Tire Pressure (TPMS) Functionality

[jimihimi]

I have successfully reverse engineered the Tire Pressure (TPMS) controller protocol.

Forked and made a branch that has the functionality here: Link to Branch

Currently the new branch can read and clear troubleshooting codes (DTCs) and Transmitter IDs of the sensor in the tires.

Would really appreciate some testers as I only have two TPMS modules to develop against.

[ldeploynoob]

Nice work, I will see if I can compile your code and try it on my 2008 car.

In an ideal world, it would actually show the specific pressures of the four transmitters!

[ldeploynoob]

So when I try to build it, cross-compiling for Windows within a Linux VM, your code chokes during the compilation of the TPMS portion in a "declared protected" error.

It apparently doesn't like "msleep(10)" in protocolTPMS.cpp:328:32.

It's not an error that came up when building "FreeSSM-master" this way, since obviously there is no TPMS portion to that code.

Not sure what's going on here, this is well beyond my pay grade:

src/SSMprotocolTPMS.cpp:328:32: error: 'static void QThread::msleep(long unsigned int)' is protected within this context
  328 |                 QThread::msleep(10);
      |                 ~~~~~~~~~~~~~~~^~~~
In file included from /opt/mxe/usr/i686-w64-mingw32.static/qt/include/QtCore/QThread:1,
                 from src/AbstractSSMcommunication.h:26,
                 from src/SSMprotocol.h:35,
                 from src/SSMprotocolTPMS.h:4,
                 from src/SSMprotocolTPMS.cpp:1:
/opt/mxe/usr/i686-w64-mingw32.static/qt/include/QtCore/qthread.h:116:17: note: declared protected here
  116 |     static void msleep(unsigned long);
      |                 ^~~~~~
make[1]: *** [Makefile.Release:1540: release/SSMprotocolTPMS.o] Error 1
make[1]: Leaving directory '/home/ldeploynoob/Desktop/FreeSSM-TPMS'
make: *** [Makefile:34: release] Error 2

[jimihimi]

What version of QT are you using? I think older ones don't expose the sleep function inside threads; I may be able to write a helper function for backwards compatibility, but want to be sure that it's a versioning issue before doing so. Thanks!

I updated my notes on romraider based on some new findings. There are additional SSM commands in the 'readDataByLocalIdentifier' that provide some status/values but I am unsure what the values correlate to - once we have TPMS buildable we can expose these and see how they correlate to temperature/pressure https://www.romraider.com/forum/viewtopic.php?f=40&t=21117

[ldeploynoob]

That was it, thank you. No need to re-write it, I have the .exe file compiled now.

The output list of "qtchooser -l" initially showed only qt4 and qt5.

I added :/usr/bin/qmake6 to the PATH, and then entered "QT_SELECT=qt6", and then "qtchooser -l" showed qt6 on that list.

Then "make" compiled the .exe file just fine.

Anyone following me here should note that because I was cross-compiling, I had to swap the Windows "" for Linux "/" in several of the files in the SRC folder, as I mentioned elsewhere in this Issues forum. I think the problem lines were only in the .h files that referred to the Windows folder in the source code.

I'll let you know what happens when I run it.

[ldeploynoob]

No joy.

The "Tire Pressure" button results in "Communication Error" exactly like all the other buttons except for "Engine" and "Transmission", which do connect via SSM2 / ISO-14230, instead of ISO-15765.

I just complained about that issue here yesterday:

#88 (comment)

I'm not sure if you have written this to require a CANBUS connection, but I am using an OP 2.0.

This is for a 2008 USDM Legacy Outback, 3.0 six cylinder car, its ECU rom has been patched to allow CANBUS logging.

Perhaps these other Control Units beyond ECU and TCU are only available to connect with FreeSSM on newer Subarus, or maybe something can be done for my 2008 car.

I believe 2008 was the first year for CANBUS on Legacy models like this Outback.

No problems exist (except for the absence of a CANBUS speed connection) when connecting to the ECU or TCU.

[jimihimi]

I added OpenPort comms to the TPMS module; it should work for you now (before it was just K-Line adapters like VAG).

Also, I made another tab to show live data (raw hex) in the hope that we can decipher it.

On my Win11 machine i have to do a 32-bit build to get the OpenPort drivers to work correctly - not sure if this is the same in Linux.

