Mobiletron TPMS - Githubissues

VK1IAN commented 2 years ago

Good Morning, I've used rtl_433 to decode weather stations and it works well. I am taking my first tentative steps at identifying an unknown device and was wondering if anyone has worked with the Mobiletron TPMS transmitters? My cunning plan is to build my own receiver (ESP8266 with touchscreen connected to a CC1101 receiver to replace the one that came with the kit (the older I get, the harder it is to read the 4x16 LCD display without glasses). The transmitters currently installed in the wheels of our truck are the TX014. I have just recently purchased replacements (TX026) which will be installed when the tyres are replaced. I found the FCC reports (ULZ-TX014 and ULZ-NXP002) which indicates they transmit on 433.92MHz using FSK. I've already had a quick look with cubic-sdr and confirmed the frequency and observed a deviation of approx +/60Hz. I've had a go at capturing .cu8 files (using -S unknown) but I'm not exactly sure what to make of them yet. Being a novice and where I live, there is a LOT of activity on the 433M band and I think I'm struggling to "home in" on the signals I'm after. I've attached one of them here which I think has the data I'm looking for. On a side note, if I generate a pulse file using rtl_433 -w filename.fsk filename.cu8 and drop it on https://triq.org/pdv/ , the sample format is shown as OOK (and nothing on the display). If I generate with tl_433 -w filename.ook filename.cu8 and drop it on the same site, it now shows as FSK and I see pulses. Not sure where I go from here (i.e what I need to enter for slicer, short, long, sync and gap) but I'm still reading!! I'm going to a mate's place in a week and he lives in an area which is a LOT more "RF quiet", so I'll have another go at a capture then. I will also reduce the amount of wheels visible to the receiver, so I'm only looking for 2 IDs rather than 6. Anyway, if anyone has any hints I'd be much appreciative. Regards g006_433.94M_250k.cu8.zip

zuckschwerdt commented 2 years ago

$ rtl_433 -A g006_433.94M_250k.cu8

Detected FSK package    @0.168392s
Analyzing pulses...
Total count:   60,  width: 28.22 ms     ( 7054 S)
Pulse width distribution:
 [ 0] count:   50,  width:   56 us [48;76]  (  14 S)
 [ 1] count:    1,  width:  360 us [360;360]    (  90 S)
 [ 2] count:    1,  width:  188 us [188;188]    (  47 S)
 [ 3] count:    6,  width:  116 us [116;136]    (  29 S)
 [ 4] count:    1,  width:  244 us [244;244]    (  61 S)

Yes, that looks like 50 µs FSK PCM.

