TPMS BMW R1200

[techmike78]

Good day.

I have been working on a project for a long time on esp32s3+cc1101 for decoding readings from BMW motorcycle pressure sensors.
I managed to get the required values ​​using rtl_433, but I can't do the same using esp32+cc1101, I only get garbage at the receiver output.
Most likely, I didn't select the reception parameters correctly, but trying out setBitRate, setFrequencyDeviation and setRxBandwidth didn't give any result.
I ask the community for help, because my programming level and knowledge are not high enough for this.

An example of receiving data using rtl_433:

---

time : 2025-09-01 10:53:09
model : BMW count : 1 num_rows : 1 rows :
len : 45 data : 058639002248 id : 2c31c8
Pressure : 4 Temp_F : 73 F
codes : {45}058639002248

---

The latest code for Arduino (Platformio):

/*

rtl_433 -X 'name=BMW,m=OOK_MC_ZEROBIT,s=122,l=122,r=300,preamble=7fff,get=id:@3:{24}:%x,get=pressure:@27:{9}:%d,get=temp:@36:{9}:%d' -f 433.92M

-f 433.92M        - received frequency
name=BMW
m=OOK_MC_ZEROBIT - On-Off Keying with Manchester Code and a fixed leading zero bit.
s=122            - The expected duration of a "short" pulse or half-bit width in microseconds (µs).
l=122            - The expected duration of a "long" pulse or full-bit width in microseconds (µs
r=300            - The expected duration of a reset gap in microseconds (µs)
preamble=7fff

*/
#include <Arduino.h>
#include <RadioLib.h>
#include <SPI.h>

// https://github.com/jgromes/RadioLib/wiki/Debug-mode
//#define RADIOLIB_DEBUG_BASIC        (1)   // basic debugging (e.g. reporting GPIO timeouts or module not being found)
// #define RADIOLIB_DEBUG_PROTOCOL     (1)   // protocol information (e.g. LoRaWAN internal information)
// #define RADIOLIB_DEBUG_SPI          (1)   // verbose transcription of all SPI communication - produces large debug logs!

// https://github.com/jgromes/RadioLib/blob/master/examples/CC1101/CC1101_Receive_Interrupt/CC1101_Receive_Interrupt.ino
/*
esp32s3 super mini cc0111 connection spi pin
SCK - 4
MISO - 5
MOSI - 6
SS - 7
SCL/CSN -9
*/

#define CC1101_MISO 5
#define CC1101_MOSI 6
#define CC1101_SCKL 4
#define CC1101_CS 9

#define CC1101_GDO0 7
#define CC1101_GDO2 10

SPIClass newSPI(HSPI);

CC1101 radio = new Module(CC1101_CS, CC1101_GDO0, RADIOLIB_NC, CC1101_GDO2, newSPI);
// CC1101 radio = new Module(CC1101_CS, RADIOLIB_NC, RADIOLIB_NC, RADIOLIB_NC, newSPI);

// flag to indicate that a packet was received
volatile bool receivedFlag = false;
// this function is called when a complete packet
// is received by the module
// IMPORTANT: this function MUST be 'void' type
//            and MUST NOT have any arguments!
#if defined(ESP8266) || defined(ESP32)
  ICACHE_RAM_ATTR
#endif
void setFlag(void) {
  // we got a packet, set the flag
  receivedFlag = true;
}

void printhex(int h) {
  if (h<16) {
    Serial.print("0");
  }
  Serial.print(h,HEX);
}

byte mc_Arr[255];   // array for Manchester bytes
// https://github.com/cterwilliger/tst_tpms/blob/main/examples/CC1101_tpms_recv_example.ino#L216
/*
 * decodeManI
 * ----------
 * Manchester I (IEEE 802.3) bitstream decoder
 * Manchester encoded bit stream uses 2 bits to represent 1 bit of data.  Manchester I encodes a "1" as a transition 
 * from low to high and "0" as a transition from high to low.  Each byte decodes to 1 nibble.
 */
void decodeManI(byte *array, int size)
{ 
    // array of all possible Manchester I values
    byte manIarray[16] = {0xAA, 0xA9, 0xA6, 0xA5, 0x9A, 0x99, 0x96, 0x95, 0x6A, 0x69, 0x66, 0x65, 0x5A, 0x59, 0x56, 0x55};
    int k = 0;

    // convert each Manchester I byte to it's NRZ equivalent
    for ( int i = 0; i < size; i=i+2 ) // look at every 2 bytes in the payload
    {
        for ( int j = 0; j < 16; j++ )
        {
            if ( array[i] == manIarray[j] ) // search for ManI pattern
            {
                array[k] = j << 4; // shift left one nibble, put back into passed array
            }
        } 

        for ( int j = 0; j < 16; j++ )
        {
            if ( array[i+1] == manIarray[j] )
            {
                array[k] = array[k] | j; // combine previous nibble with this one
            }
        }
        k++;
    }

} // end decodeManI

