Reading GM TPM with CC1101

Using Arduino Project Guidance
1

I've been fighting with this for a few days now, and surprisingly have come up with nothing related to reading modern GM Schrader TPMs. I have a set of AG6SP4 / GM 13598773 that I am trying to get an esp32 with a CC1101 to read for a retrofit project on a vehicle that predates tire pressure monitoring. I know the sensors work and report correctly as I have access to a reader at work, using that I have each sensor ID written down. I am able to see them transmit using Universal Radio Hacker, as stated in the FCC docs for this part I get 16 packets no less than 100ms apart when I hit them with a LF tire bonger.

In the interpretation screen I get what appears to be valid data using ASK modulation, all zeros with FSK selected. As a test I took one and put it in the freezer for about 5m then re-recorded it, the data was different this time indicating about where the temperature data resides. The FCC docs mention that the packets are manchester encoded, but I am having a tough time figuring out how to reverse it. Does anyone have any ideas on going about decoding these packets into valid data? I believe they should contain the ID, pressure, temperature, battery life/state, and probably a check bit.

The next question is how to configure radiolib to receive the info with a CC1101, using the examples I have managed to get it working or at least it claims that its listing, but it doesn't pick anything up.

These are the packets im getting from URH. There is a difference between the two for sure and between room temp and cold. Pressure should be reading zero, and temp should be around 74f or so, much lower for the cold one though.

Sensor 1
   aaaaaaaaaaaaaaaaaaaaaaaacb4b2caaaaaad52ab52d4cb4aad2aaaacccb3532a
Sensor 2
   aaaaaaaaaaaaaaaaaaaaaaaacb4b2caaaaaad52acab2b2accad2aaaacccaccaca
Sensor 2 Cold
   aaaaaaaaaaaaaaaaaaaaaaaacb4b2caaaaaad52acab2b2accad2aaaab4b2b354a
2

Are the packets you offer as examples the result of Manchester decoding the bit stream you are receivIng?

Can you post the code that allowed you to read these packets?

a7

3

An what is the sensor id for sensor 1 and 2 , also you need more packets ( add also the temperature/pressures at the moment of recording )

4

Tutorial here (for weather sensors, but the approach is general): Reverse Engineer Wireless Temperature / Humidity / Rain Sensors — Part 1 « RAYSHOBBY.NET

5

@alto777 The packets posted are raw data straight from Universal Radio Hacker using a RTL-SDR usb.

@davidefa Sensor one reports out 2017287205, two 2017599814. The pressure is zero and the temperature is about 74°F. I have two more sensors that I can query. Beyond that, all I can change their temperature as they are not in a wheel, just on my desk.

6

@jremington Interesting, I'll have to spend some time reading through that. Thanks.

7

It is a tried and true method! I've used it for several sensors. Some have a CRC check byte.

Collect data for various known pressures and the pattern should become clear.

More info about various tire pressure sensors here: Reddit - Dive into anything

8

You said

To what FCC docs are you referring?

Is there any Manchester decoding done by whatever it is that makes the data stream you posted? If that data is encoded, you have to de-Manchesterize it. it makes no sense to wonder about what the "raw" data is.

One of the links seems to suggest there are some tools available to help with that.

a7

9

I honestly do not know if it's being decoded or not, this is my first go at RF hacking. I figured that this would be documented already since these sensors are used in plenty of vehicles, guess not. I checked the docs here https://fccid.io/MRXAG6SP4 for anything that might describe operation, and of course as I type this they're having server problems, so I can't snip the relevant section.