rtl_433 -w g006_433.94M_250k.ook g006_433.94M_250k.cu8 (drop on https://triq.org/pdv/) confirms that. There is an unusual long warm-up (18ms), then a preamble, and data.

The (byte) alignment isn't visible, could be a preamble of aaab. Try to get more codes, document what should be in them and share a BitBench like this.

This should capture raw codes: rtl_433 -R 0 -X 'n=mobiletron,m=FSK_PCM,s=50,l=50,r=900,bits>=100'

VK1IAN commented 2 years ago

@zuckschwerdt Thanks mate. Couple of questions:

How did you come to the values for s, l and r?? (i.e in the command s=50,l=50,r=900)
Is 250K sample rate sufficient or should I be going higher??
How does the -R 0 switch interact with the -S unknown switch?? It appears that when I use "-S unknown -R 0", all decoders are deregistered and EVERYTHING is logged to a file. I might try the command without the -R 0 switch. I forgot to mention that I've had the current receiver apart and identified a few parts; a 434M filter, a T5743 receiver (by Atmel) and a PIC18LF4526 micro (which receives data from the receiver and drives the LCD). I've got the T5743 data sheet and slowly digesting the info. The T5743 expects a continuous "2 edges per bit" signal (the minimum is set in a config register) and then a "start bit", before allowing data on the "data out" pin to the microcontroller. This would explain the aaab; a=1010 and b=1011. The other thing that concerns me is the T5743 does nothing with the data in so far as encoding. This means there could be some oddball encoding implemented in the PIC. The data sheet also talks about manchester (or biphase) encoded data to give the "2 edges per bit" signal, but this could also be done with NRZ; something to be considered later I guess. I'll continue to read through the T5743 in an attempt to understand how it works. WRT BitBench; I was waiting for that hoary chestnut. Are there any tutorials for beginners?? Otherwise I'll have to cross that bridge when I get to it :-| I'll let you know what I find once I'm at my mate's place; internet connectivity permitting of course. Appreciate your advice and guidance.

zuckschwerdt commented 2 years ago

For PCM the short and long value are just the bit-length, 50 µs here. The reset value should be longer than the longest run of 0's observed. Usually more than 10 bits won't work well so 500, rounded that up generously for testing I just put 900 there.
250k is somewhat on the edge for a 50 µs signal but should work. If you encounter problems go up to 1000k.
Use -R 0 to exclude any other decoders when using -X, that way you only get the codes you are interested in. No need for -S. But best not to use -R 0 with -S unknown -- that's actually -S all then.
"Two edges per bit" sounds like Manchester, yes. But the data seen is just NRZ and does not show the Manchester pattern? E.g. compare the raw FSK signal below to how "regular" MC would look here: https://triq.org/rtl_433/PULSE_FORMATS.html#mc-%E2%80%94-manchester-code
BitBench is just to pick codes apart. Dump raw codes there and try some formats to visualize.

mobiletron-fsk

VK1IAN commented 2 years ago

Been doing a bit of experimenting (more to familiarize myself with the tools) and seem to have found a discrepancy. If I run the attached cu8 file through rtl_433 using rtl_433 -X 'n=mobiletron,m=FSK_PCM,s=50,l=50,r=900,bits>=100 it returns aaaaaaaaaaaa2fd4e132194824d56d37aaaaaa000 If I generate a ook (not sure why this shows up as PSK on the website) with rtl_433 -w g006_433.94M_250k.ook g006_433.94M_250k.cu8 and drop it on https://triq.org/pdv, (using Slicer=PCM, Short=50, Long=50, Gap=900), it returns aaaaaaaab5aa8bfa9e1320ca409355da6faaaaaa000 I'm curious as to why they are different. Is this perhaps a result of 250K sampling being a bit too close for 50uS that you mention above?? As an exercise, I also generated a .sr file using rtl_433 -w g006_433.94M_250k.sr g006_433.94M_250k.cu8 and opened it in sigrok. I marked a nibble (using cursors), then decoded by hand by moving the cursor range up nibble by nibble. I came up with aaaaaaaaaaaa2fd4e132194824d56d37aaaaaa000; i.e the same as what the -X option returned. Anyway, I'm off to my mate's on Friday so am hoping to get some fresh files over the weekend. To avoid the possible 250K sampling limitation, I'll do them all at 1M. Apart from file size, I assume there will be no down side to sampling this high?? Just need to get my head around BitBench now. All files mentioned above are in the attached zip file.

g006_433.94M_250k.zip

zuckschwerdt commented 2 years ago

rtl_433 will automatically find a preamble (aaaaa) and adjust the bit rate to perfectly match. Pulseviewer doesn't do that, so you'll need to match the rate yourself -- 60 µs should work. Somewhat hard to read but it should really show FSK not PSK ;)

VK1IAN commented 2 years ago

rtl_433 will automatically find a preamble (aaaaa) and adjust the bit rate to perfectly match. Pulseviewer doesn't do that, so you'll need to match the rate yourself -- 60 µs should work.

Worked perfectly. Thanks mate; your blood is worth bottling :-) At least I now know what those numbers do :-)

Somewhat hard to read but it should really show FSK not PSK ;)

Seen - Typo on my part :-o

VK1IAN commented 2 years ago

Been playing with BitBench and think I'm sorted for the most part, however I don't seem to be able to figure out what the variables in the "Calculation" section do; specifically "Offset, Length and Width". My assumptions were as follows:

Offset = Number of bits from the start of the stream to start;
Length = Number of bits to consider in the calculation; and
Width = Number of bits required in the answer.

As an example, assume I have a data stream like this aa12481111 I would now like to add the nibbles 1248 with a 4-bit answer so I use: Offset: 8, Length: 16, Width: 4 This gives a result of 0xf which is what I was expecting. If I now go for a 8-bit answer (Width: 8) I get 0x5a; I was expecting 0x0f. I'd be grateful if you could advise what I am doing wrong.