void setup()
{
  delay(6000);
	Serial.begin(115200);
  Serial.setDebugOutput(true);
  delay(1000);
  Serial.println(F("Starting... "));
  delay(1000);

  Serial.print(F("[CC1101] Initializing ... "));

	//spi.begin();
  newSPI.begin(CC1101_SCKL, CC1101_MISO, CC1101_MOSI, CC1101_CS);
	
  // int state = radio.begin(433.92);
  int state = radio.begin();
  if (state == RADIOLIB_ERR_NONE)
  {
      Serial.println(F("success!"));
      Serial.print(F("[CC1101] Partnumber ")); Serial.println(radio.SPIgetRegValue(0x30), HEX);
      Serial.print(F("[CC1101] Version ")); Serial.println(radio.getChipVersion(), HEX);
  }
  else
  {
      Serial.print(F("failed: code "));
      Serial.println(state);
      // while (true);
  }

  float frequency = 433.92;
  // float frequency = 433.919830;
  if (radio.setFrequency(frequency) == RADIOLIB_ERR_INVALID_FREQUENCY) {
    Serial.println(F("[CC1101] Selected frequency is invalid for this module!"));
    while (true);
  } else {
    Serial.print(F("[CC1101] setFrequency [MHz] ")); Serial.println(frequency);
  }
  // float bitrate = 19.2;  // 19200 baud
    float bitrate = 9.6;  // 9600 baud
  state = radio.setBitRate(bitrate);
  if (state == RADIOLIB_ERR_INVALID_BIT_RATE) {
    Serial.println(F("[CC1101] Selected bit rate is invalid for this module!"));
    while (true);
  } else if (state == RADIOLIB_ERR_INVALID_BIT_RATE_BW_RATIO) {
    Serial.println(F("[CC1101] Selected bit rate to bandwidth ratio is invalid!"));
    Serial.println(F("[CC1101] Increase receiver bandwidth to set this bit rate."));
    while (true);
  } else {
    Serial.print(F("[CC1101] setBitRate [kbps] ")); Serial.println(bitrate);
  }
  // float bandwidth = 135.0;
  // if (radio.setRxBandwidth(bandwidth) == RADIOLIB_ERR_INVALID_RX_BANDWIDTH) {
  //   Serial.println(F("[CC1101] Selected receiver bandwidth is invalid for this module!"));
  //   while (true);
  // } else {
  //   Serial.print(F("[CC1101] setBandwidth [kHz] ")); Serial.println(bandwidth);
  // }
  radio.autoSetRxBandwidth();

  byte syncHigh = 0x7F; byte syncLow = 0xFF;
   radio.SPIwriteRegister(0x04, syncHigh); Serial.print(F("[CC1101] Reg0x04 SetSyncHigh ")); Serial.println(syncHigh);
   radio.SPIwriteRegister(0x05, syncLow); Serial.println(F("[CC1101] Reg0x05 SetSyncLow ")); Serial.println(syncLow);

  radio.setEncoding(RADIOLIB_ENCODING_MANCHESTER);    // for transmitt encodeind

  // set the function that will be called
  // when new packet is received
  radio.setGdo0Action(setFlag, CHANGE);

  // set the function that will be called
  // when new packet is received
  radio.setPacketReceivedAction(setFlag);

  // test cc1101 spi work
  radio.SPIwriteRegister(0, 0x29);
  delay(500);
  if (radio.SPIreadRegister(0) == 0x29)
  {
    Serial.println(F("CC1101 reset successful"));
  }else{
    Serial.println(F("CC1101 reset failed. Try rebooting"));
  }

    radio.setOOK(true);   // OOK is on
    radio.setFrequency(433.92);
    radio.setBitRate(9.6);
    radio.setFrequencyDeviation(50);
    radio.setRxBandwidth(125);
    radio.setCrcFiltering(false);
    
    //radio.setSyncWord(0x7F, 0xFF, 1, true);
    //radio.fixedPacketLengthMode(16);
    radio.disableAddressFiltering();
    radio.disableSyncWordFiltering();

  // start listening for packets
  Serial.print(F("[CC1101] Starting to listen ... "));
  state = radio.startReceive();
  if (state == RADIOLIB_ERR_NONE) {
    Serial.println(F("success!"));
  } else {
    Serial.print(F("failed, code "));
    Serial.println(state);
    while (true) { delay(10); }
  }

  Serial.println(F("Started!"));
  delay(5000);
}

void loop (void)
{
  delay(1);
  
    // check if the flag is set
  if(receivedFlag) {
    bool print_debug=1;
    bool find_pre=0;

    // you can also read received data as byte array
    int len = radio.getPacketLength();
    byte byteArr[len+1];
    int state = radio.readData(byteArr, len);

    if (print_debug==1){

      memset(mc_Arr,'\0',sizeof(mc_Arr)); //обнуляем все данные внутри структуры
      memcpy(mc_Arr, byteArr, len); // переносим данные в буфер для отправки
      // decode manchester I
      decodeManI(mc_Arr, 16);

      Serial.print(len); Serial.print("; ");
      Serial.print(radio.getRSSI());
      Serial.print("; ");
      Serial.print(radio.getLQI());
      Serial.print("; ");

      // print data of the packet
      for (int i=0; i<len; i++) {
        printhex(byteArr[i]);
      }
      Serial.println();
   
      Serial.print("MC: ");
      // print data of the MC packet
      for (int i=0; i<len; i++) {
        printhex(mc_Arr[i]);
      }
      Serial.println();

    }

    
    // BMW tpms preamble
    if (byteArr[0]==0x7F && byteArr[1]==0xFF ){
      // https://github.com/merbanan/rtl_433/blob/master/src/devices/tpms_bmw_g3.c
      Serial.println("BMW header finded !");
      find_pre=1;
    }

    for (int i=0; i<len; i++) {
      if (byteArr[i]==0x7F && byteArr[i+1]==0xFF){
        Serial.println("FINDED !!!");
        find_pre=1;
      }
    }

    if (find_pre==1){
      Serial.print(len); Serial.print("; ");
      Serial.print(radio.getRSSI());
      Serial.print("; ");
      Serial.print(radio.getLQI());
      Serial.print("; ");

      // print data of the packet
      for (int i=0; i<len; i++) {
        printhex(byteArr[i]);
      }
      Serial.println();

    }
    find_pre=0;

    // put module back to listen mode
    radio.startReceive();

    // reset flag
    receivedFlag = false;
  }

}

Data output when receiving readings from the sensor:

