Need help decoding - creating new device for rtl_433

[Zoltan T.]

Hello,

I have a TPMS sensor I'd like to read with my own device. The problem is, the data coming from it doesn't seem to corelate to serial number printed on the device itself.

The recordings are made in a reinforced concrete/metal sheet building, with a 1/4 wave dipole antenna. To ensure no other devices get received I left the receiver for cca 60 minutes with no received telegram.

After introducing the TPMS sensor into building I got this: https://drive.google.com/folderview?id=0BxCtZbY-hhwdTkdLMi10RU1ieVU&usp=sharing

The datasheet say's, to activate it, raise the pressure by more than 225 mbar. Well, I did a pressure test at 4 bar then atmospheric pressure, cycled a dozen times. Every time I changed the pressure, something got received.

The sensor info:

FCC ID: MRX C4W4MA4

Schraeder electronics

Serial row1: 003A38B2

Serial row2: 56029398AB

Serial row3: 12321 (this is probably date code, not serial)

Thanks

[Zoltan T.]

What I've found today is that the device doesn't send the serial number in each telegram. What it does send is a 95ms long telegram with a short preamble of 3ms.

The format is something like this: preamble;byte1;byte2;byte3;byte4;byte5;byte6;CRC?

Preamble=0x03 or 11b

CRC?=changing length, the ending zeroes are not transmitted. Is it a CRC, or something else, I don't know.

Example gfile002.data: 

0x03 0x0A 0x40 0x49 0x0C 0xB5 0x69 0x00 

- the byte5 here has a value of 0xB5 or dec. 181. 181*0.025bar=4.525bar, which is the approx pressure I've put on the sensor.

Example gfile007.data:

0x03 0x08 0x10 0x24 0x86 0x70 0x54 0x60

In this one byte5 is 0x70, or 112, 112*0.025=2.8bar

Example gfile015.data:

0x03 0x08 0x10 0x24 0x86 0x68 0x54 0x40

Pressure is slowly decaying from the bottle, byte5 is now 0x68 or 104, which translates to 104*0.025=2.6bar

According to datasheet, the temperature range is -50..205 C, and equals to 1bit/degree C. Thats 1 byte for full range. The pressure range is 0..6.375 bar with 1bit/0.025bar

 and it looks like it is stored in the byte5.

I couldn't find anything related to temperature yet. The test site was around 20 C, but the bottle get hotter when pressurized, and colder when released to atmospheric, so maybe 15-30 C fluctuation.

[Benjamin Larsson]

On 03/11/2016 04:38 PM, Zoltan T. wrote:
> What I've found today is that the device doesn't send the serial number
> in each telegram. What it does send is a 95ms long telegram with a short
> preamble of 3ms.
>
> The format is something like this:
> preamble;byte1;byte2;byte3;byte4;byte5;byte6;CRC?
> Preamble=0x03 or 11b
> CRC?=changing length, the ending zeroes are not transmitted. Is it a
> CRC, or something else, I don't know.
>
> Example gfile002.data:
>
> 0x03 0x0A 0x40 0x49 0x0C 0xB5 0x69 0x00

Do you have a receiver for the transmitter ? Can you correlate a few
transmitted signals with the output on the receiver ?


[01] {52} 08 20 24 86 74 a2 10

Pulse width distribution:
[ 0] count: 1, width: 125 [125;125] ( 500 us)
[ 1] count: 37, width: 32 [32;34] ( 128 us)
[ 2] count: 15, width: 63 [62;64] ( 252 us)

This looks fairly good.

MvH
Benjamin Larsson

[Tommy Vestermark]

Hi,

Before even trying to decode the content of the data you must be sure it is correctly demodulated.

I had a brief look at gfile001.data and it is apparent that the file is not PWM modulated - but the analyzer is fooled by a long start pulse. Looking in the FCC description it states Manchester decoding, which fits nicely with the pulse pattern. So you will have to write an initial device decoder which uses Manchester demodulation and just outputs the raw data. It looks like there should be ~8 bytes of data. Beware that polarity of the bits may be inverted compared to what you expect.