zuckschwerdt commented 2 years ago

"Width" is the unit width, i.e. nibble, byte, ... Offset: 8, Length: 16, Width: 8 is to add the byte (Width: 8) at offset 8 and the byte at offset 16. 0x12+0x48 = 0x5a

VK1IAN commented 2 years ago

OK. To reinforce my understanding, if I have the following: aaa167f29cde456aaaaa and I only want to sum the 167f29cde456 section to a byte value, I would use Offset: 12, Length: 48 and Width: 8 ?? Thank you for your patience.

zuckschwerdt commented 2 years ago

It's not "to a byte value" but "using byte size values / in steps of a byte". I.e. "8" means "add bytes" / "4" means "add nibbles"; the result will always be an int big enough to hold the answer.

VK1IAN commented 2 years ago

Ack

VK1IAN commented 1 year ago

Turns out the captured data I provided previously is not the Mobiletron TPMS. I positioned myself in a remote area of my mate's property (no power available) so I could do the capture. I managed to isolate the front tyres from the rear ones to limit the IDs I'm looking for (unless the SDR dongle I'm using has far better sensitivity than the Mobiletron Receiver). I ran the captures for approx 50 mins, recording the pressures and temperatures indicated by the Mobiletron receiver at various intervals. A subset of those captures is attached. During the period of this subset, the temperature of both tyres was 13 degrees Celsius and the pressure for both was 69 PSI. The IDs of the sensors are B1A79312 and 288F9312. I ran rtl_433 in analysis mode and came up with a FSK-PWM signal, so ran: rtl_433 -R 0 -X 'n=TPMS,m=FSK_PWM,s=111,l=222,r=1032' <filename>.cu8 on all the files. I've entered the results into bitbench here: https://triq.net/bitbench#c=feb765a8&c=fefe72b6&c=feb765ac&c=fef747b8&c=feb765a8&c=fefe72b4&c=feb765ac&c=fef747b8&c=fe74f4ec&c=fe74f4ec&c=feabfa2c&c=feb765ac&f=hh%20&i=true&cw=4 By inverting the data, I can pick out temperatures (in farenhiet expressed as hex) but it is not consistent. It appears the temp, pressure and IDs are being sent over multiple transmissions but I'm struggling to see how this is being done. I'd be much appreciative of some guidance.

TPMS.zip

zuckschwerdt commented 1 year ago

TPMS usually use PCM with MC, i.e. there is data in the gaps which PWM would disregard. For raw data use

rtl_433 -R 0 -X 'n=TPMS,m=FSK_PCM,s=100,l=100,r=250,bits>=64'

Then collect the code in a BitBench, use a preamble of 5556 and turn on Manchester.

Here is a BitBench for the samples from the zip. The codes are rather short and I can't spot a fixed ID?

zuckschwerdt commented 1 year ago

It's just these unique codes and no visible pattern

03 1a 3f +trailer? 11
36 f8 6a +trailer? 11011
f8 18 69 +trailer? 11011
46 ba 3e +trailer? 11
73 58 6b +trailer? 11011

VK1IAN commented 1 year ago

TPMS usually use PCM with MC, i.e. there is data in the gaps which PWM would disregard. For raw data use
rtl_433 -R 0 -X 'n=TPMS,m=FSK_PCM,s=100,l=100,r=250,bits>=64'
Then collect the code in a BitBench, use a preamble of 5556 and turn on Manchester.

Here is a BitBench for the samples from the zip. The codes are rather short and I can't spot a fixed ID?

Thanks for the info however I'm struggling to understand what is going on. I am coming to the view that Mobiletron are not your typical TPMS so will probably be doing something very unique. Why use 5556 as a preamble?? I think I need to poke around a bit with the spectogram/pulsedata webpage to see if I can join some dots in my head; they are currently really BIG smudges!!!

zuckschwerdt commented 1 year ago

Why use 5556 as a preamble?

No reason, it's just the first non-preamble bit we can grab and align to.

merbanan / rtl_433

Mobiletron TPMS #2170