Starting...
[CC1101] Initializing ... success!
[CC1101] Partnumber 0
[CC1101] Version 14
[CC1101] setFrequency [MHz] 433.92
[CC1101] setBitRate [kbps] 9.60
[CC1101] Reg0x04 SetSyncHigh 127
[CC1101] Reg0x05 SetSyncLow
255
CC1101 reset successful
[CC1101] Starting to listen ... success!
Started!
152; -135.00; 6; 001F9F9E1F99FFFE67F99F9FF87FE7867E78667E01861F86061F8666187F99E19E1866067FFE1F99879E61F807F99E0660181E0601E7E7E61E7F9E1FFF9F818181001F9F9E1F99FFFE67F99F9FF87FE7867E78667E01861F86061F8666187F99E19E1866067FFE1F99879E61F807F99E0660181E0601E7E7E61E7F9E1FFF9F8181001F9F9E1F99FFFE67F99F9FF87FE7867E78667E01861F
MC: 001F9F9E1F99FFFE67F99F9FF87FE7867E78667E01861F86061F8666187F99E19E1866067FFE1F99879E61F807F99E0660181E0601E7E7E61E7F9E1FFF9F818181001F9F9E1F99FFFE67F99F9FF87FE7867E78667E01861F86061F8666187F99E19E1866067FFE1F99879E61F807F99E0660181E0601E7E7E61E7F9E1FFF9F8181001F9F9E1F99FFFE67F99F9FF87FE7867E78667E01861F
102; -73.50; 31; 67F879FE607E01F9980181FE7E6799F8618001F879E7E1FE67E7FE0619FE079819FE799806019FE7878607879E1800AE43DA0FE8493FFF9E7FFFFE18679FF8F88167F879FE607E01F9980181FE7E6799F8618001F879E7E1FE67E7FE0619FE079819FE799806
MC: 67F879FE607E0150980181FE7E6799F8618001F879E7E1FE67E7FE0619FE079819FE799806019FE7878607879E1800AE43DA0FE8493FFF9E7FFFFE18679FF8F88167F879FE607E01F9980181FE7E6799F8618001F879E7E1FE67E7FE0619FE079819FE799806
FINDED !!!
102; -73.50; 31; 67F879FE607E01F9980181FE7E6799F8618001F879E7E1FE67E7FE0619FE079819FE799806019FE7878607879E1800AE43DA0FE8493FFF9E7FFFFE18679FF8F88167F879FE607E01F9980181FE7E6799F8618001F879E7E1FE67E7FE0619FE079819FE799806

[jgromes]

There's a couple of things wrong in the code, but the bigger issue is probably that the CC1101 expects a specific packet format (a preamble, a sync word, optionally the payload length field and only then, the payload. You will need to check what sort of packet format is your transmitter using. And of course, you will need to know all of the signal properties an d its modulation.

Also, this is not actually a problem in the library, so I'm converting this to a discussion thread instead of an issue.

[techmike78]

You wrote everything correctly, it is with the selection of parameters that I cannot do.
As far as my knowledge of digital signals allows me, the preamble and sync word are not as important as the speed and bandwidth of the signal.

From the side of rtl_433 the following parameters are known:

rtl_433 -X 'name=BMW,m=OOK_MC_ZEROBIT,s=122,l=122,r=300,preamble=7fff,get=id:@3:{24}:%x,get=pressure:@27:{9}:%d,get=temp:@36:{9}:%d' -f 433.92M