Since you also list 8 bytes, is that what you do already?

Otherwise I agree with Benjamin. The easiest way to decode the data is by having a reference. Also try to vary one parameter (temperature or pressure) and see which bits changes.

Cheers,
Tommy

[Zoltan T.]

On Friday, March 11, 2016 at 6:22:30 PM UTC+1, Benjamin Larsson wrote:

Do you have a receiver for the transmitter ? Can you correlate a few
transmitted signals with the output on the receiver ?

 

I don't own a receiver for this type of transmitter. The plan is to build one, and all the data is recorded with a USB TV dongle.

 

[01] {52} 08 20 24 86 74 a2 10 

In this example the value 0x74 can be correlated to air pressure, which at that time changed from atmospheric pressure to around 4.5bar. If it's a pressure value, then using a formula from the datasheet it is 0x74 * 0.025bar = 2.9bar.

Yesterday I've put the apparatus into fridge so I should have telegrams with <0C values then slowly raising to room temperature. At the same time the pressure inside the bottle should increase to.

[Benjamin Larsson]

You need some type of reference to correlate the bitstream with, best is
to use a real decoder but if that is not possible then just use another
thermometer. But as Tommy said you need to hook up manchester decoding
first so you can get the raw bitstream.

MvH
Benjamin Larsson

[Zoltan T.]

On Friday, March 11, 2016 at 7:18:43 PM UTC+1, Tommy Vestermark wrote:

Before even trying to decode the content of the data you must be sure it is correctly demodulated.

Isn't the "-t" parameter saves raw data? The values presented in my second post are "hand picked" with Audacity from a gfilexxx.data files. It's true that the waveform does not look like the waveform from FCC test report (it's on my drive, same folder as datasheet). Same waveform as when I use SDR# to record in raw format.

 Btw, managed to find a sample recording from a same type of sensor on sigidwiki http://www.sigidwiki.com/wiki/Tire_Pressure_Monitoring_System_(TPMS) - it looks the same, the waveform is the same, hand decoding gives the same data format.

I had a brief look at gfile001.data and it is apparent that the file is not PWM modulated - but the analyzer is fooled by a long start pulse. Looking in the FCC description it states Manchester decoding, which fits nicely with the pulse pattern. So you will have to write an initial device decoder which uses Manchester demodulation and just outputs the raw data. It looks like there should be ~8 bytes of data. Beware that polarity of the bits may be inverted compared to what you expect.

The waveform looks like OOK to me.  But I'm not expert in RF/modulation.

Since you also list 8 bytes, is that what you do already?

 

I shouldn't express the preamble as 0x03 or 11b. It is "high for two periods" in front of a packet. Then 6 data bytes, after that a variable length part, transmitted are only the leading zeroes and the 1's. The trailing zeroes are not transmited, eg. 00101000b is transmitted as 00101b. But that's only the last part of the telegram, probably CRC.

 

Otherwise I agree with Benjamin. The easiest way to decode the data is by having a reference. Also try to vary one parameter (temperature or pressure) and see which bits changes.

I've put it into freezer last night. Today, I'll leave it on room temperature and start the recording. It should give us some more data. 

[Zoltan T.]

I've got something. It can't be called good result, but it is a progress (or just hope).

Test mode active. Reading samples from file: gfile001.data

Input format: uint8

@0.000000s DSC Contact bad CRC: FFFFFF, Status: FF, CRC: FF

pulse_demod_manchester(): TPMS 

bitbuffer:: Number of rows: 1 

[00] {68} 7f 67 03 a3 8b 20 04 94 90 

@0.524288s DSC Contact bad CRC: FFFFFF, Status: FF, CRC: FF

pulse_demod_manchester(): TPMS 

bitbuffer:: Number of rows: 1 

[00] {68} 7f 67 03 a3 8b 20 04 94 90 

pulse_demod_manchester(): TPMS 

bitbuffer:: Number of rows: 1 

[00] {68} 7f 67 03 a3 8b 20 04 94 90 

pulse_demod_manchester(): TPMS 

bitbuffer:: Number of rows: 1 

[00] {68} 7f 67 03 a3 8b 20 04 94 90 

pulse_demod_manchester(): TPMS 

bitbuffer:: Number of rows: 1 

[00] {68} 7f 67 03 a3 8b 20 04 94 90 

pulse_demod_manchester(): TPMS 

bitbuffer:: Number of rows: 1 

[00] {68} 7f 67 03 a3 8b 20 04 94 90 

pulse_demod_manchester(): TPMS 

bitbuffer:: Number of rows: 1 

[00] {68} 7f 67 03 a3 8b 20 04 94 90 

Test mode file issued 4 packets

In the data now you can find the serial number (0x3A38B2): [00] {68} 7f 67 03 a3 8b 20 04 94 90. It is shifted for some reson, but it's there. 

Anyone willing to jump in? It'll take ages for me to write a driver :(

[Zoltan T.]

Anyone willing to jump in? It'll take ages for me to write a driver :(

Hmm, no edit...

If someone is willing to jump in I can provide the following:

- we know the serial number, it has to be transmitted else the receiver won't know which tire is flat out of four (0x3A38B2) 

- we know that it transmit at least the temperature in 1 byte (-50..205C, 1C/bit resolution) and pressure in 1 byte (0..6.375 Bar, 0.025Bar/bit )

- I can modulate the ambient pressure and take the reading (done, files on the link are taken with ~1..4.5 Bar pressure)

- I can modulate the ambient temperature and verify with other instruments if needed. In the sample data the temperature changed to - when pressurized it heated up, when vented cooled down, approx. 10C difference shall be observed in the recorded files.

- free beer if you are in Zagreb :)

