TPMS and Schrader

[helmarw]

i have trouble getting sensor reading of standard Schrader TPMS sensors (434MHz)
a bit strange since they a very commonsense , mostly Fiat-Chrysler (eg. my Dodge) and Mercedes aso
I compared its simultaneously with an rtl-sdr using "rtf_433 -C is -R 60" and trigged the sensor
with the original TPM-RKE Analyzer (Miller Tool 9936). both show the same sensor obviously.
hackrf/portapack does nothing :/
Of course I uses a 433MHz Antenna and I tested other parts of the firmware first, e.g. FM Radio is working, SD is in ... and when I go to Spec-View I can see the pulses emitted from the sensor too, so I think something is off with the decoding or the TPMS pulses or whatever, not sure myself.
I attached a few pics

and a video
IMG_5600.mp4.zip

[helmarw]

btw in case someone is wondering, in general the TPMS App is working, just not with Schrader kompatible Sensors. While i was driving home i left it on and after 40min drive it found a couple of sensors from passing by cars. None of them are mine!

[helmarw]

for your convenience, i managed to record the BB of one of my sensors (ID 7AA9016)
i replayed it with portapack and decoded the sensor readings with my rtl-sdr and the program rtl_433. Also my Miller Tool recognised the playback. If you want to try it out dont put the LNA to high, it will saturate the receiver. i used 16 or 24, more than enough and about 50-100cm distance between the two antennas
BB_record_Schrader.zip

[helmarw]

an other piece of the strange puzzle. i found the tpms logfile on the sd card. it clearly shows
that all the sensors i logged according to the screenshot and are logged as Schrader
tpms.txt
something is not right here :/

[helmarw]

since i dont know yet how to debug the portapack software im adding some more
information about the ignored TPMS Sensor i gathered from rtl_433, maybe someone else can put its to use. If you need anything else i can help with please drop me a line

model : Schrader type : TPMS flags : 00 ID : 7AA9016
Pressure : 2.5 kPa Temperature: 26 C Integrity : CRC
pulse_demod_manchester_zerobit(): Schrader TPMS
bitbuffer:: Number of rows: 1
[00] {68} 7f 00 7a a9 01 60 14 c8 e0
Pulse data: 54 pulses
[ 0] Pulse: 100, Gap: 25, Period: 125
[ 1] Pulse: 34, Gap: 24, Period: 58
[ 2] Pulse: 38, Gap: 26, Period: 64
[ 3] Pulse: 35, Gap: 25, Period: 60
[ 4] Pulse: 36, Gap: 26, Period: 62
[ 5] Pulse: 68, Gap: 25, Period: 93
[ 6] Pulse: 36, Gap: 56, Period: 92
[ 7] Pulse: 35, Gap: 27, Period: 62
[ 8] Pulse: 36, Gap: 25, Period: 61
[ 9] Pulse: 35, Gap: 25, Period: 60
[ 10] Pulse: 38, Gap: 25, Period: 63
[ 11] Pulse: 34, Gap: 28, Period: 62
[ 12] Pulse: 34, Gap: 26, Period: 60
[ 13] Pulse: 36, Gap: 26, Period: 62
[ 14] Pulse: 36, Gap: 26, Period: 62
[ 15] Pulse: 67, Gap: 25, Period: 92
[ 16] Pulse: 35, Gap: 27, Period: 62
[ 17] Pulse: 34, Gap: 28, Period: 62
[ 18] Pulse: 35, Gap: 55, Period: 90
[ 19] Pulse: 67, Gap: 57, Period: 124
[ 20] Pulse: 66, Gap: 57, Period: 123
[ 21] Pulse: 66, Gap: 58, Period: 124
[ 22] Pulse: 66, Gap: 56, Period: 122
[ 23] Pulse: 35, Gap: 26, Period: 61
[ 24] Pulse: 68, Gap: 55, Period: 123
[ 25] Pulse: 37, Gap: 24, Period: 61
[ 26] Pulse: 37, Gap: 25, Period: 62
[ 27] Pulse: 36, Gap: 27, Period: 63
[ 28] Pulse: 34, Gap: 26, Period: 60
[ 29] Pulse: 36, Gap: 27, Period: 63
[ 30] Pulse: 35, Gap: 25, Period: 60
[ 31] Pulse: 67, Gap: 57, Period: 124
[ 32] Pulse: 65, Gap: 27, Period: 92
[ 33] Pulse: 36, Gap: 54, Period: 90
[ 34] Pulse: 40, Gap: 23, Period: 63
[ 35] Pulse: 35, Gap: 27, Period: 62
[ 36] Pulse: 37, Gap: 24, Period: 61
[ 37] Pulse: 36, Gap: 26, Period: 62
[ 38] Pulse: 35, Gap: 25, Period: 60
[ 39] Pulse: 38, Gap: 25, Period: 63
[ 40] Pulse: 35, Gap: 26, Period: 61
[ 41] Pulse: 67, Gap: 58, Period: 125
[ 42] Pulse: 66, Gap: 55, Period: 121
[ 43] Pulse: 35, Gap: 26, Period: 61
[ 44] Pulse: 69, Gap: 25, Period: 94
[ 45] Pulse: 34, Gap: 56, Period: 90
[ 46] Pulse: 37, Gap: 25, Period: 62
[ 47] Pulse: 68, Gap: 56, Period: 124
[ 48] Pulse: 35, Gap: 27, Period: 62
[ 49] Pulse: 34, Gap: 26, Period: 60
[ 50] Pulse: 67, Gap: 25, Period: 92
[ 51] Pulse: 37, Gap: 25, Period: 62
[ 52] Pulse: 37, Gap: 56, Period: 93
[ 53] Pulse: 33, Gap: 2501, Period: 2534