[ldeploynoob]

Cool.

I will not have a chance to re-build and re-test for a couple of weeks, but I will post my result when I do so.

[ldeploynoob]

YOU ARE THE MAN!

I made some time before my trip out of town, compiled your new source code, and now I can connect to the control unit for the TPMS.

(I don't suppose you could have a look at the code for ABS/VDC, Cruise Control and AC to work similar magic for me to get into those control units too, could you?)

I think I already was compiling for 32 bit, because I entered this command from the Linux terminal, from the root directory of your source code:

/opt/mxe/usr/i686-w64-mingw32.static/qt6/bin/qmake6

Then once that had completed, I entered "make", and it ran just fine (after first switching all the Windows backslashes to Linux forward slashes in the SRC folders).

Here is what I get:

Now I really will be a couple of weeks before I reply!

[ldeploynoob]

BTW, these screen shots were taken when the car was stationary, just after a cold start. The TPMS light did it's usual test cycle at startup, ignition on, along with the other idiot lights, and then it went out. I started FreeSSM and got these screenshots just after that.

I had no time for a test drive, so I had no way to see if (and how) they change when rolling. FreeSSM doesn't really have a logger function anyway, so I guess I would have just had to take screenshots at random intervals to give you "live" data.

[jimihimi]

This is great to hear! It's interesting to see your ROM-ID is 08 CA 07 00, all the modules I dumped were 08 CA 03 00 out of Tribecas. I'm guessing this is the same Calsonic branded hardware with some variation for the different models.

I will update the Live Data to refresh at some interval, that should help to reverse engineer the values. No surprise you got 0x00, the tire sensors 'sleep' until you drive for some time. Also the 0x21/0x99 data is not supported on earlier modules like yours.

I will try the ABS, Cruise, etc on my car and see - if I don't have the same issue as you there's not much I can do to fix it.

[ldeploynoob]

Hi jimihimi,

I am back with the vehicle, and had a chance to do some tests.

Regarding your last post, actually the correct ROM-ID for my TPMS Control Unit is 8B CA 07 00.

It may be a little hard to read from screen capture, with the purple text in Dark Mode background.

I didn't see any updates to your code now from the last time I built it, so I just played with my existing .exe file.

I started the test after driving for about an hour on the highway, so the TPMS sensors would be "awake", and the tires were warmed up.

I tested all tire pressures with a reasonably accurate mechanical gauge, and all four were at 39 psi at the start of the test (ie. quite warm).

I decided to run four tests at different speeds: parked (0 mph), 25 mph, 35 mph and 60 mph.

I held the speed with cruise control for a few seconds, and my indicated speed was corrected with a GPS app.

I got the following results with the "Live Data" button. The button appears to give only freeze frame data as at the moment the button is pressed (ie. it doesn't update from that point, and you have to back out of and then re-enter the TPMS Control Unit to get new data).

I will enter the results as text here, so there is no legibility problem with screen captures.

First, the 25 mph test (ie. 40 kph)

Live Data:
0x21 / 0x10 / Live/status block (10 bytes):
Raw: FF FF C0 C3 C0 C0 2A 83 90 E0
Byte
Byte 0 0XFF (255)
Byte 1 0XFF (255)
Byte 2 0XC0 (192)
Byte 3 0XC3 (195)
Byte 4 0XC0 (192)
Byte 5 0XC0 (192)
Byte 6 0X2A (42)
Byte 7 0X83 (131)
Byte 8 0X90 (144)
Byte 9 0XE0 (224)

Then the 35 mph test:

Raw: FF FF C0 C0 C0 C0 38 83 90 E0
Byte
Byte 0 0XFF (255)
Byte 1 0XFF (255)
Byte 2 0XC0 (192)
Byte 3 0XC0 (192)
Byte 4 0XC0 (192)
Byte 5 0XC0 (192)
Byte 6 0X38 (56)
Byte 7 0X83 (131)
Byte 8 0X90 (144)
Byte 9 0XE0 (224)

Then the 60 mph test:

Raw: FF FF C0 C3 C0 C0 5E 83 90 E0
Byte
Byte 0 0XFF (255)
Byte 1 0XFF (255)
Byte 2 0XC0 (192)
Byte 3 0XC3 (195)
Byte 4 0XC0 (192)
Byte 5 0XC0 (192)
Byte 6 0X5E (94)
Byte 7 0X83 (131)
Byte 8 0X90 (144)
Byte 9 0XE0 (224)

Then parked, at 0 mph obviously:

Raw: FF FF C0 C0 C0 C0 00 83 90 E0
Byte
Byte 0 0XFF (255)
Byte 1 0XFF (255)
Byte 2 0XC0 (192)
Byte 3 0XC0 (192)
Byte 4 0XC0 (192)
Byte 5 0XC0 (192)
Byte 6 0X00 (0)
Byte 7 0X83 (131)
Byte 8 0X90 (144)
Byte 9 0XE0 (224)

So from basic pattern recognition, it clearly looks like Byte 6 is always the estimated road speed in kilometers per hour.

Bytes 2 through 5 remain nearly constant, with only a slight variation at Byte 3 through all the tests.

That very small change in Byte 3 could easily be a small change in the pressure of one of my tires with heat, or else margin of error for reading a tire pressure.

So I will surmise those four bytes are the pressure values of the four transmitters.

However, their units are a puzzle.

I would have expected them to be set in kilopascals, given the metric speed in Byte 6.

But that can't be exactly right because I started out with 39 psi read mechanically (ie. 269 kpa), so those Bytes are all far too low to be straight kpa of each tire.

192 kpa is only 28 psi.

My wild ass guess: perhaps they are the number of kilopascals beyond the minimum threshold for triggering the idiot light.

If that were true, then it would mean that the idiot light would be triggered at about 77 kilopascals (ie. 11 psi).

In other words, 269 kpa actual reading on the mechanical gauge, minus the 192 kpa that keeps showing up in bytes 2 through 5, leaves you with a floor constant of about 77 kpa (11 psi).

However, a quick Google search suggests the idiot light is triggered below 26 psi (179 kpa), so at the end of the day, I don't really know what to think about the units used in these Bytes.

I'm not sure whether the system is smart enough to assign FL, FR, RL, RR to the four bytes at issue.

I suppose I would have to make one tire significantly overinflated and one significantly underinflated, and rotate them to different positions to see if the reading on Bytes 2 through 5 changed.

If the Bytes don't change values when the tires are rotated to different positions, then I guess the Bytes just correspond with the ID of their TPMS sensor.

But if the Bytes changed when the tires are rotated, then it must mean each Byte corresponds to one of the four positions on the car.

Obviously that would be a real pain in the ass to test.

As for Bytes 0, 1, 7, 8 and 9, they all stayed exactly the same through all four tests, and I have not got the foggiest idea what they may be doing.

How's it going looking at making the ABS, Cruise, etc. buttons work for me? :)

[ldeploynoob]

Had to make some corrections to the data, sorry, I think it's all good now.

[ldeploynoob]

I waited for the tires to cool a bit, and then I checked them with the mechanical gauge.

All the tires were still in the high 30 psi range, maybe not quite 39 psi but pretty near to it on this gauge.

I then dropped the left rear tire pressure down to 25 psi on this gauge, and went for a quick drive.

No TPMS idiot light came up, so either my mechanical gauge is somewhat inaccurate, or 26 psi is not the magic minimum trigger point of the TPMS light.

It is clear now to me now that Bytes 2, 3, 4 and 5 are a direct indication of tire pressure, though the units used still baffle me.

So we now have five out of the ten Bytes in the system deciphered, except for the units of tire pressure used by this system.

Maybe call it 4.5 of the Bytes deciphered :)

Raw: FF FF BC BE BC 87 00 83 90 E0
Byte
Byte 0 0XFF (255)
Byte 1 0XFF (255)
Byte 2 0XBC (188)
Byte 3 0XBE (190)
Byte 4 0XBC (188)
Byte 5 0X87 (135)
Byte 6 0X00 (0)
Byte 7 0X83 (131)
Byte 8 0X90 (144)
Byte 9 0XE0 (224)

So it is clear that Byte 5 reflects the new left rear wheel pressure, at least at this point.

Next test will be to swap the LR wheel's position on the car to somewhere else, and see whether Byte 5 still shows low relative to the other three.

That will determine whether it is just reflecting its sensor ID back to to the TPMS Control Unit (ie. a "dumb system"), or whether it is reflecting its location at another Byte (ie. a "smart system").