[Benjamin Larsson]

I can write the driver if you tell me exactly how to decode each byte.
What I don't have time to is to blindly try to decode the signals and
try to figure out their meaning. You are the best person to do that work.

MvH
Benjamin Larsson

[Benjamin Larsson]

> 67 0*_3 a3 8b 2_*0 04 94 90. It is shifted for some reson, but it's there.

>
> Anyone willing to jump in? It'll take ages for me to write a driver :(
>

Hi, most likely some kind of preamble is present in the signal that
shifts the serial number.

MvH
Benjamin Larsson

[Benjamin Larsson]

I think the preamble is handled correctly as you are getting the serial
number on a 4 bit boundary. I think you can assume that the bit stream
decode is working and that is is time to identify the meaning of the
bits. If you need help with decoding the bits, post the bit stream and
corresponding values.

MvH
Benjamin Larsson

[Zoltan T.]

On Sunday, March 13, 2016 at 10:11:49 AM UTC+1, Benjamin Larsson wrote:

 

I can write the driver if you tell me exactly how to decode each byte. 

Thanks, I'll take you offer. In the meantime managed some progress, read below.

 

What I don't have time to is to blindly try to decode the signals and 
try to figure out their meaning. You are the best person to do that work. 

No, that's my problem. Just need something to spit out the correct numbers.

 

I think the preamble is handled correctly as you are getting the serial
number on a 4 bit boundary. I think you can assume that the bit stream
decode is working and that is is time to identify the meaning of the
bits. If you need help with decoding the bits, post the bit stream and
corresponding values.

I'm not sure if it's working correctly. As the "decoder" is hacked together by me from pieces of original code.

Here is the progress I mentioned previously:

The data IS manchester encoded, the radio part is ASK/OOK .The bitstream from three different (randomly selected) telegrams decoded by hand:

raw1:01010101011010011010010110100101010101010110101001100101011010100101011001101001011001010101010101010101100110100101011001100101010101

raw2:01010101011010011010010110101001010101010110101001100101011010100101011001101001011001010101010101010101100101100101100110010110010110

raw3:01010101011010010101010110010101010101010110101001100101011010100101011001101001011001010101010101010101100101100110010101100110010110

Using this encoder/decoder it's clear that the encoding is done by Thomas method (01=0, 10=1).

