tpms_rx with non-integer-divisible-by-8 crc check bits?

[xnk]

Having decoded the Pacific TPMS sensors as used by Toyota (at 314.98MHz) the total number of bits are 66 with a CRC8 calculated over the first 58 bits. The protocol matches the 9910bps FSK modulation in tpms_rx with preamble 00111111001 but the length in packet_check is set to 64 (with a note that some fraction of packets are 68 bits long). Changing the length to 66 and adding the correct check function does not yield a successful decode however and I think this might be related to having a non-integer-divisible-by-8 check length?

{
'modulation': 'fsk',
'access_code': '00111111001',
'encoding': 'diffman',
'prefixes': ('',),
'length': 66,
'range_data': (0, 58),
'range_check': (58, 66),
'check_fn': crc8(polynomial=0x13, init=0x0),
}

If anyone's interested in the format used by Pacific see https://github.com/xnk/pacific-tpms for more information. I'm trying to figure out a way to get tpms_rx to successfully decode this.

[jboone]

Sorry for the delay, I have too many projects to keep track of...

Anyway, cool work! I would raise the possibility that the packets are still a multiple of 8 bits, and you just need a larger body of good packets to get a reliable assessment of the alignment and CRC polynomial. There were many times where I thought a packet payload was not a multiple of 8, but further digging and more data demonstrated that I was wrong, or that the packet didn't use any substantial form of checksum or CRC (looking at you, Schrader/Subaru 37-bit packets).

Do you have insight of how long the IDs are for these sensors? Are they printed on the case, ideally as hex?

Have you done a statistical analysis on a variety of captured packets (many vehicles), qualified/grouped by preamble, to see if there's regions of the packet that are invariant (status fields, preambles), apparently random (checksum or CRC), and physical measurements (bell-ish curve distribution of values over the range)?

[xnk]

Hey! I’m in the same boat with regards to having a lot of projects - no worries! I haven’t done any super detailed statistical analysis, but the fact that my synthetic packets are being accepted by the car seems to indicate that at least the actual receiver hardware only cares about 66 actual bits. I recorded a few hours both while driving and while parked, very few packets (less than 0.1%) does not pass the CRC check (due to noise into the demodulator most likely, or collision). When investigating it eventually became obvious where the tire pressure (plus the inverse copy) and temperature were located. Additional battery low/sensor fault bits weren’t found until I could inject packets back into the TPMS ECU to see the actual results. I only have one car with this system but I have tested with the five sensors shipped with the car (4+spare) and I bought 4 additional used/refurb sensors off eBay for the winter tires, which is what started this whole investigation. All nine sensors verify at different tire temperatures and tire pressures so I’m fairly confident about the CRC at this point. The ID is listed in hex on the sensors, and that is 7 digits long, which matches the 28 first decoded bits. (See my attempted description here: https://github.com/xnk/pacific-tpms) I can add a fake sensor to the TPMS ECU in the car (using the Toyota diagnostics tools) and then fake that 28-bit hex ID using my HackRF One and the car diag software will happily accept it as a real sensor.