-f 433.92M - received frequency 433.92 mhz
name=BMW - name decoder (any)
m=OOK_MC_ZEROBIT - On-Off Keying with Manchester Code and a fixed leading zero bit.
s=122 - The expected duration of a "short" pulse or half-bit width in microseconds (µs).
l=122 - The expected duration of a "long" pulse or full-bit width in microseconds (µs
r=300 - The expected duration of a reset gap in microseconds (µs)
preamble=7fff - preamble to the beginning of the data

[techmike78]

It was possible to successfully send a data packet using cc1101, which was recognized as a sensor in rtl_433.
With the settings:

uint8_t tx_byteArr[] = {0x7f, 0xff, 0x05, 0x86, 0x39, 0x00, 0x22, 0x48};
int state = radio.begin(433.92);
state = radio.setOOK(true);
state = radio.setEncoding(RADIOLIB_ENCODING_MANCHESTER); 
state = radio.fixedPacketLengthMode(0);
radio.disableSyncWordFiltering();
radio.setCrcFiltering(false);
radio.disableAddressFiltering();  // disable address filtering
radio.setFrequencyDeviation(35.0);   // девиация в kHz, // if ASK/OOK, deviation makes no sense
radio.setBitRate(9.6);              // скорость в kbps

int state = radio.startTransmit(tx_byteArr, sizeof(tx_byteArr), 0);  

But it is not possible to receive the same packet, there is simply no data to receive, with the same cc1101 settings. I tried both blocking functions and by interrupt.

[jgromes]

As far as my knowledge of digital signals allows me, the preamble and sync word are not as important as the speed and bandwidth of the signal.

This is really not true. Without knowing the packet format (including a sync word), how can you tell a packet from the noise? This is a prerequiste alongside the modulation parameters, not something "less important".

But it is not possible to receive the same packet, there is simply no data to receive, with the same cc1101 settings

That is not surprising, considering one of the things you are doing in your is radio.fixedPacketLengthMode(0); (not to mention ignoring all return codes, so you have no idea whether the configuration succeeded or not). I would recommend reading the documentation for CC1101::fixedPacketLengthMode and also consulting the CC1101 for the packet formats it supports.

[techmike78]

As far as my knowledge of digital signals allows me, the preamble and sync word are not as important as the speed and bandwidth of the signal.

This is really not true. Without knowing the packet format (including a sync word), how can you tell a packet from the noise? This is a prerequiste alongside the modulation parameters, not something "less important".

But it is not possible to receive the same packet, there is simply no data to receive, with the same cc1101 settings

That is not surprising, considering one of the things you are doing in your is radio.fixedPacketLengthMode(0); (not to mention ignoring all return codes, so you have no idea whether the configuration succeeded or not). I would recommend reading the documentation for CC1101::fixedPacketLengthMode and also consulting the CC1101 for the packet formats it supports.

Good day.

Thank you for constructive criticism.
The code above is the result of my attempts to receive something from the tpms sensor. I tried both a fixed packet length and an arbitrary one, but it did not help me.
Perhaps I do not understand all the details for working with cc1101.
A packet with data from the sensor is 8 bytes, where the peramble is 0x7f 0xff, for example in HEX:
7fff058639002248

For example, for a fixed packet length, the settings were as follows (taking into account that in cc1101 the last two bytes will be used for RSSI and LQI because PKTCTRL1=0x04):

  state = radio.setOOK(true);  // Включение OOK модуляции
  state = radio.setEncoding(RADIOLIB_ENCODING_MANCHESTER);    // for transmitt encodeind
  state = radio.fixedPacketLengthMode(10); 
  state = radio.setSyncWord(0xfe, 0xff);  // set synck world (preamle) 0xfe, 0xff
  state = radio.setCrcFiltering(false);
  state = radio.disableAddressFiltering();  // disable address filtering
  state = radio.setFrequencyDeviation(35.0);   // девиация в kHz, // if ASK/OOK, deviation makes no sense
  state = radio.setBitRate(9.6);              // скорость в kbps
  state = radio.autoSetRxBandwidth();
  radio.setPacketReceivedAction(setFlag);
  state = radio.setPromiscuousMode(true);   // Set modem in "sniff" mode: no packet filtering (e.g., no preamble, sync word, address, CRC).

I receive garbage on interrupt, where there is 0xfe, 0xff, I catch it with a separate code:

      for (int i=0; i<len; i++) {
      if (byteArr[i]==0x7F && byteArr[i+1]==0xFF){
        Serial.println("FINDED !!!");
        find_pre=1;
      }
    }

and there are completely inappropriate bytes, for example:

FINDED !!!
readData state: 0
10; -90.00; 0; 8F867B3FF07FFFF3083E
MC: 8F867B3FF07FFFF3083E
FINDED !!!
readData state: 0
10; -88.00; 0; BCC07FFF9981FFE06180
MC: BCC050FF9981FFE06180

[techmike78]

I tried to configure strictly according to the datasheet:
preamble 16 bits = 0xfeff
fixed packet length 8+2=10 bytes
without sync word
without address
without CRC

radio.reset();
int state = radio.begin(433.92);
state = radio.setOOK(true);  // Включение OOK модуляции
state = radio.setEncoding(RADIOLIB_ENCODING_MANCHESTER);    // for transmitt encodeind
state = radio.fixedPacketLengthMode(10); 
state = radio.setPreambleLength(16,0);
state = radio.setSyncWord(0xFE, 0xFF, 0); // Преамбула FE FF
state = radio.setCrcFiltering(false);
state = radio.disableAddressFiltering();  // disable address filtering

state = radio.setFrequencyDeviation(35.0);   // девиация в kHz, // if ASK/OOK, deviation makes no sense
state = radio.setBitRate(9.6);              // скорость в kbps
state = radio.autoSetRxBandwidth();

as a result, when the sensor transmits and in rtl_433 a packet of the following type is received:

058639002240

in serial esp32 you can see many packets, but not with the same content:

readData state: 0
RAW: 10; -73.50; 6; 009D9FFDBEFEF7D612A2
MC: 009D9FFDBEFEF7D612A2
readData state: 0
RAW: 10; -105.50; 127; 73DC29732E2AF9EC0273
MC: 73DC29732E2AF9EC0273
readData state: 0
RAW: 10; -69.50; 28; FF99F334FE6D191AB9A0
MC: FF99F334FE6D191AB9A0
readData state: 0
RAW: 10; -73.50; 65; C4F1BA21E91A569B7B67
MC: C4F1BAE0E91A569B7B67
readData state: 0
RAW: 10; -69.00; 25; FFFFFFB2F0A17AD1A7ED
MC: FFFFFFB2F0A17AD1A7ED
readData state: 0
RAW: 10; -69.00; 20; F7FF7E35A7C8757B63B3
MC: F7FF7E35A7C8757B63B3
readData state: 0
RAW: 10; -71.50; 56; E46DD7B785EF1FE20A94
MC: E46DD7B785EF1FE20A94
readData state: 0
RAW: 10; -73.00; 78; 715761FC84A45ECDBD79
MC: 715761FC84A45ECDBD79
readData state: 0
RAW: 10; -69.00; 18; DFBF77555E4A7C0AD819
MC: DFBF77555E4A7C0AD819
readData state: 0
RAW: 10; -69.00; 28; FEFCBFEFFFDC9D2DDEFA
MC: FEFCBFEFFFDC9D2DDEFA
readData state: 0
RAW: 10; -70.00; 40; F7FF15174555DC289D91
MC: F7FF1F174555DC289D91
readData state: 0
RAW: 10; -68.50; 17; FFFFDFF487A2E2C77497
MC: FFFFDFF487A2E2C77497
readData state: 0
RAW: 10; -69.00; 32; CFF6A7FA4EBC8844DFE2
MC: CFF6A7FA4EBC8844DFE2
readData state: 0
RAW: 10; -71.50; 58; E94F64027453551A857E
MC: E94F64F07453551A857E
readData state: 0
RAW: 10; -72.00; 55; B6F24C77C3F8497B30F0
MC: B6F24C77C3F8497B30F0
readData state: 0
RAW: 10; -69.50; 42; ED6FAF11C570C26E77ED
MC: ED6FAF11C570C26E77ED
readData state: 0
RAW: 10; -74.00; 6; FBF7DFFFFE9FF46AE75D
MC: FBF7DFFFFE9FF46AE75D
readData state: 0
RAW: 10; -72.00; 9; FFDB3DE1FFFDFC748D30
MC: FFDB3DE1FFFDFC748D30
readData state: 0
RAW: 10; -74.50; 21; FCB0739F27573B28BC8B
MC: FCB0739F27573B28BC8B
readData state: 0
RAW: 10; -70.50; 9; FFDB6FBF73E73AFFBF7D
MC: FFDB6FBF73E73AFFBF7D
readData state: 0
RAW: 10; -73.50; 15; 7FCFAD6FDED8C9B1BB1E
MC: 7FCFAD6FDED8C9B1BB1E

what am i doing wrong?

[techmike78]

OK, let's dig a bit into what you provided:

preamble 16 bits = 0xfeff

It seems to me that in the first example you posted, there is the preamble 0x7FFF, so I don't know where you got 0xFEFF from. But nevertheless, that is a rather uncomon for a preamble, the typical values are a series of alternating zeroes and ones, 0x55... or 0xAA... - the many edge transitions help the receiver synchronize to the signal. CC1101 expexts this sort of alternating preamble, so this is already a problem. Maybe it could be worked by disabling the preamble and treating 0x7FFF as a sync word, but I don't know whether CC1101 can disable the preamble detection completely.

The correct preamble value is 0x7fff, I set another value during tests and it is incorrect.
But it is called "preamble" in the rtl_433 program. In cc1101 it looks more like SyncWord.

In the cc1101 datasheet I did not find a direct way to disable the preamble, you can only set its length in the MDMCFG1 byte (6:4 NUM_PREAMBLE[2:0]) and this value is set to the default for me - CC1101_MDMCFG1: 0x02 (Number of preamble bytes = 4).
With the current cc1101 settings (setSyncWord(0x7F, 0xFF, 0)), if the tpms sensor transmits, then cc1101 clearly starts to show that it receives data, thus the default preamble for cc1101 is triggered.

Next, you are setting bit rate to 9.6 kbps. I don't know where you got that value from, since the first code snippet you have posted says:

l=122 - The expected duration of a "long" pulse or full-bit width in microseconds (µs

So, that would mean the bit rate you're looking for is something like 1/122e-6 = 8.196 kbps (let's round that and call it 8.2 kbps), right?

fixed packet length 8+2=10 bytes

I don't know where is this coming from, your example packet of 058639002240 is 6 bytes long.

The value of 9.6 kbps was selected experimentally for the transmission speed. I could not find a value where the data is received in the required format.
The rtl_433 program allows you to decompose the signal into a spectrogram, where you can see that the minimum pulse width is 144 μs. This turns out to be 1/0.000144 = 6.9 kbps.
The spectrogram can be presented as text or a link to triq.org/pdv:

rtl_433 -X 'name=BMW,m=OOK_MC_ZEROBIT,s=122,l=122,r=300' -f 433.92M -A g022_433.92M_250k.cu8
Detected OOK package    @0.465608s
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : @0.465608s
model     : BMW          count     : 1             num_rows  : 1             rows      :
len       : 61           data      : 7fff058639002248
codes     : {61}7fff058639002248
Analyzing pulses...
Total count:   51,  width: 15.39 ms             ( 3847 S)
Pulse width distribution:
 [ 0] count:    2,  width:  508 us [504;516]    ( 127 S)
 [ 1] count:   40,  width:  144 us [140;148]    (  36 S)
 [ 2] count:    9,  width:  264 us [260;276]    (  66 S)
Gap width distribution:
 [ 0] count:   41,  width:  100 us [96;112]     (  25 S)
 [ 1] count:    9,  width:  220 us [220;224]    (  55 S)
Pulse period distribution:
 [ 0] count:    2,  width:  668 us [600;740]    ( 167 S)
 [ 1] count:   37,  width:  244 us [244;256]    (  61 S)
 [ 2] count:    5,  width:  488 us [484;500]    ( 122 S)
 [ 3] count:    6,  width:  368 us [364;376]    (  92 S)
Pulse timing distribution:
 [ 0] count:    2,  width:  508 us [504;516]    ( 127 S)
 [ 1] count:   40,  width:  144 us [140;148]    (  36 S)
 [ 2] count:   18,  width:  244 us [220;276]    (  61 S)
 [ 3] count:   41,  width:  100 us [96;112]     (  25 S)
 [ 4] count:    1,  width: 10004 us [10004;10004]       (2501 S)
Level estimates [high, low]:  15986,     20
RSSI: -0.1 dB SNR: 29.0 dB Noise: -29.1 dB
Frequency offsets [F1, F2]:    2040,      0     (+7.8 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB10501FC009000F40064271483939393939393939393939393938293939393A2A392939393A3929393A3939293A2939393939393939393A29393A293A293A455
Attempting demodulation... short_width: 144, long_width: 264, reset_limit: 228, sync_width: 508
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=144,l=264,r=228,g=0,t=0,y=508'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {13} ff f8          : 11111111 11111
[01] {36} f3 dd df f6 a0 : 11110011 11011101 11011111 11110110 1010

Detected OOK package    @0.662904s

I tried to configure it as in the last attempt, but specify the data length as 6 bytes, the speed of 6.9 kbps and disable the reception of RSSI + LQI parameters.

int state = radio.begin(433.92);
state = radio.setOOK(true);  // Включение OOK модуляции
state = radio.setEncoding(RADIOLIB_ENCODING_MANCHESTER);    // for transmitt encodeind
state = radio.fixedPacketLengthMode(6); 
state = radio.setPreambleLength(16,0);
state = radio.setSyncWord(0x7F, 0xFF, 0); // Преамбула 7F FF
state = radio.setCrcFiltering(false);
state = radio.disableAddressFiltering();  // disable address filtering
state = radio.setFrequencyDeviation(35.0);   // девиация в kHz, // if ASK/OOK, deviation makes no sense
state = radio.setBitRate(6.9);              // скорость в kbps
state = radio.autoSetRxBandwidth();
state = radio.SPIsetRegValue(RADIOLIB_CC1101_REG_PKTCTRL1, RADIOLIB_CC1101_APPEND_STATUS_OFF, 2, 2);  // PKTCTRL1.APPEND_STATUS is OFF

RAW: 6; -74.00; 0; FFFFFFFFFFFF
As a result, cc1101 when transmitting the tpms sensor receives the values ​​FFFFFFFFFFFF

Is this due to a mismatch between the transmission and reception speed?

[jgromes]

Is this due to a mismatch between the transmission and reception speed?

Possibly, but I think the primary issue is going to be the packet format.

if the tpms sensor transmits, then cc1101 clearly starts to show that it receives data, thus the default preamble for cc1101 is triggered.

That does not mean it will be able to receive anything sensible. If the CC1101 cannot synchronize on the signal correctly (for example - because it expects more preamble bits, as 0x7FFF is certainly not 4 bytes), then it will always output garbage.

[techmike78]

Is this due to a mismatch between the transmission and reception speed?

Possibly, but I think the primary issue is going to be the packet format.

if the tpms sensor transmits, then cc1101 clearly starts to show that it receives data, thus the default preamble for cc1101 is triggered.

That does not mean it will be able to receive anything sensible. If the CC1101 cannot synchronize on the signal correctly (for example - because it expects more preamble bits, as 0x7FFF is certainly not 4 bytes), then it will always output garbage.

Configured in the data reception cycle from tpms, change of synchronization mode (SYNC_MODE).
The necessary data was not received, but bytes 0x7F, 0xFF are received only in the mode "No preamble/sync, carrier-sense above threshold".
Tried to change the preamble size manually (setPreambleLength function), no data was received at all.

I am at a dead end, I don't understand what to do next.
cc1101 does not have a setting for changing the preamble.

I have an idea to switch cc1101 to transparent mode and use a logic analyzer to search for what the module receives on the GDO pin. But I have not investigated at such a low level, and I have no idea who can help me with this.

[jgromes]

I have an idea to switch cc1101 to transparent mode and use a logic analyzer to search for what the module receives on the GDO pin

RadioLib does support that using the receiveDirect (GDO0 clock, GDO2 data) and receiveDirectAsync (GDO0 data), so feel free to test it out.

But I think you should step back a little bit here - do you absolutely need to receive this using CC1101? Can you switch to some other module, or better yet, and SDR which has a lot more flexibiltiy than a transceiver IC?

[techmike78]

Which RF chip to use is not important for me, I have different chips, but 1101 has more information on the Internet.
I also have si4432, si44631b, SX1278, they work very similar to 1101 but more modern, but there is less information on them on the Internet.

I also tried another program for rtlsdr - Universal Radio Hacker (URH). In it, I decoded slightly different bytes, I am still confused and still studying this program.

[techmike78]

I conducted an experiment, transmitted a fixed data packet but at different speeds, received it using the rtl_433 program.
As a result, the data packet is received only at a speed of 9.6 kbps, at other values, data was not received.
Used the following speed values ​​in the cycle:
float BitRate_Arr[] = {1.2, 2.4, 3.0, 4.8, 9.6, 14.4, 19.2, 38.4, 76.8, 153.6, 307.2};

[techmike78]

@jgromes Could you please tell me how to get all the configuration register values ​​for the sx1278 chip using the register read function with spi?
I added the parameter to .pio\libdeps\esp-wrover-kit\RadioLib\src\BuildOptUser.h
#define RADIOLIB_GODMODE (1)

but when compiling, I get a function unavailable error:

In file included from C:/avrprojects/esp32_SX1278_test_rx/src/esp32_SX1278_test_rx.ino:11:
.pio/libdeps/esp-wrover-kit/RadioLib/src/RadioLib.h:58:4: warning: #warning "God mode active, I hope it was intentional. Buckle up, lads." [-Wcpp]
   58 |   #warning "God mode active, I hope it was intentional. Buckle up, lads."
      |    ^~~~~~~
C:/avrprojects/esp32_SX1278_test_rx/src/esp32_SX1278_test_rx.ino: In function 'void setup()':
C:/avrprojects/esp32_SX1278_test_rx/src/esp32_SX1278_test_rx.ino:214:29: error: 'class SX1278' has no member named 'readRegister'
  214 |   uint8_t regOpMode = radio.readRegister(0x01);
      |                             ^~~~~~~~~~~~

This error occurs in the following piece of code:

  // RegOpMode (0x01) - Режим работы
  uint8_t regOpMode = radio.readRegister(0x01);
  Serial.print(F("RegOpMode (0x01): 0x"));
  Serial.println(regOpMode, HEX);

[Evil-Optimus]

Hello techmike78,
Thanks for your answer. It's great that you're willing to share the code. I can learn something from it. But I still have a question. How did you detect the sensor in RTL433?
I have an 8532731 sensor, an RTL SDR model 4 module, and one EL-50448 wake-up tool for testing, but I'm not receiving anything in RTL433. On the SDRSharp I can see a signal when I use the EL-50448 wake-up tool.

I receive data in RTL433 from Toyota sensors in the street and other stuf but notting from the 8532731 sensor.
What do I wrong? Or does the sensor have to be under pressure to be recognized?
PS. I don't own a BMW R1200GSA myself.
I'm looking this up for my brother-in-law and also to learn more about tire monitoring systems.

[Karolas123]

Hi. I was able to detect sensor issues with my R1200GS R50, both using rlt_433 and the esp32c3+sx1278 combination. I haven't posted the code for the latter anywhere yet, but I can send it here, but you'll have to clean it up to remove my specific device details.

Hi, did you manage to pick up the BMW R1200 sensors using the CC1101 radio? Are you still having problems? If you succeeded, could you share your configuration?

[Evil-Optimus]

Hi techmike78,

could you share the code for reading the TPMS with an ESP32 and an SX1278. Information about the sensor problems on your R1200GS and how you resolved them might also be of interest to other BMW owners.
Your experiences regarding the composition of your ESP32, SX 1278, antenna, use and troubleshooting of the problem with the BMW and TPMS are also very welcome for anyone who wants to start with this.

I now have the idea to make a mobile TPMS sniffer/logger with the LilyGO TTGO T3 LoRa32 V1.6.1 433MHz.
After some additional research and reading information about RTL433, I came across this module, as they use the same module to read sensor data with RTL433 and then send the data via Wi-Fi through an openMQTT Gateway to Home Assistant.
So, if this module allows this, it should also be possible to read just one type of TPMS sensor and display it on the module's display.
The LilyGO TTGO LoRa32 is a microcontroller based on an ESP32 with a built-in LoRa chip SX1278, an OLED display, and an SD card adapter, all in a single module.
Thanks to the USB-to-serial converter, it should be easy to program, even like an Arduino.
I believe this should be possible with this module. It's a simple and relatively inexpensive module without much soldering and is compact. Ideal for dummies like myself working with RTL433, RF, etc.

It also seems like a useful tool if you have two spare wheels for off-road trips, so you can test the TPMS sensors before installing them on the BMW motorcycle.
Perhaps a starting point (idea) for other TPMS sniffers/loggers/testers, etc.

So if you have a moment, could you please share this information? Then I can also test it with a Schrader sensor 8532731. If it works with the Schrader sensor, I'll also test it on the BMW R1200GSA motorcycle and the extra wheels.

Thanks in advance.

Greetings, Evil-Optimus

[serialrf433]

@Evil-Optimus
You would maybe like to take a look at this 3 things if you want to use Arduino and the LoRa32 433 device:
https://github.com/NorthernMan54/rtl_433_ESP
NorthernMan54/rtl_433_ESP#198
https://github.com/digitalcontemplation/rtl_433_ESP-Arduino-IDE-compatibility

[techmike1978]

Hello techmike78, Thanks for your answer. It's great that you're willing to share the code. I can learn something from it. But I still have a question. How did you detect the sensor in RTL433? I have an 8532731 sensor, an RTL SDR model 4 module, and one EL-50448 wake-up tool for testing, but I'm not receiving anything in RTL433. On the SDRSharp I can see a signal when I use the EL-50448 wake-up tool.

I receive data in RTL433 from Toyota sensors in the street and other stuf but notting from the 8532731 sensor. What do I wrong? Or does the sensor have to be under pressure to be recognized? PS. I don't own a BMW R1200GSA myself. I'm looking this up for my brother-in-law and also to learn more about tire monitoring systems.

Good afternoon.
I detected the sensor using a "wake-up" device (EL-50448 OEC-T5), which generates a 150 kHz carrier frequency, and the sensor responds by transmitting its readings. In my case, it sends 25 identical data packets. After that, I used rtl_433 in data capture mode and wrote it to a file (rtl_433 -f 433M -S all). The people in this thread were very helpful in selecting the right filter.

The sensor doesn't necessarily have to be in the tire or have a different pressure than normal; it transmitted the data as is.
It's important to note that pressure sensors are available not only at 433 MHz, but also at 2.4 MHz. You need to search online to find out for yourself to avoid wasting a lot of time. But I knew for sure that my BMW 1200GS operates at 433 MHz, because It's based on its pressure reading unit (RDC 65758546222), as stated in the specifications. Modern BMW motorcycle sensors already use Bluetooth and are not compatible with mine.
If you're unsure about the sensor's transmission frequency, it's quicker to contact a service center that has the equipment to work with the sensors and can check the frequency at which they transmit data.

[Evil-Optimus]

Hallo serialrf433,
Thanks for the links. I'll take a closer look at the content first.
One thing that stands out to me is the comment in NorthernMan54's first link regarding LILYGO LORA 32:

This is the LILYGO® LoRa32 V2.1_1.6.1 433 board I used for development. I used the 433 Mhz Board with the SX127X chipset.
When your purchasing one of these, please watch out for similar boards that do not use the SX127X chipset. These others boards will not work, as the required receiver mode is not available in the chipset.

I don't see any indication of the chipset used.
The module I received from AliExpress looks exactly like the one in the photo in this article.

The only additional information is stated on the packaging.

I'll take a closer look at this first.
Thanks in advance for the information.
Greetings, Evil-Optimus

[Evil-Optimus]

Hello serialrf433,
Thanks for the information. I'm trying it with the LILYGO® LoRa32 V2.1_1.6.1 433 board.
According to the information I found, the module I received is the correct board with the SX1278 chipset.

T3_V1.6.1 with NR 20210104 is the correct PCB.
LILYGO 433/470MHz Model LORA32 is the correct chipset (SX1278).
Q134 listed on the box is the pre-installed software: in this case, Paxcounter on 433MHz.
We don't need this in my case, so that firmware will be deleted.

[Evil-Optimus]

Hello techmike1978 (or techmike78)
Thanks for sharing the code. I'll take a closer look at it first and try to convert it for use with a LILYGO® LoRa32 V2.1_1.6.1 433 board.

Greetings to everyone and thanks for the help and information.
to be continued...

[Evil-Optimus]

I first checked the Lilygo for the correct connections for LORA and to test the screen.
I'll go step by step so that anyone interested with limited knowledge can follow along.
I'll also try to learn something new and summarize it in a single document afterward.

To write a sketch (program) to a LilyGo T3 V1.6.1 (LoRa32) ESP32 board, i use the Arduino IDE.
Configure the IDE with the ESP32 board manager, install the necessary LoRa and OLED libraries, selected the correct "ESP32 Dev Module," and selected the correct COM port for uploading.
The code is written in Arduino IDE V1.8.19.
Required libraries (Arduino IDE) (needs to be installed)
• RadioLib
• Adafruit SSD1306
• Adafruit GFX

GFXBoard: TTGO LoRa32-OLED v2.1.6
Pin definitions for T3 V1.6.1 LORA
• MOSI 27
• SCK 5 (SCLK)
• CS 18
• DIO 26
• RST 23
• MISO 19

Pin definitions for T3 V1.6.1 OLED
• OLED_SDA 21
• OLED_SCL 22

So here's a small test program for the screen. I chose font size 2 so I could display the four desired data points at once. I'll refer to it as the “TPMS IPTS screen data” from now on:
• I: TPMS SENSOR ID
• P: Pressure in bar
• T: Temperature in Celsius
• S: Battery status

Arduino Code : BMWSCREEN01

to be continued…….

[Evil-Optimus]

BMWSCREEN01.txt

[Evil-Optimus]

Here's the next step: I'm going to try configuring the T3 LoRa32 V1.6.1 433 MHz (SX1278) according to the information from techmike78's code and jgromes' comments in this section.

I don't understand everything in the code yet, but I'll try to implement it step by step so I can learn something.
So first, i'll try to get the raw code from the TPMS sensors.

Since I've also heard that this module (T3 LoRa32 V1.6.1 433 MHz (SX1278)) is almost dead, and the Heltec with SX1278 is also almost impossible to find, the only remaining option is the SX1278 external (AI Thinker - SX1278 with an ESP32) to receive TPMS.

Maybe someone has some tips for recent alternatives for Lilygo and Heltec in 2026.

To be continued…

Lilygo T3_V1.6.1 has the following connections:
MOSI: 27
SCLK: 5
CS: 18
DIO: 26
RST: 23
MISO: 19

#include <Arduino.h>
#include <SPI.h>
#include <Wire.h>
#include <RadioLib.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>
// ---------------------------------------------------------
// Hardware-config T3 LoRa32 V1.6.1 433 MHz (SX1278)
// ---------------------------------------------------------
#define LORA_SCK 5
#define LORA_MISO 19
#define LORA_MOSI 27
#define LORA_CS 18
#define LORA_RST 23
#define LORA_DIO0 26
#define LORA_DIO1 33

// SSD1306 I2C
#define OLED_ADDR 0x3C
#define OLED_SDA 21
#define OLED_SCL 22
#define OLED_WIDTH 128
#define OLED_HEIGHT 64

SPIClass spiLora(VSPI);
SX1278 radio = new Module(LORA_CS, LORA_DIO0, LORA_RST, LORA_DIO1, spiLora);
Adafruit_SSD1306 display(OLED_WIDTH, OLED_HEIGHT, &Wire, -1);

Initialize Lora SX1278

radio.beginFSK();
radio.setOOK(true);
radio.setFrequency(433.92);
radio.setBitRate(8.2);
radio.setFrequencyDeviation(50);
radio.setRxBandwidth(125);
radio.setCRC(false);
radio.setAFCAGCTrigger(RADIOLIB_SX127X_RX_TRIGGER_RSSI_INTERRUPT);
byte syncWord[] = {0x555,0xE5};
radio.setSyncWord(syncWord, 2);
radio.fixedPacketLengthMode(6);
radio.disableAddressFiltering();
radio.setEncoding(RADIOLIB_ENCODING_MANCHESTER);
radio.setOokThresholdType(RADIOLIB_SX127X_OOK_THRESH_PEAK);
radio.setOokFixedOrFloorThreshold(0x50);
radio.setOokPeakThresholdDecrement(RADIOLIB_SX127X_OOK_PEAK_THRESH_DEC_1_4_CHIP);
radio.setOokPeakThresholdStep(RADIOLIB_SX127X_OOK_PEAK_THRESH_STEP_1_5_DB);
radio.setRSSIConfig(RADIOLIB_SX127X_RSSI_SMOOTHING_SAMPLES_8);
radio.setDio0Action(setFlag, RISING);

[Evil-Optimus]

Unfortunately, I still haven't managed to obtain the raw code for the TPMS sensors.

I can already receive data packets, but when I add the comments from jgromes and what techmike78 included in his code regarding the SPI register of SX1278, I keep getting error messages when compiling in Arduino IDE.

• Module* mod = radio.getMod();

• mod->regdump(NULL, 0x00, 0x39-0x00);

These lines give different error messages that I don't understand yet.

error: 'virtual Module* SX127x::getMod()' is protected

error: 'class Module' has no member named 'regdump' mod->regdump(NULL, 0x01, 0x39-0x00);

If anyone can give me solutions or tips towards possible solutions, I would be grateful. I am definitely going to continue figuring out exactly how all this works, but since I am a beginner with all of this RF, RTL433, ESP32, etc., it will probably take quite a bit of time.

To be continued…

[Evil-Optimus]

I had some problems with the sensor's RAW data. Apparently, I was searching using the wrong ID.
I also had some issues with the Arduino ID serial monitor regarding the binary representation of the RAW readout.
So, clearing everything and starting from scratch seemed like the best solution to me. And yes, now I suddenly saw it.
So I’ve learned something new again. One step closer to the solution.
I’ve found the sensor ID, and now for the rest. See the PDF "01_RAW Code reading lilygo".
I don't quite understand shifting the data in Arduino IDE yet, and I also need to take a good look at the exact position of the pressure, temp, and status, and how much I need to shift them in Techmike78's script.
If the ID is only 1 position to the left in my case, and Techmike's script speaks of 20 bits to the right, then it is clear that I am seeing or misunderstanding something here again.

So, if anyone can give me a tip, I would appreciate your response.

Greetings to everyone and thanks for the help and information.

to be continued...

01_RAW Code reading lilygo.pdf