The decoded data:

decoded1: 000 00110110 01100000 00111010 00111000 10110010 00000000 01011000 10100000

decoded2: 000 00110110 01110000 00111010 00111000 10110010 00000000 01001001 01001001

decoded3: 000 00110000 01000000 00111010 00111000 10110010 00000000 01001010 00101001

Rearranging around a bit and the result is this:

Data1:

000

00110110 - 0x36, 54

01100000 - 0x60, 96

00111010 - 0x3A, 58

00111000 - 0x38, 56

10110010 - 0xB2, 178

00000000 - 0x00, 0

01011000 - 0x58, 88

10100000 - 0xA0, 160

Data2:

000

00110110 - 0x36, 54

01110000 - 0x70, 112

00111010 - 0x3A, 58

00111000 - 0x38, 56

10110010 - 0xB2, 178

00000000 - 0x00, 0

01001001 - 0x49, 73

01001001 - 0x49, 73

Data3:

000

00110000 - 0x30, 48

01000000 - 0x40, 64

00111010 - 0x3A, 58

00111000 - 0x38, 56

10110010 - 0xB2, 178

00000000 - 0x00, 0

01001010 - 0x4A, 74

00101001 - 0x29, 41

From this, I'd say the format is the following:

Preamble: 000

Byte_1: probably pressure,1bit/0.025Ba,0..6.375

Byte_2: no idea, need more testing

Byte_3: Serial_number_byte_1

Byte_4: Serial_number_byte_2

Byte_5: Serial_number_byte_3

Byte_6: zero in all samples except one, need more testing

Byte_7: probably temperature,1bit/Celsius, -50..205

Byte_8: no idea, need more testing

Bytes 1, 2, 6, 7 and 8 will be tested by me, but I'd ask you if you could make a new device first. I'ts quite noisy here, for every packet from my sensor I receive dozens of other packages from surrounding buildings.

[Benjamin Larsson]

On 03/13/2016 10:20 PM, Zoltan T. wrote:
> Byte_8: no idea, need more testing

There should be a crc somewhere. Most likely at the end.

MvH
Benjamin Larsson

[Zoltan T.]

You are right! Byte_8 is a CRC! But I got valid results if the CRC is calculated on byte_1..byte_6 (byte_8 ignored), then byte_7 is the checksum.

bash-4.2$ cat testmessage_1.bits

0000011011001100000001110100011100010110010000000000101100010100000

0000011011001110000001110100011100010110010000000000100100101001001

0000011000001000000001110100011100010110010000000000100101000101001

bash-4.2$ ./bruteforce-crc --width 8 --start 3 --end 59 --offs-crc 59 --file testmessage_1.bits

number of threads        : 4

width                    : 8 bits

CRC's offset             : 59

calc CRC for bit offsets : 3 .. 59 (not included)

final XOR                : 0

truncated polynom        : from 0 to 255 (MSB not shown)

initial value            : from 0 to 255

probe final xor          : false

probe reflect in         : false

probe reflect out        : false

extracted crc 00a0

extracted crc 0049

extracted crc 0029

----------------------[ MATCH ]--------------------------------

Found a model for the CRC calculation:

Truncated polynom : 0x7 (7)

Initial value     : 0x30 (48)

Final XOR         : 0x0 (0)

Reflected input   : false

Reflected output  : false

Message offset    : from bit 3 .. 59 (end not included)

[Zoltan T.]

Hello Benjamin,

Did you managed to make progress on the decoder? Please let me know if you need additional info. 

br, Zoltan

[Benjamin Larsson]

Can you gather all the info, sample signals and available code in a
ticket? I'll write a decoder then.

MvH
Benjamin Larsson

[John Jore]

@Zoltan,

As per https://github.com/merbanan/rtl_433/issues/392, I've got Steelmate TPMS sensors, which may be very similar to your setup, FSK and Manchester. If someone (Benjamin?) gives me a hand on the initial setup (modulation/short/long/limit), I may be able to write something up that can be adapted to your use case as I didn't find the ticket for tihs one,  (Else I would have cloned it for my usage!)