seems to me when looking at rtl_433 there are two version of those TPMS
"Schrader" and Schrader EG53MA4, the EG53MA4 is what im using, so there might be a
difference which was not considered yet in portapack ?!

some information about that sensor here (i assume its Sensor B afaik):
https://elib.dlr.de/81155/1/TPMS_for_Trafffic_Management_purposes.pdf

from: rtl_433/src/devices/schraeder.c

r_device schraeder = {
        .name        = "Schrader TPMS",
        .modulation  = OOK_PULSE_MANCHESTER_ZEROBIT,
        .short_width = 120,
        .long_width  = 0,
        .reset_limit = 480,
        .decode_fn   = &schraeder_callback,
        .disabled    = 0,
        .fields      = output_fields,
};

r_device schrader_EG53MA4 = {
        .name        = "Schrader TPMS EG53MA4, PA66GF35",
        .modulation  = OOK_PULSE_MANCHESTER_ZEROBIT,
        .short_width = 123,
        .long_width  = 0,
        .reset_limit = 300,
        .decode_fn   = &schrader_EG53MA4_callback,
        .disabled    = 0,
        .fields      = output_fields_EG53MA4,
};

[eried]

Which lines from that tpms.txt actually appear in the portapack? Maybe the length of the data is different? In tpms_packet.cpp I see that 64, 72 and 80 bytes are "parsed"

[helmarw]

looks to me all the lines appear, but i didnt check in detail, since non of them are my sensors.
when i get the sensor to send the pulse burst nothing at all happens on the portapack (except that is see that the singnal level changes) and nothing gets recorded in the tpms.txt

yes probably different size, im checking at the moment this part, which i assume most likely beeing "experimental"
from portapack-havoc/firmware/common/tpms_packet.cpp

