TPMS TireMoni TM-240

[72ka]

Hi, I have this TPMS TireMoni TM-240 system: TM-240

It has 4 sensors, up to 12bar pressure. Each sensors is labeled by number from 1 to 4. No ID outside even inside. Maybe there is helpfull link to FCCID https://fccid.io/T8QTD-1000A

I spent couple of days (!) reading this awesome project wiki, and I stuck with it. My findings:

The sensors transmitts OOK signal, everything else is only my estimation... I think I can catch ID and Wheel position. You can look here for my current findings. There are the sensors 3 and 4 (S3 and S4), where I made some measurement under different pressure conditions (0,1,2,3 and 4 bars).

BITBENCH HERE

Anyway, I'm totally lost... I cant see any relations in bits to the pressure.... No zereos when all sensors are in zero, etc... I am afraid is encrypted...

I've tried to find anything in non-coded, manchester coded and differential manchester... all three ways ends the same, no relations to the pressure.

In the attachment you can see for example the recordings for Sensor 4 in one zip file. It consist of file mes.txt where is the console output with my commands and the records itself.

S3-4bar.zip

Thank you for the help.

[zuckschwerdt]

Quick notes: I'd venture to say that "wheel position" is a fluke, usually there is a fixed ID which is learned and assigned by the head unit.
You can check if MC or DMC is used on a longer stream of slightly changing messages: measure for a day, either just outside to allow for small temperature and pressure changes or very slowly letting air out. You will only get a consistent ramp of values with the right coding. Also you will spot the field where the pressure is (and maybe temp) with a slow ramp.

The files 4,5,8,13 you posted are clipping badly (too loud) they could be FSK. The files 9,10,11 are incomplete.

Only file 12 is sensible -- still clipping but there are two complete packets. The signal is PPM 500/1000 -- this is not your TPMS. So we still need a good sample of the TPMS.

[72ka]

Quick notes: I'd venture to say that "wheel position" is a fluke,

I dont think so... it is absolutly consistent Sensor 1 is 0, S2 is 1, S3 is 2 and S4 is 3 for bunch of my packets. And in the product manual, there is also, when you buy a new sensor, you have to order the number (wheel position). For example, sensor 3 can't work on wheel 4 etc... you can learn the receiver on each wheel number only the correct sensor number (yes, it is not usuall)

usually there is a fixed ID which is learned and assigned by the head unit. You can check if MC or DMC is used on a longer >stream of slightly changing messages: measure for a day, either just outside to allow for small temperature and pressure >changes or very slowly letting air out. You will only get a consistent ramp of values with the right coding. Also you will >spot the field where the pressure is (and maybe temp) with a slow ramp.

this is strange... if the sensor is just lying on the desk for hour, each packet has the bits almost random (except the ID, WHEEL POS and maybe some flags).
Need to say, sensor is emmiting packets when idle every aroun minute.

The files 4,5,8,13 you posted are clipping badly (too loud) they could be FSK. The files 9,10,11 are incomplete.

Only file 12 is sensible -- still clipping but there are two complete packets. The signal is PPM 500/1000 -- this is not your TPMS. So we still need a good sample of the TPMS.

Thanks, I'll have a look into them, some packets are maybe from my weather sensors etc... I have here couple of transmitters in neighborhood etc.. the fire sensors, other cars, weather stations etc...

[72ka]

Only file 12 is sensible -- still clipping but there are two complete packets. The signal is PPM 500/1000 -- this is not your TPMS. So we still need a good sample of the TPMS.

Maybe a stupid question... how to check if the sample is not clipped? And not too loud? Is this sample good? Thank you :)

OK_g017_433.92M_1000k.zip

[zuckschwerdt]

how to check if the sample is not clipped?

I will add that to Pdv in the next weeks. For now try the preview https://triq.org/spectrogram-next/
It shows clipping with red (also the wave should look like a sine, no flat areas) in the bottom waveform view, zoom in with mouse scroll.

[72ka]

OK, changed gain (rtl_433 -S all -s 2048k -g 12) and now I think this signals are correct. Now I think is clear, that the signal is FSK.
Unfortunatelly, the results are the same, only the PCM gives the consistent results in ID and also with wheel number...
Can you please confirm, that the signal is OK?

And... what do you think of the decoding? For me, everything looks like manchester, it works, but.. the results are not logical for pressure or temperature.

S3-0bar.zip

Thank you

[zuckschwerdt]

Yes, that looks good. FSK PCM 50 MC is exactly what we expect from a TPMS.
I guess the sync is maybe 5539 as that aligns nicely to 10 full bytes.
Not sure if/where the encryption/obfuscation is as usually you'd want to hide the ID, which is still visible here?

[72ka]

Yes, the ID is visible that's doesnt make sense for encryption. But now I found very interresting thing, it looks like the packets are separated for some "types"... check THIS BITBENCH If I order them by "type" look at the other values... I see there some consistency.
So maybe the sensors sends in each packet only for example pressure, then temperaure, then whatever (and also in different intervals... there is no separation to odd or even packets)... I think this is possible.

So, my next task is to collect more data.

[gdt]

@72ka What's the status of this issue and next steps?

[72ka]

@72ka What's the status of this issue and next steps?

Hi, I spent a lot of time on this device. It looks the device sends some like full packets with some unidentified informations periodiccaly and the pressure or temperature packets only when some event occurs (pressure leak etc...). I have no more time for it.