JJ

[Benjamin Larsson]

On 06/27/2016 12:08 AM, John Jore wrote:
>
> @Zoltan,
>
> As per https://github.com/merbanan/rtl_433/issues/392, I've got
> Steelmate TPMS sensors, which may be very similar to your setup, FSK and
> Manchester. If someone (Benjamin?) gives me a hand on the initial setup
> (modulation/short/long/limit), I may be able to write something up that
> can be adapted to your use case as I didn't find the ticket for tihs
> one, (Else I would have cloned it for my usage!)
>
>
> JJ

The modulation is FSK with what looks like manchester coding. But as you
say there are other signals mixed in your set.

For example 1 and 5 belong to 1 set and 11 another. I guess you need to
drive alone somewhere and capture a sample to be really sure. Or just
group the signals to find the one type of signal with a uniform strength
and signal layout. If the signal you want is in the group 1 and 5 then
you might need to get some samples in a higher bitrate like 1M/s. Even
though the signal is enough for decoding it might help during development.

MvH
Benjamin Larsson

[Benjamin Larsson]

On 03/25/2016 10:32 AM, Zoltan T. wrote:

There is now an initial implementation that can decode the id of the sensor.

rtl_433 -D r gfile001.data gives the following output:

Schraeder TPMS decoder

bitbuffer:: Number of rows: 1
[00] {68} 7f 67 03 a3 8b 20 04 94 90

id = 0x3A38B2

I tried to reproduce the crc field but was not able to do that. Please
redo that step with the output from rtl_433.

MvH
Benjamin Larsson

[Benjamin Larsson]

>
> I tried to reproduce the crc field but was not able to do that.

Actually I just figured out the crc.

011111110110011100000011101000111000101100100000000001001001010010010000
011111110110011100000011101000111000101100100101001001001010011001100000
011111110000010000000011101000111000101100100000000001001010001010010000
011111110000011100000011101000111000101100100100110101001010001111100000
011111110000010000000011101000111000101100100000001101001001000111110000
011111110000001100000011101000111000101100100000000001001001111100110000
011111110000001100000011101000111000101100101010000001001001111010110000


~/projects/bruteforce-crc$ ./bruteforce-crc --width 8 --start 4 --end 60
--offs-crc 60 --file data.bits --reflect-in true --reflect-out true
--probe-final-xor true

number of threads : 4
width : 8 bits

CRC's offset : 60
calc CRC for bit offsets : 4 .. 60 (not included)

final XOR : 0
truncated polynom : from 0 to 255 (MSB not shown)
initial value : from 0 to 255

probe final xor : true
probe reflect in : true
probe reflect out : true

extracted crc 0049
extracted crc 0066
extracted crc 0029
extracted crc 003e
extracted crc 001f
extracted crc 00f3
extracted crc 00eb

----------------------[ MATCH ]--------------------------------
Found a model for the CRC calculation:
Truncated polynom : 0x7 (7)

Initial value : 0xf0 (240)

Final XOR : 0x0 (0)
Reflected input : false
Reflected output : false

Message offset : from bit 4 .. 60 (end not included)


So that gives us a meaning for 10 out of 17 nibbles. Pressure,
temperature and flags should be left.

MvH
Benjamin Larsson

[Christian Zuckschwerdt]

Zoltan,

did you decode the pressure and temp readings? Did you consider the values to be PSI and Fahrenheit as the company "Schrader" is US-based?
I pick up quite some readings in sensor range and would infer the first three unkown nibbles to be flags. The last 4 nibbles seem to indicate the pressure/temp reading:

"071" "0C7E06" "5643"
"070" "61CCAC" "5b47"
"070" "61C7D5" "5b44"
"251" "68252C" "643a"
"261" "5286DF" "6d42"
"fac" "E9BB65" "556f"
"260" "55B5DF" "653e"
"071" "7F2D20" "6d42"
"070" "994F56" "884e"
"250" "997A1E" "9046"