BMW TPMS

[C Miller]

Hello all!  This is my first attempt at trying to decode a TPMS sensor and I'm stuck.  I followed the instructions here, ANALYZE but can't get past the, "Analyze the data packet".  I have my .ook files and loaded them into https://triq.org/pdv/.  I repurposed an old wheel balancer so I could change pressures and get the most data that I could, but I can't even identify the sensor ID from the data I've collected.  I've attached a zip file that contains three sets of data as well as screenshots of the pdv data using the .ook files.  I also took the 0 and 1's from the pdv results and copied them to bitbench trying different settings but I guess I never landed on the right combination.

I'd really appreciate guidance so I can decode future sensors since I've already got a test bed so I could help collect data if others need it.  The wheel currently has the OEM BMW sensor in it.  Once I have this one decoded I'm going to install an Autel MX-1 sensor so I can program it for different vehicles and collect data if any of that makes sense.

The sensor is 433MHz and I can scan it with an Autel TPMS scanner.  Once the wheel starts spinning, the information is transmitted every 30 seconds.  Photos of each test are in the folders but just in case, this is what I've captured:

Sensor ID: 3BAE30A9, Pressure: 23.6 PSI, Temperature: 8 Deg C

Sensor ID: 3BAE30A9, Pressure: 24.4 PSI, Temperature: 11 Deg C

Sensor ID: 3BAE30A9, Pressure: 27.3 PSI, Temperature: 8 Deg C

The attached zip file contains a folder for each test with 10 samples.

Any assistance would be greatly appreciated.

[Benjamin Larsson]

On 06/11/2023 01:54, C Miller wrote:
> Hello all!  This is my first attempt at trying to decode a TPMS sensor
> and I'm stuck.  I followed the instructions here, ANALYZE

> <https://triq.org/rtl_433/ANALYZE.html> but can't get past the, "Analyze

> the data packet".  I have my .ook files and loaded them into

> https://triq.org/pdv/ <https://triq.org/pdv/>.  I repurposed an old

> wheel balancer so I could change pressures and get the most data that I
> could, but I can't even identify the sensor ID from the data I've
> collected.  I've attached a zip file that contains three sets of data as
> well as screenshots of the pdv data using the .ook files.  I also took
> the 0 and 1's from the pdv results and copied them to bitbench trying
> different settings but I guess I never landed on the right combination.
>
> I'd really appreciate guidance so I can decode future sensors since I've
> already got a test bed so I could help collect data if others need it.
> The wheel currently has the OEM BMW sensor in it.  Once I have this one
> decoded I'm going to install an Autel MX-1 sensor so I can program it
> for different vehicles and collect data if any of that makes sense.
>
> The sensor is 433MHz and I can scan it with an Autel TPMS scanner.  Once
> the wheel starts spinning, the information is transmitted every 30
> seconds.  Photos of each test are in the folders but just in case, this
> is what I've captured:
>
> Sensor ID: 3BAE30A9, Pressure: 23.6 PSI, Temperature: 8 Deg C
> Sensor ID: 3BAE30A9, Pressure: 24.4 PSI, Temperature: 11 Deg C
> Sensor ID: 3BAE30A9, Pressure: 27.3 PSI, Temperature: 8 Deg C
>
> The attached zip file contains a folder for each test with 10 samples.
>
> Any assistance would be greatly appreciated.
>

It looks like it is manchester coded but I cant seem to find the id in
there.

MvH
Benjamin Larsson

[C Miller]

On Sunday, November 5, 2023 at 8:31:58 PM UTC-5 wrote:

It looks like it is manchester coded but I cant seem to find the id in
there.

MvH
Benjamin Larsson

I tried Manchester as well but couldn't get it.  I was looking at the, Introduction to pulse formats and it seemed like it could have been PWM as well but that didn't yield any results either.  Thanks for looking into it, I'm stumped. 

[Christian Z.]

The pulses look good and seem to be MC or DMC. The options then are to invert all bits and to shift by up to 3 bits (when looking at nibbles / hex chars). Then we might need to reflect LSB/MSB (in BitBench: "^8h")

This gives 32 possible strings. None of those match the ID?

[Benjamin Larsson]

I tried everything except reflection.

/Benjamin

[C Miller]

Just so I'm following because I'm pretty confused at this point.  If I change the slicer, I get the following:

MC
0101010101010101110101111111000000001000110100000001100000010110011011010011000010011001010110011

Is this preamble? 0101010101010101

DM

1111111111111110011110000001000000011001011100000010100000111010101101110101000110101011111010100

Is this preamble? 1111111111111110

 

[Benjamin Larsson]

First we have a preamble of level transitions. Then we have a manchester
pattern.
/Benjamin

[C Miller]

On Monday, November 6, 2023 at 9:01:32 AM UTC-5 ba... wrote:

First we have a preamble of level transitions. Then we have a manchester
pattern.
/Benjamin

These would then be level transitions, 0101010101010101, and because it's Manchester, need to figure out if the transitions are on the falling or rising edge?  This is why Christian Z. recommended inverting them?  

I apologize for all the remedial questions; I'm trying to understand.  Thanks for your patience. 

[Christian Z.]

Yes, there is no agreed upon polarity in MC.

The ID seems hard to spot, the best way forward would be to capture lots of codes from a slow progression of either temperature or pressure change. Mark down the start and end of those ranges, but for the values it is only important that the change is small enough to be by a few bits only, best case a single bit (for temp that might be 1 deg and for pressure it might be 1 kPa or 2.5 kPa or such -- aim for smaller changes that this in each code)

Then observe where the fields for those are and how they change. Best case you now know alignment and bit-order. The try to match up the fixed bytes with the ID.

[C Miller]

Okay, I will work on getting the samples.  Thank you again for your assistance and patience! 

[C Miller]

I'm having issues with my test bed, all of a sudden it stopped receiving data.  All I got was one sample and I compared it to one of the previous samples.  These two have different pressure and temperature so don't know how valuable it will be but I can see there are differences in the last 5 bytes.  I'll keep working on the test rig and see if I can figure out why I'm not receiving data.  The TPMS scanner is able to read the sensor data no problem, so it's very strange.

163KPa   8C - 01010101 01010101 11010111 11110000 00001000 11010000 00011000 00010110 01101101 00110000 10011001 01011001 1
158KPa 14C - 01010101 01010101 11010111 11110000 00001000 11010000 00011000 00010100 10011011 11001111 01010000 10101110 1

Thanks again!

[C Miller]

Comparing the two samples I received from my original post, the temperature was the same and gave the following differences, which was just the pressure.  

It looks like the pressure is toward end of the data starting at 'D', correct?

23.6PSI 8C - AAABAFE011A0302CDA6132B3 - 01010101 01010101 11010111 11110000 00001000 11010000 00011000 00010110 01101101 00110000 10011001 01011001 1
27.3PSI 8C - AAABAFE011A0302CD0612D67 - 01010101 01010101 11010111 11110000 00001000 11010000 00011000 00010110 01101000 00110000 10010110 10110011 1

[Christian Z.]

Yes, I guess it is the usual order of state, ID, pressure, temp, checksum. But we need the small changes to pinpoint the last bit and align the fields.

[C Miller]

I saw that the BMW decoder has been added, thank you!  I'm still trying to figure out how the data was discovered.  Through some trial and error, I have extracted the raw bitstream from a CC1101 chip I'm playing with.  Is there a way to extract the raw bitsream that RTL_433 is receiving?  I'd like to confirm the RTL_433 and my CC1101 raw bitstreams are the same so I'm not chasing my tail.  What is the next step in trying to discover the actual data.  If I copy my raw bitstream into bitbench, it's not really making any sense, even when following along the process used in the tpms_bmw.c file, manchester_decode then invert.  I apologize for the elementary questions, I'm really trying to understand the process, I have several other sensors I'd like to contribute solutions for.

This is my raw bitstream that I captured from my CC1101, up sampled 8x and then down samples into bits, which matches the data captured from URH.  I think I'm on the right track to have the correct raw data.  RTL_433 captured the signal and it was decoded correctly.

BMW X7 12/2018-07/2022 (433Mhz)
ID: 50AD7489
Pressure: 0.0 Psi
Temp: 71F
Battery: OK

Preamble - 010101010101010

Sync (0xAA59) - 1010101001011001

Begin Data - 0101010101011010011001100101010110011001101001100110101001100101100101011001011001010101010110100110010110011001010101010101010101011001010101011001100110010110010110100101010111111111

Kindest regards.

[Christian Z.]

Is there a way to extract the raw bitsream that RTL_433 is receiving?

You can use :v for verbose output with any decoder, e.g. rtl_433 -R 252:v -R 257:v will enable both decoders verbose and print the received codes.

[C Miller]

That's perfect!  My bitstream is matching what RTL_433 is finding.  I guess learn how to use bitbench is the next step?

Thanks again!

[Christian Z.]

Here is a BitBench example with your data:

https://triq.org/bitbench/#c=y0101010101011010011001100101010110011001101001100110101001100101100101011001011001010101010110100110010110011001010101010101010101011001010101011001100110010110010110100101010111111111&f=BRAND%3A8h%20ID%3A32h%20PRES%3A8d%20TEMP%3A8d%20WARN%3A8h%20SEQ%3A8h%20NOMI%3A8d%20CHK%3A8h&z=1&d=MC&cw=4

[C Miller]

Thank you!  I'm beginning to understand, a little bit.  

I did figure something out, the NOMI (Flag 3) seems to be the battery OK/LOW byte.  The test I did:
3v3 = 169 (OK)

~2v25 or less = 129 (LOW)

I need to somehow rig up my wheel balancer to let the air out while it's spinning to see what the values do.

Off to try and decode a RAM 2500 TPMS signal.  I think I'm still drowning but going to give it a shot.

Thanks again for all your help, really appreciate it.

Kindest regards.

[Christian Z.]

Yes, those 3 "flags" bytes are not well understood. It's great that you are experimenting and getting some plausible results!

169 and 129 are 10101001 and 10000001. So two bits actually flipped for low battery.

Feel free to open an issue at https://github.com/merbanan/rtl_433/issues and post samples. Very likely there is someone to help.

[Christian Z.]

there's a company , LDL or Lid technologies,

They have tpms protocols used in the motorsports circuit racing industry.

the flags they have are emission cause..
low rf trigger, or rolling operation , might be worth investigating.

Yes, we sometimes see flags for e.g. acceleration -- but is hard to find them when "dry testing". Nice to see that OP seems to have some nice rig for testing TPMS while spinning!

[C Miller]

Yes, after further testing, Flag 3 is an interesting situation.  It also goes to a 1 and back to 0, depending on what's happening.  More investigation will be needed.  I haven't been able to create a situation that is a cause for some kind of alarm yet.  I'll keep trying, it's fascinating trying to figure this stuff out but also extremely frustrating.  I'll run more tests and get consistent results before posting anymore findings.

Thanks again.