Optional<Reading> Packet::reading_ook_8k4_schrader() const {
	/*
	 * Preamble: 01*40
	 * System ID: 01100101, ??*20 (not really sure what this data is)
	 * ID: 32 Manchester symbols
	 * Value: 8 Manchester symbols (temperature?)
	 * Value: 8 Manchester symbols (pressure?)
	 * Checksum: 8 Manchester symbols (uint8_t sum of bytes starting with system ID)
	 */
	/* NOTE: First four bits of packet are consumed in preamble detection.
	 * Those bits assumed to be 0b0100", which may not be entirely true...
	 */

but is should be:

         * Preamble: 01*40   -> 3bits
	 * System ID: 01100101, ??*20 (not really sure what this data is)  -> 1Byte
	 * ID: 32 Manchester symbols  -> 4Bytes
	 * Value: 8 Manchester symbols (temperature?)  -> 1Byte (Pressure)
	 * Value: 8 Manchester symbols (pressure?) -> 1Byte (Temperature)
	 * Checksum: 8 Manchester symbols (uint8_t sum of bytes starting with system ID) -> 1Byte

assuming 8 Manchester symbols = 1Byte

[helmarw]

yes most likely the parsed size:

according to this document: https://elib.dlr.de/81155/1/TPMS_for_Trafffic_Management_purposes.pdf

Sensor: A = 80bits
Sensor: B = 67bits (or 56 if you ignore the first 11bits, or 64 if you ignore the first 3bits)
Sensor: C = 80bits

70 must be different Sensors
could be 64 but only if you take the first 3bits (learn) into account, which do nothing and the checksum also ignores the next byte (CB)

Each message consists of 3 bits + 8 bytes (3 bits LEARN section + 7 data bytes + 1 byte CRC) using Manchester code. The preamble consists of a two wide pulses, which is followed by the LEARN section consisting of 3 bits. The first byte after LEARN section is without determined purpose, which was constant during the measurements (CB). The next 4 bytes are the sensor ID, which is followed by 1 byte pressure value (P) and one byte temperature value (T). The real pressure is obtained by multiplying unsigned received value by 2.5, while temperature in °C is calculated by subtracting 50 from the received unsigned value. The last byte is CRC according to CRC-8-CCITT standard. LEARN and CB are not used in CRC calculation.

i also noticed that these two line a probably wrong:

Pressure { static_cast<int>(reader_.read(32, 8)) * 4 / 3 },
Temperature { static_cast<int>(reader_.read(40, 8) & 0x7f) - 56 }

it should be:

Pressure { static_cast<int>(reader_.read(32, 8)) * 5 / 2 },
Temperature { static_cast<int>(reader_.read(40, 8) & 0x7f) - 50 }

(unless something was done to this values before, which i missed, then ignore this comment)

[helmarw]

its OOK not FSK

i think this might be the crucial part

Optional<Reading> Packet::reading_ook_8k4_schrader() const {

	constexpr uint8_t first_nibble = 0x4;
	const auto id = reader_.read(20, 32);
	const auto value_0 = reader_.read(52, 8);
	const auto value_1 = reader_.read(60, 8);
	const auto checksum = reader_.read(68, 8);

if i take the paper into account i would assume it should be:

	const auto id = reader_.read(12, 32);
	const auto value_0 = reader_.read(44, 8);
	const auto value_1 = reader_.read(52, 8);
	const auto checksum = reader_.read(59, 8);

+/-1 bit if i messed up the counting, starting from 0 or 1 i dont know ;)

[eried]

If you could make it in such a way that with the minimum amount of changes in the code parses your sensors, I guess it would be a good enough solution. But the proper solution would be to use another SDR to transmit all TPMS possible signals to make sure you dont break it for another type.

But I do not know specifics :/ I do not really know which sensor my car has, I will check later.

[helmarw]

me neither, i only got one type of sensors and recorded it, see previous post.
i would need recordings from other sensors and a second hackrf/portapack
i only got an other rtl-sdr so far for receiving only.
And i still dont know how to debug the portapack (is there some debug option? cant find anything). i could do some changes but if i dont get any kind of output i still dont know where exactly ive to look for, and i do not understand the code sufficiently enough for now, still trying to figure things out here. Maybe the one who actually programmed the tpms part, but it looks to me not much changed since it was forked from sharebrained

[eried]

I am not sure how to debug either, what I have been doing is to add lines like this:

// debug
//painter.draw_string({10,60},style(), "*** DEBUG");
//painter.draw_string({10,80},style(), "X="+to_string_dec_int(x_pos)+" y="+to_string_dec_int(y_pos));
//painter.draw_string({10,100},style(), " lat="+unit_auto_scale(lat_,3,3)+" long="+unit_auto_scale(lon_,3,3)+" ");
painter.draw_string({10,120},style(), " w="+to_string_dec_int(map_width)+" h="+to_string_dec_int(map_height)+" ");
painter.draw_string({10,140},style(), " w="+to_string_dec_int(map_center_x)+" h="+to_string_dec_int(map_center_y)+" ");
//painter.draw_string(target_rect.location(), style, to_string_short_freq(entry.frequency) + " " + entry.time + " " + str_duration);

About the TPMS what I can do is to scan my signals to help in your research, but I do not have a PSI indicator on the screen. I have only seen the "low pressure" icon blinking.

[helmarw]

oki, yes that might be helpful, you caould also use rtl_433 to confirm the readout, if you have an other sdr available

[helmarw]

aint working. im pritty sure its OOK and also the amount of bursts after the LF tone activation matches make me quite sure its "Sensor B" but even after disabling the checksum check im not getting any data, not even wrong one. so i think the error its earlier probably when analysing the incoming signal bursts and deciding which decoder to use and passing the result. Just could not figure out yet where to look. would be good to have an option to see the raw (un)encoded and unfiltered data coming in (if anything) but like thats its impossible or at least very very time consuming to figure out whats (not) happing... pity hoped it would be a quick fix

[helmarw]

no luck, i also tried the original version, and your compilation.
its something wrong or missing in the code :/

[helmarw]

i also tried the original firmware and your nightly build
same thing, so problem lies deeper than i initially thought :(

[eried]

I tried receiving my data without luck also it didnt catched anything on the street. I will try in the other frequency, but maybe the standard is different here in skandinavia?

[helmarw]

dont think so, unless its an US import (315MHz) in all Europe its supposed to be 433MHz.
as far as I know there are no other frequencies in use, at least not the officially supplied ones.
For aftermarket china imports I cant say ;)
Or your car uses the ABS system or simply measures the circumference, some resonance effect of the turning tyres etc. (called indirect systems) most Audi and VW with some exceptions, Seat, Honda, Mazda, vom Mercedes (A+B class afaik). Most others uses direct systems (sensors in the tyres)