Analysizing data from Aston Martin 433MHz Smartire TPMS #3067
Comments
|
Try the sample file on https://triq.org/pdv/ -- it's quiet slow (for a TPMS) at 167 µs a half-bit, 6 kBps. And it uses OOK -- we normally see FSK at 50 µs. Try a flex decoder like this and record some changes in temperature or pressure to spot those data fields. |
|
Thanks for your reply @zuckschwerdt. I'm afraid I'm out of my depth here so I will have to figure out what most of that means 😅 I would make sense for the system to be slow - it was developed in the early 2000's and is known to be pretty mediocre. I ran The Autel is showing NA when trying to read the temperature, so I can't confirm that value. It's likely ambient temp, which today was somewhere between 20-25c. I do believe these sensors do transmit temperature, or at least the Smartire system has a built in temperature warning when a single tyres temperature reaches 170F/75c (or around that number). On table (no movement): Spinning in circular motion (40kpa): |
|
Another test later this evening. A few 0KPa reads, then a 70KPa read. All triggered via the Autel TS408 TPMS reader, and the later 70KPa reading by me again moving the sensor around quickly. Before this latest test, I reprogrammed the sensor, but it appears to have the same ID as reported by the Autel reader. It reports the ID as I can see a bit of a pattern - the code/data repeats with |
|
Decimal ID = 17489 => 0x4451 = Hexadecimal ID, if you try the bellow command I found 0x4451 in the middle of the data from your cu8 files: from g012_433.92M_250k.cu8: 5 x times these values from g013_433.92M_250k.cu8: 5 x times these values For each transmit, you have 10 messages. ( Message A then B x 5 times ) Try other TPMS sensors to see if you can identify the hexa values into the codes with my command. Edit: I found from videos that the id is 6 nibbles coded - 3 bytes / more than 16 bit (Vantage Smartire / Aston Martin DB9 protocol, from 1/2005 till 12/2011). This will get the ID from 22 bits: (2 first bits are excluded because the ID is not same in second message B) We can get the ID from 24 bits with |
|
Thanks @ProfBoc75 that's really helpful and made some good progress. ID is correct - I've been able to reprogram a spare sensor with custom IDs and each time it's been correct. I've also figured out the temperature reading has an offset of 40, so figured out this much: I did notice that in the above strings, the ID parts are missing a leading 1. ID I'm still unsure on pressure. Can't find a correlation. The chip in this TPMS is a Sensornor SP11A, but I can't find any datasheets/documentation about it. I have found the datasheet on a newer variant of the IC used in another TPMS sensor, which might give some clues (it gave me the -40c offset for temp). It uses the SP13 version of the chip, which is 6/7 years newer - https://www.alldatasheet.com/datasheet-pdf/view/208717/MICROCHIP/AN238.html. The sensor is also transmitting some sort of battery/voltage status. |
|
I guessed the data layout, at least the first part, missing the checksum not yet decoded. bitbench: Message_type is 2 bit flags, 00 or 01 The ID is 22 bit coded and it match with your new ID, just to confirm, did you try to set ID 9 999 999 ? About the data layout, could be: More details here: Bitbench |
|
Thanks @ProfBoc75 - you're correct. I was actually writing a response as you posted! :) I put the sensor inside a garden pressure sprayer and was able to simulate pressures. Using the data below, I've figured the formula is I was able to confirm these with the Autel reader. Nearly there! Very promising, although unusual it comes as two messages. I will try 9999999 as an ID - you're probably correct here. Update: Yes the max sensor ID value is 4194303 (0x3FFFFF) 👍 |
|
Can you please share other samples, as I need more to guess the checksum, I'm close to the good one, 2 possibilities for the moment guessed with revdgst, but I'm not sure about the exact position of the checksum, looks like it could be shifted a little, the flags before it could be less with 4 or 6 bits then the checksum (see the bitbench below) Another point, we need more use cases, like: fast pressure increase, fast pressure decrease, low bat, and rolling wheel to identify some flags somewhere into the data layout. bitbench updated with your last findings |
|
@ProfBoc75 I will try get some more in-car readings for you over the weekend. Might be difficult as only one sensor currently works (they're all 14 years old!). The sensor I've been testing with isn't installed. I'm still using the garden pressure spray bottle to simulate the increase and decrease in pressures. I'm not sure if this is useful. Here are the results. The highest I can get it to go is 235/240kpa. rapid-decrease.txt I had to use the Autel reader to trigger these readings as the sensor itself doesn't seem to transmit data very often (possibly because it's not rotating). I ran the commands with |
|
@MatthewRuddy: if you recorded files, you can zip them into single file and upload here as you did already. This will let me test them / replay the files. |
Perhaps best to upload such big files somewhere else, e.g. some free file hoster. |
|
Here are files for above tests. Still waiting to do in-car tests. 😄 https://www.dropbox.com/scl/fi/sscc3tu37djqvvtocb72f/rtl_433_rapid_increase_decrease.zip?rlkey=0aloumt77t3z6j9aq7pdlvrc2&st=vo23uat1&dl=0 |
|
Some findings and good news, I guessed the CRC and found Fast Pressure Increase Flag position, but still needs some clarification.
About behavior, in case of fast pressure increasing a single message is sent with the flag to 1 and pressure value, following 10 messages with the new pressure / temp, still flag to 1, and sent every 1.5 or 2 seconds. When the pressure is stable, the flag disappeared, and message sent less often. I did not see flag when pressure decreased. Bitbench updated |
|
@MatthewRuddy , I created the pr #3072 with a draft version of the decoder, which is working from my side with your sample files. Please, test and let me know here or into the pr if you have any findings/improvement or correction. |
|
Thank you @ProfBoc75, I will test this as soon as I can. Will share any findings. I finally managed to get in-car driving data. This is from a 10 minute drive, with some traffic: driving.txt. I forgot to run -W, my apologies. I think it's actually plausible that two of the sensors are working - I'm unsure (IDs |
|
We have 2 new types into your last driving.txt file, across 3 IDs.
Sorted by Sensor ID then Date Time.
Looks like the message type is repeated in same order, in sequence. 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 3, 2, 3, 0, 0, 0, 0, .... No sure if you were always driving during the capture, but the message 2 & 3 are very few compare to the 0 & 1 messages more frequent. |
|
That is odd, I'm not sure what these values could be. The box/device that receives the signals and triggers dashboard errors provides limited information. Maybe it's a clue? The only errors it seems to provide are:
When any of these are triggered, the dash says "Tyre System Fault" and you have to refer to indicator LEDs on the box/device to determine which tyre is the culprit. TLDR, it's really old school. I stopped during the drive maybe 3 times for more than 20 seconds (traffic and lights). Otherwise, didn't reach over 60kph. Will try get some more data when possible. I'm also going to remove the box/receiver device from the car (when possible) and see if I can replay some of these commands and trigger the error states to simulate these scenarios. This may be helpful. |
I have been trying to reverse decode the TPMS sensors for a 2008 Aston Martin, which uses a Smartire system with 433MHz TPMS sensors. I have no doubt they're similar to something already decoded with rtl_433, but can't quite figure out which sensors they are most like. I'm also pretty new to this!
I've been able to capture some data when running
rtl_433 -S unknown, which I've attached. The sensors I'm using isn't inside a tyre, so it will be reading 0/1kpa, FYI. Temperature should work. I have an Autel TS408 TPMS programming device, which can activate the sensor remotely, which I'm doing to capture the data here with a Nooelec NESDR Smart V5 and an antenna.Can anyone help point me in the right direction? I'm sure this sensor is similar to something already figured out here.
Thanks.
g012_433.92M_250k.cu8.zip
g013_433.92M_250k.cu8.zip
The text was updated successfully, but these errors were encountered: