Analysizing data from Aston Martin 433MHz Smartire TPMS

[MatthewRuddy]

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

[zuckschwerdt]

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. Use a decoding of MC with 167 / 167. Note that there is a 3 half-bit desync at the start.

Try a flex decoder like this and record some changes in temperature or pressure to spot those data fields. rtl_433 -R 0 -X 'n=name,m=OOK_MC_ZEROBIT,s=167,l=167,r=600' The data from e.g. your first sample is {56}518c001e187f4b.

[MatthewRuddy]

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 rtl_433 -R 0 -X 'n=name,m=OOK_MC_ZEROBIT,s=167,l=167,r=600' and recorded two scenarios. One with the sensor just sitting on a table, and another with me spinning it around in a circular motion (to simulate a wheel). When spinning it, upon reading with the Autel TPMS programming device it showed 40kpa pressure. It seems moving the sensor around triggers it into providing a KPa value other than 0.

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): on-table.txt

Spinning in circular motion (40kpa): spinning-around-40kpa.txt

[MatthewRuddy]

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 17489.

I can see a bit of a pattern - the code/data repeats with 518c001e187f4b every 1, 3, 5, 7, 9 times, etc. This never changes. That's as far as I've been able to figure out with my limited knowledge.

another-test-70kpa.txt

[ProfBoc75]

@MatthewRuddy

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:

 rtl_433 -R 0 -X 'n=Aston-Martin-Smartire,m=OOK_PCM,s=167,l=167,r=600,preamble=32,decode_dm,get=id:@20:{16}'

from g012_433.92M_250k.cu8: 5 x times these values

{51}52800445103ba --> Fixed value, even with the other flex decoder and your text files, always same value
{51}53f404451011a

from g013_433.92M_250k.cu8: 5 x times these values

{51}52800445103ba --> Fixed value, even with the other flex decoder and your text files, always same value
{51}54040445100ea --> Few values changed, same from your text files, second message values changed a little.

For each transmit, you have 10 messages. ( Message A then B x 5 times ) Now, I'm not sure about the preamble, I can't find any CRC, so probably a checksum from these data to guess.

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)

rtl_433 -R 0 -X 'n=Aston-Martin-Smartire,m=OOK_PCM,s=167,l=167,r=600,preamble=32,decode_dm,get=id:@14:{22}'

We can get the ID from 24 bits with get=id:@12:{24} but the second message B the ID is not the same.

bitbench

[MatthewRuddy]

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:

5 31 58 96 7f 02 e2 [ID 1611391, 0x31 = 49 - 40 = 9c, put in fridge for 5 mins, 0kpa]
5 14 58 96 7f 03 e2 [ID 1611391, 0x14 = 20 - 40 = -20c, put in freezer, 0kpa]
5 27 58 96 7f 01 7a [ID 1611391, 0x27 = 39 - 40 = -1c, out of freezer warmed in hand 2 mins later, 0kpa]
5 2f 58 96 7f 00 02 [ID 1611391, 0x2f = 47 - 40 = 7c, still warming up, 0kpa]
5 3a 58 96 7f 00 3a [ID 1611391, 0x3a = 58 - 40 = 18c, warmed up in hand again, 0kpa]

I did notice that in the above strings, the ID parts are missing a leading 1. ID 1611391 = 18967F but I'm only seeing 58967F here. The max ID I can program is 9999999 (7 digits) FYI. 8 digit IDs are not supported (can't be programmed by the Autel reader).

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.

[ProfBoc75]

@MatthewRuddy

I guessed the data layout, at least the first part, missing the checksum not yet decoded.

bitbench:

? 4h TEMP/PRESSURE 8d MESSAGE_TYPE 2b ID 22d FLAG ? 4b CHECKSUM ? 8h TRAILING ? 4h

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 ? And not only able to program but also able to read the ID 9999999 from your Autel device. As for me the max is 4194303 / 0x3FFFFF (22 bits)

About the data layout, could be: Message A (type b00) = Pressure offset 40, Message B (type b01) = Temp, offset 40.

More details here: Bitbench

[MatthewRuddy]

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 X - 40 = Y * 2.5 = Z, Z being the KPa value. Similar to the datasheet above, but with an offset like the temperature of -40. Here is a couple of values I recorded:

5 37 18967f 03 d2 (0x37 = 55) ((55 - 40) * 2.5 = 38kpa)
5 42 58967f 01 c2 (0x42 = 66) ((66 - 40) = 26c)

548 18967f 02 22 (0x48 = 72) ((72 - 40) * 2.5 = 80kpa)
543 58967f 00 a2 ((66 - 40) = 27c)

5 56 18967f 00 c2 (0x56 = 86) ((86 - 40) * 2.5 = 115kpa)
5 43 58967f 00 a2 ((67 - 40) = 27c)

5 64 18967f 03 3a (0x64 = 100) ((100 - 40) * 2.5 = 150kpa))
5 41 58967f 02 62 ((65 - 40) = 25c)

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) 👍

[ProfBoc75]

@MatthewRuddy :

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)

Done with g 0c k 0c final XOR ae using xor xor (100 %)
Done with g 8a k 8a final XOR 28 using xor xor (100 %)
Time elapsed in s: 0.03 for: Rev-Galois BYTE_REFLECT

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. Notice that a normal pressure around 250 kPa could also trigger flag.

bitbench updated with your last findings

[MatthewRuddy]

@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 rapid-increase.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 -W flag and can upload those files if also useful? They're quite large, 33mb and 66mb respectively.

[ProfBoc75]

@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.

[zuckschwerdt]

quite large, 33mb and 66mb respectively.

Perhaps best to upload such big files somewhere else, e.g. some free file hoster.

[MatthewRuddy]

Here are files for above tests. Still waiting to do in-car tests. :smile: https://www.dropbox.com/scl/fi/sscc3tu37djqvvtocb72f/rtl_433_rapid_increase_decrease.zip?rlkey=0aloumt77t3z6j9aq7pdlvrc2&st=vo23uat1&dl=0

[ProfBoc75]

@MatthewRuddy

Some findings and good news, I guessed the CRC and found Fast Pressure Increase Flag position, but still needs some clarification.

• The message is based on 6 bytes, but missing the last bit, expected 48 bits, and we have 47 bits.
• Looking at the last byte and the 2 or 3 last bits (LSB), they are always xxxxx01 (7bits) or xxxxx010 (8bits), but I found a CRC-7 here, poly 0x45, init 0x6f , final xor 0x00.
• Looking before last byte, the first MSB bit is Fast Pressure Increase flag, the last 2 LSB bits are may be linked to CRC or Parity or XOR ???, here the issue, because of the 2 or 3 last bits of the last byte are always the same, these 2 last bits could be part of CRC (MSB/LSB ?), but in that case I'm not able to find the algorithm. And these 2 bits are not linked to a flag behavior at Temp nor Pressure level, but previous bits for sure, like a checksum.

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

[ProfBoc75]

@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.