New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BMW Gen5 TPMS support #2821
Comments
It's basically the same. MC can't reliably discern the timing of the short transitions until the first long one. |
Does it make sense then calculated CRC for stripped data:
? |
With bitbench I am able to guess:
Should I investigate more or could I try to prepare decoder? |
0xaa as init seems much nicer than 0x40. And we usually expect a preamble. The resulting raw |
Looks good already. You might be missing the alarm flags like rapid deflate, low battery and diagnostics as spinning, triggered, ... |
I tried to guess couple more columns - bitbench, but some of them are hard for me to verify. I'm using diagnostic tool as reference: What should be the next steps? |
PR a decoder if you like :) Look into the other TPMS decoders and copy one that looks clean and simple. |
Hi @petrjac : try to increase the pulse to 27 instead of 25 and you will get the 0xfff, if you reduce to 24 you will get the 0x000 |
That's unexpected. For MC we don't need an exact timing and the slicer should always match. Does this slight change somehow match/ignore the first "bit"? That would change the assumption about 000 vs fff. |
When trying with
|
Thanks for confirming! That does not seem right, we need to look into that. I can try to rewrite the MC slicer with that nice example we have here. |
Hi @zuckschwerdt , @petrjac : FYI, I drafted a decoder, and started listening to the cars passing on my street. Sounds like the bitbench is not exactly as expected, I need to consolidate my findings in a table and back here soon. About the rf decode part, I'm using FSK_PCM, s=l=25, r=100, then looking for preamble = 0xaa59 then MC decode + Invert. Data Layout :
The pressure values, I'm not able yet to find a simple formula to convert value into kPa or PSI , I need more samples for that. Notice that the captures from Airspy @ 10MHz are not readable by rtl_433 (no error, but only partial value), only the 2.5MHz give expected results with |
@ProfBoc75 you are faster than me :), I was planning to write decoder on the weekend. I'l be happy to help you at least with my findings:
|
I noticed also that , depends on the first byte , Manuf/Brand, the coding is not the same, And for 0x80 (128) sounds to be Continental model. There is another discussion here where the data packet is also 11 byte The RF part is not the same (not Manchester coded), but the data formatting sounds to be very close, just not information in the same order as Brand HUF (0x03). if we guess all the formula and with DATA_COND, we may be able to handle these 2 Brands. Edit : looking at the RDC Production information guide (page 20, 3. Operation picture) , the third brand could be "Schrader" trademark of "Sensata", and I notice that from my street :
|
FYI, it takes time to collect metrics and to deep dive, since I'm trying to manage the 3 brands in the same decoder, and not so much cars in my one way street. At least the brand 0x03 / Huf Gen 5 is ok for me without the flags decoding which require some work, we don't know which bit is related to battery, fast deflating and so on ... |
In diagnostic sw data I have found more manufacturer for TPMS:
However I cannot be sure that list is correct/complete. On the weekend I'll try to receive signals from HUF sensors to confirm temperate, pressure and maybe also alarm tags. Interestingly the RDCi gen 5 sensors should also send tire size ... |
Hi, I collected some data from the street : I kept the original order to get the sequence number increasing if any.
|
Hi,
|
I'm already looking into The minmax discriminator is default on 868 MHz where most TPMS are. It does not work too well for 433.92 MHz, usually OOK. Try to convert some of your signals to OOK (with FSK proper name would be mark/space not on/off...) and look how noisy the resulting pulses are. E.g. g018_433.92M_2500k.ook
|
OK, thank you for clarification:). This is probably due unappropriate Soapy params for Airspy R2 |
Checked with :
After MC decoded , missing 1 bit to be a valid message, expected {88} bits, 11x8 , so the message is too short and excluded. I tried to go further and the CRC failed.
Good for brand 0x03, HUF, sounds like brand 0x80, Continental, the temp is DEC - 50, we need feedback from Continental valve owners to confirm that.
From your bitbench, the pressure is clearly = DEC * 2.5 (kPA) or DEC * 0.025 (Bar) , as most of TPMS sensors. We saw that from other TPMS decoders , value can be coded like that : (DEC - x ) * 2.5 to get the figures.
rtl_433 is receiving 3 signals, so each one are decoded.
From the RDC tool guide, the temp should be taken into account in the normal pressure, + 0.1 bar / + 10 °C , so may be the temp is not same too ?
I don't understand your point, it's properly decoded with |
What bmw part number TPMS this refer? |
For Huf gen. 5 the P/N is 36106877937. |
Hello again, I recorded several samples with BMW Gen4 sensors. The message format looks similar to Gen5 sensors and also samples collected by @ProfBoc75. Here is bitbench with decoded data. I was also able to compare data with official diagnostics. Notes:
|
Hi @petrjac: Thanks for this feedback, can you try with this option I'm not able to decode your last 4 x CS16 files. |
@ProfBoc75 I tried this... would this be useful?
Demodulated signal looks like this in URH: Raw hex is |
I fact, I wanted you to run rtl_433 in live to see if you are able to get some answers, and I put verbose information in the decoder itself, like data before and after MC, so we can see where it failed and it could help me understand. This option
you may test with auto gain with From your 4 samples, rtl_433 is not able to decode,
But from your last raw hex information, it looks like it should work, we can replay with rtl_433 like this:
Edit: So for me, apart from the version/generation 4 to be taken into account, it's a signal reception problem to be tuned, playing with the gain and your LNA / MIX / VGA levels or |
@ProfBoc75 Thank you for your comment. You are right, the signal is obviously clipping:). I've been adjusting the gain settings and also forgot to set Should I upload some samples or try something else? |
Yes, you can upload few other samples into rtl_433_tests with your other gen4 files. Update the README file with pressure and temp details for each file. I would like to check if we can identify the gen 4 from them compare to other gen 5 files. |
@ProfBoc75 I pushed some new samples which can be read (the signal is still noisy and weak though). I also added JSON with data from diagnostics. The |
Howdy, So far this is what I get in URH, Any help is greatly appreciated, thanks. |
@Billymazze : For BMW you need to set modulation to FSK and pulse at 25 µs. For Abarth same FSK but pulse is 52 µs. |
Could clarify where I need set those values? Do you mean on the flipper zero or in URH recorder? Sorry I'm idiot. |
I don't know for flipper zero but for URH you should have modulation option = FSK and the samples/symbol to be adjusted until you have some codes starting with aaaaaa59 or 5555555. I guess you are not so far since the length is little more than 208 bits (after aaaaaa59 preamble) like from your samples. |
Alright, I'll give that a shot. Any chance the issue is my recoding settings on URH? I recorded these signals with an RTL-SDR (Realtek RTL2838UHIDIR) @433.92mhz with a sample rate of 1.0M, bandwidth of 1.0M, gain of 49, bias tree disabled, and direct sampling disabled. Having issues installing rtl-433, but maybe it's necessary that I get it working. |
Also forgot to mention these signals I've captured are from a Gen 3 bmw tpms system, 2011 bmw x5 35d. |
@Billymazze the protocol for Gen 3 could be different. Are you able to get TPMS reference data from diagnostics (ISTA)? Can you provide some samples recorded using URH? |
I don't currently have access to ISTA D, but I will soon. Currently there's a google drive link in my first post, here. I collected signal with URH and With the flipper zero. I'm not 100% sure my recoding settings are correct, especially gain level. But I can replay the signals and trigger the TPMS warning light with the flipper zero. |
It looks that gen3 protocol differ from gen4/5. I'm not able to find any sense in there ... The ISTA/D would help, you could also try Android Ediabas app. Since the protocol for gen3 differs you can consider open separate issue. |
Alright, I'll create a new issue. |
At first great job guys! 👍 I recently retrofitted car with Autel MX-2 TPMS sensors and started playing with Noelec RTL-SDR. Would you like to rewrite BMW_Gen5 to include Audi (with if, else, case) or it is better to create new device for this brand? |
@Gucioo: Thanks for your finding ! Yes, I can update later this week the existing decoder to take into account the specific brand with shorter message without the 3 flags. |
Done, last version should decode Audi TPMS, don't hesitate to give feedback here. |
I wasn't quick enough to get back to you with the latest finding, but Audi seems to be a bit specific with TPMS implementation. BMW and Audi responds different on different trigger. https://imgur.com/a/9JH5Iir
During normal operation (in motion) Audi sends 11 bytes with id 88, when it gets sudden pressure loss it sends 11 bytes with id 88. Some exception would be needed to cover this changing length. When there is sudden pressure loss, it burst frames each second, maybe thats why they decided to reduce message length, to save on energy, but who knows?! I've also noticed the same sensor is used with A3, may be worth adding to header.
I would like to thank JSMSolns for his help to implement this protocol that he made under his Arduino TPMS Tyre Pressure Display. |
It works fine now. -s 1000000 is required to decode properly, on standard sampling rate is not working. The only thing, it would require ID update according to my previous comment:
|
@Gucioo : Very interesting ! My update is still valid but yes for this specific situation of fast deflating, and probably related to the behavior of this kind of sensor than to Audi. In my street scanning, I found one message with 0x88, unknown until now, so I will update the decoder with this brand link to Audi. I will check also JSMSolns projects to see if we have some other findings there and may be some answers related to the flags we didn't guess for BMW. Edit: JSMSolns likes also rtl_433 😄 .... for you Christian @zuckschwerdt
|
To summarize:
I'm preparing an update to the decoder and will commit soon. |
Yes, that's correct. |
Does this sensor need to receive any data to start sending pressure and temp? |
@luki343 Depends on brand model and the behavior could change between static / parked situation where the sensor is in standby mode to preserve the battery and from moving where the sensor can also send some kinetic information into one of the 3 flags. You may be interested in this Arduino project which is already handle BMW model. You may have to cross check if they updated it with our last update with Audi model and Audi pressure alert. |
@ProfBoc75 I need to adapt some TPMS to my "race car" and send it to ECU via CANbus, so the easiest way will be to use one of the currently decoded sensors, but if it needs to receive some message from car, I'm lost. I will definitely check out this project, thx |
Hi,
I'm trying to decode BMW Gen5 TPMS sensors.
I recorded several samples using Airspy R2 SDR - https://github.com/merbanan/rtl_433_tests/pull/463/files .
I was able to read raw data using URH and resolved CRC-8 as
poly=0x2f init=0x40
:However with rtl_433 I'm getting different results:
Binary data started with
0x000
instead of0xfff
.Could please someone help with verifying data before proceeding?
The text was updated successfully, but these errors were encountered: