Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

That TPMS issue, summarized

This site may earn commission on affiliate links.
Interesting read. Thanks for the detailed information, Scotty!

Ironically, my car has been throwing ID 409: TPMS Hardware Error on every drive now. Hooray...
I don't have a problem manually keeping up with my tire pressure, but this error is definitely annoying at best (the exclamation point taking place of the ability to move left on the VDS is the LARGEST annoyance of all).

Hope to see more progress toward a solution to this widely-known issue. And hey...you don't live too far from me. Perhaps I'll contract you instead of my SC to fix the issue once you've mastered it. ;)

I'll be glad to help, I'm out in Cedar Hill.
The big issue will be fixing the receiver. It's supposed to be in the 485Mhz range (or something like that). And I don't have aything that transmits to use for a test signal source.
 
Great post!
As a MS owner I suffer from stupid TPMS disfunction... (

Now it seems we have enough data to build a replacement scanner (arduino + RF board) to read sensor addresses.
As I know tesla uses CAN bus (at least on MS) to reprogram sensor addresses. Wondering if it is possible to reprogram via K-line on ODB-2?
Will try to build a chip scanner and read/set values on weekends.

They told me the antennas are the same. Which means the LIN bus is the same, and the unit ID's have to be the same. So the protocol has to be the same....

Reading the signals from the tires will be the challenge. I have no information on it, nor anything to generate test signals.

So, if anyone else can provide information it would be appreciated. I can troubleshoot RF stuff, although my scope is only 100Mhz.
The board is covered with a rubber like substance, cleaning it is a pain. The antenna portion is shown here, after I clean it.
boardCovered.jpg cleanedAntenna.jpg
 
This is my understanding of the connection arrangement:

Code:
   OBDII pin7                  (fuse#7)              CAN
        K                 GND    +12V               L   H
        |                  |      |                 |   |
        |                  |      |                 |   |
+------------------------------------------------------------+
|                                                            |
|                        TPMS ECU                            |
|                                                            |
+------------------------------------------------------------+
          |    |    |                 |    |    |
          |    |    |                 |    |    |
         +12V GND  data              +12V GND  data
      Front Antenna Module        Rear Antenna Module

The TPMS ECU transmits IDs 0x343, 0x344, and 0x345 on the instrumentation CAN bus. It may also receive CAN bus command messages, but we have no information on that.

The OBDII K line (pin #7) is supposedly what is used to talk to the tool. Presumably that updates the TPMS ECU with the sensor IDs. The TPMS ECU is then master for the front and rear antenna modules using LIN protocol. No idea what the protocol for the OBDII K line is.

I don't have any tools to work with LIN buses; although it is not too hard. Can somebody have a look at pin#7 on OBDII and see what the protocol is there?

@scotty2541 can you send me the decodes you have, and any data dumps to mark (at) openvehicles (dot) com? What was the baud rate of the LIN stuff you captured? Can you show here the details for how you used LIN IDs 10..13 to reprogram the IDs into the antennae?

We know that the sensors are from Baolong. Anybody know where the TPMS ECU and antennas come from?

P.S. A while ago, I saw a service bulletin for the Roadster TPMS that said if the antenna connection comes loose then the antenna can lose it's memory of the programmed sensor IDs. I guess that is the most likely explanation for @scotty2541 problem.

P.P.S. The reason for my renewed interest in this is explained by the picture below. I've had this for the past two days. Probably cold weather, and the tyre sensors being 5 1/2 years old.

View attachment 203847

I emailed you.

The baud rate is about 9600, but the LIN specification is that it sends a defined pattern so all the slave units can use that to sync their timing before the data packets start, That removes the need for crystals on each slave. Lower cost.
 
They told me the antennas are the same. Which means the LIN bus is the same, and the unit ID's have to be the same. So the protocol has to be the same....

Reading the signals from the tires will be the challenge. I have no information on it, nor anything to generate test signals.

So, if anyone else can provide information it would be appreciated. I can troubleshoot RF stuff, although my scope is only 100Mhz.
The board is covered with a rubber like substance, cleaning it is a pain. The antenna portion is shown here, after I clean it.
View attachment 204404 View attachment 204405

Actually I already started doing some research on this. Collected some logs from stationary car and from few short rides.

Issue is it seems my TPMS batteries are dead... so they do not transmit any signals (at least I were not successful identifying any so far).
Will try to dig further on weekends with another Tesla car.

The way you can do it is to get one of this guys: DVB-T USB 2.0 - Hacker Warehouse
And refer to Jared Boone talk on ToorCon'15:
And his s/w:
The other thing to note is that any TPMS sensor has FCC id, so you can check it's specs (mainly frequency and modulation) at FCC ID Search by entering FCC id.
 
Ok seems like I found something.

I can clearly see some regular transmissions happening at 433.92Mhz, which is perfectly aligned with FCC docs for Tesla's Baolong TPMS sensors (FCC ID TZSTPMS201 Tire Pressure Monitoring System by Shanghai Baolong Industries Corporation):
00.png


Not yet 100% sure, but most likely I'm right, so let me share some details.

Here is demodulated signal sample (you can clearly see data 1's and 0's):
01.png


Signal properties:
1. Frequency: 433.92Mhz
2. Modulation: FSK
3. Transmission time: ~28ms
4. Boudrate: 9600 (?not sure?)

Will now focus on decoding this signals and determining packet structure. Anyone with knowledge in DSP, programming, Radio willing to help? )

BTW, here is how transmission look in time (during 10 minutes ride):
02.png



Detailed log:
Code:
2.86720
37.04960
37.29152
37.53344
63.36640
71.47648
71.71712
97.52832
97.77280
131.93600
139.60960
139.85280
140.09472
165.61280
165.85600
173.79968
174.04160
174.28480
203.57888
207.99104
208.23424
208.47616
234.44352
242.18368
242.42560
268.13184
268.37504
276.38784
276.62976
276.87168
310.58432
310.82496
311.06560
336.49408
336.73856
336.98176
345.02784
370.67904
370.92224
371.16800
371.41120
378.99520
379.23840
379.48032
404.87168
405.11616
405.36064
413.20704
413.44896
413.69088
417.01248
447.42528
447.66592
447.90784
481.63712
481.87904
482.12096
515.85536
516.09600
516.33792
541.62944
 
Ok seems like I found something.

I can clearly see some regular transmissions happening at 433.92Mhz, which is perfectly aligned with FCC docs for Tesla's Baolong TPMS sensors (FCC ID TZSTPMS201 Tire Pressure Monitoring System by Shanghai Baolong Industries Corporation):
View attachment 204564

Not yet 100% sure, but most likely I'm right, so let me share some details.

Here is demodulated signal sample (you can clearly see data 1's and 0's):[/CODE]

Wow, awesome data capture. What did you use to collect it? I was shopping around for some SDR devices, but haven't picked one up, lots of mixed reviews out there. There's a higher quality SDR Play device I can get from Ham Radio Outlet is the price range that satisfies me.

I've got very little DSP experience, but lots of data communication experience, I did decipher manchester data stream from a proximity card, and wrote an article for circuit cellar magazine. But the data was already demodulated. I'm willing to try to help out with anything, However, my schedule is rather tight over the next two weeks.

That post from Jared Boone was very informative too.

Can you upload the raw data, as a ZIP file or something? I would try to write an algorithm in C on my PC to decode it first, then port it to a chip.
 
  • Like
Reactions: dhrivnak
Wow, awesome data capture. What did you use to collect it? I was shopping around for some SDR devices, but haven't picked one up, lots of mixed reviews out there. There's a higher quality SDR Play device I can get from Ham Radio Outlet is the price range that satisfies me.

I've got very little DSP experience, but lots of data communication experience, I did decipher manchester data stream from a proximity card, and wrote an article for circuit cellar magazine. But the data was already demodulated. I'm willing to try to help out with anything, However, my schedule is rather tight over the next two weeks.

That post from Jared Boone was very informative too.

Can you upload the raw data, as a ZIP file or something? I would try to write an algorithm in C on my PC to decode it first, then port it to a chip.

I used a very basic $20 RTL device, like this one (with stock antenna): Amazon.com: IEIK SDRMCX RTL-SDR, FM+DAB, DVB-T USB Stick Set with RTL2832U & R820T. Great SDR for SDR#, Low-Cost Software Defined Radio Compatible with Many SDR Software Packages: Electronics

Here is my device:
00.jpg

To capture data I tried 2 methods:
1. simply ran rtl_sdr -f 433920000 -g 40 -s 1000000 capture.dat and used Jared's tools to extract bursts
2. used Jared's auto burst extraction tpms_rx --if-rate 400000 --file capture.dat --bursts

After getting potential signal burst files did some tinkering using both Jared's tools and my own setup based on GNU Radio to learn modulation, encoding and so on (can share any details with anyone who is ready to help decipher Tesla's TPMS RF protocol).

Will drop you PM with zipped signals to play with.
 
  • Informative
Reactions: dhrivnak
Baud rate should be 9600 (see screenshots):
04.png 05.png

And here is the first attempt to get signal bits using gnuradio (manchester encoded):
Code:
00000000: 0000 0000 0101 0001 0100 0000 0001 0000  ................
00000010: 0001 0100 0100 0100 0100 0100 0100 0100  ................
00000020: 0100 0100 0100 0100 0100 0100 0100 0100  ................
00000030: 0100 0100 0100 0100 0100 0100 0100 0100  ................
00000040: 0100 0100 0100 0100 0100 0100 0100 0100  ................
00000050: 0100 0100 0100 0101 0000 0100 0101 0000  ................
00000060: 0100 0100 0100 0100 0101 0001 0001 0001  ................
00000070: 0001 0001 0001 0001 0001 0001 0000 0101  ................
00000080: 0001 0001 0001 0001 0001 0001 0000 0100  ................
00000090: 0101 0000 0101 0000 0101 0001 0000 0100  ................
000000a0: 0100 0100 0100 0100 0100 0101 0001 0000  ................
000000b0: 0101 0001 0001 0001 0001 0001 0001 0001  ................
000000c0: 0001 0000 0100 0101 0000 0101 0000 0100  ................
000000d0: 0101 0001 0001 0001 0001 0001 0000 0100  ................
000000e0: 0101 0001 0001 0001 0000 0101 0000 0100  ................
000000f0: 0101 0001 0000 0100 0100 0100 0101 0001  ................
00000100: 0001 0001 0001 0001 0001 0001 0001 0000  ................
00000110: 0101 0000 0101 0000 0101 0000 0101 0000  ................
00000120: 0101 0101 0100 0100 0100 0001 0001 0000  ................
00000130: 0101 0000 0100 0000 0000 0000 0100 0100  ................
00000140: 0001 0000 0a                             .....

It clearly contains errors, which is gnuradio Clock_Recovery_MM and BinarySlicer blocks issue or me doing something wrong :).
 
  • Informative
Reactions: dhrivnak
Baud rate should be 9600 (see screenshots):
View attachment 204583 View attachment 204584

And here is the first attempt to get signal bits using gnuradio (manchester encoded):
Code:
00000000: 0000 0000 0101 0001 0100 0000 0001 0000  ................
00000010: 0001 0100 0100 0100 0100 0100 0100 0100  ................
00000020: 0100 0100 0100 0100 0100 0100 0100 0100  ................
00000030: 0100 0100 0100 0100 0100 0100 0100 0100  ................
00000040: 0100 0100 0100 0100 0100 0100 0100 0100  ................
00000050: 0100 0100 0100 0101 0000 0100 0101 0000  ................
00000060: 0100 0100 0100 0100 0101 0001 0001 0001  ................
00000070: 0001 0001 0001 0001 0001 0001 0000 0101  ................
00000080: 0001 0001 0001 0001 0001 0001 0000 0100  ................
00000090: 0101 0000 0101 0000 0101 0001 0000 0100  ................
000000a0: 0100 0100 0100 0100 0100 0101 0001 0000  ................
000000b0: 0101 0001 0001 0001 0001 0001 0001 0001  ................
000000c0: 0001 0000 0100 0101 0000 0101 0000 0100  ................
000000d0: 0101 0001 0001 0001 0001 0001 0000 0100  ................
000000e0: 0101 0001 0001 0001 0000 0101 0000 0100  ................
000000f0: 0101 0001 0000 0100 0100 0100 0101 0001  ................
00000100: 0001 0001 0001 0001 0001 0001 0001 0000  ................
00000110: 0101 0000 0101 0000 0101 0000 0101 0000  ................
00000120: 0101 0101 0100 0100 0100 0001 0001 0000  ................
00000130: 0101 0000 0100 0000 0000 0000 0100 0100  ................
00000140: 0001 0000 0a                             .....

It clearly contains errors, which is gnuradio Clock_Recovery_MM and BinarySlicer blocks issue or me doing something wrong :).

That burst from 20 to 80 looks like a burst to wake up any AGC/PLL on the receiver. Then there should be some asserts, as start of frame markers, then stuff to sync the demodulators, etc...

Those dimples at 89, then at 95 look like phase shifts.
433.92 Meg Cycles per second, divided by 9600 bits per second, is 45,200 cycles per bit.

After demod, 9600 baud is 0.000104 seconds per bit. If, like the Jared video, the data is 70 bits, then the burst would be 7.29217 milliseconds. I'm guessing we can't see the full burst in image.

First thing I would do is try throwing away leading values, until you find a sync pattern. Typically 0xAA or 0x55. Which looks like it starts are offset 1.3 in the second image. Those are typically used as start markers, and to sync up the bit stream so you know where bit 7 ends and bit 1 of the next byte begins.

Just my thoughts until I can have time to dig in deeper.
 
  • Informative
Reactions: dhrivnak
P.P.S. The reason for my renewed interest in this is explained by the picture below. I've had this for the past two days. Probably cold weather, and the tyre sensors being 5 1/2 years old.

View attachment 203847

Now this is strange. I've been getting the same TPMS hardware error every morning, 20 minutes into my drive to work. Seems that the sensors don't wake up when car is turned on, 20 minutes later the fault timer fires, and car re-initialises (triggers?) the sensors, then a minute or so later the fault clears. Repeatable. Every morning for the past two weeks. The OVMS display is fine and is showing values from the sensors.

Then, Sunday, I pumped up my tyres (they were low on the right side). Did a long drive that day, and no TPMS fault. Two more commutes to work (yesterday, today) and no TPMS fault.

It seems perhaps a bug where a low tyre pressure is being interpreted as a TPMS hardware error.

I really need to get into the K-line to see what is there. Planning to dig out that Saleae Logic analyser, and see what I can find on the OBDII connector.
 
If the tires heat unevenly will that trigger a warning? Our VW would do that; even though all tires are in spec (though 1 barely), the right rear had a slow leak and so heated up much differently than the other 3 and would trigger an alert.

What confuses me is the error message is a TPMS hardware fault, not low pressure warning.
 
Now this is strange. I've been getting the same TPMS hardware error every morning, 20 minutes into my drive to work. Seems that the sensors don't wake up when car is turned on, 20 minutes later the fault timer fires, and car re-initialises (triggers?) the sensors, then a minute or so later the fault clears. Repeatable. Every morning for the past two weeks. The OVMS display is fine and is showing values from the sensors.

Then, Sunday, I pumped up my tyres (they were low on the right side). Did a long drive that day, and no TPMS fault. Two more commutes to work (yesterday, today) and no TPMS fault.

It seems perhaps a bug where a low tyre pressure is being interpreted as a TPMS hardware error.

Well, that was a wrong turn. The fault is back today (commensurate with a drop in ambient temperature - temperatures were higher the past few days). I did manage to capture the output of the sensor display both at the time of the TPMS fault (left picture) and just after it cleared itself (right picture):

tpms_before.png
tpms_after.png


FL: +0.7psi +1C
FR: -0.7psi -5C
RL: +0.7psi +3C
RR: +04psi +3C

The front right sensor seems the one with the issue. The 29C -> 24C makes no sense, as the temperature should go up as the tyre warms up during the drive.

New best guess: sitting cold at night (about 15C ambient here now, the FR tpms battery didn't have enough power. Then, as the tyres heat up during the drive, it starts to work. The re-trigger after 20 minute timeout clears the fault. Certainly, the FR tpms sensor seems 'stuck' at the end-of-previous-day value.
 

Attachments

  • IMG_8332.PNG
    IMG_8332.PNG
    1.2 MB · Views: 113
  • Like
Reactions: driver_EV
I do love faults. They teach you so much...

So, I took a CAN bus dump (instrumentation bus, 1Mhz) on the way to work. Started it five minutes into the journey, and as expected, twenty minutes into the journey I got the TPMS Hardware Fault alert, which cleared itself a few minutes later. Here are some snippets of the dump, annotated, to show what is going on:

Code:
 1481151965.511 344 4C 37 00 00 67 39 66 37      --- TPMS (f-l 27psi,15C r-l 37psi,17C r-r 37psi,15C)
 1481152883.534 344 4C 37 00 00 67 39 66 37      --- TPMS (f-l 27psi,15C r-l 37psi,17C r-r 37psi,15C)
 1481153263.795 344 4C 37 00 00 67 39 66 37      --- TPMS (f-l 27psi,15C r-l 37psi,17C r-r 37psi,15C)
 1481153891.056 344 4C 37 00 00 67 39 66 37      --- TPMS (f-l 27psi,15C r-l 37psi,17C r-r 37psi,15C)
 1481154449.317 344 4C 37 00 00 67 39 66 37      --- TPMS (f-l 27psi,15C r-l 37psi,17C r-r 37psi,15C)
 1481154833.578 344 4C 37 00 00 67 39 66 37      --- TPMS (f-l 27psi,15C r-l 37psi,17C r-r 37psi,15C)
  ...
 1481580406.214 100 93 05 99 01 00 01 00 00    ->VDS (message to VDS 93)
  ...
 1481649197.813 344 51 3D 50 40 6E 43 6E 42      --- TPMS (f-l 29psi,21C f-r 29psi,24C r-l 39psi,27C r-r 39psi,26C)
 1481649637.071 344 51 3D 50 40 6E 43 6E 42      --- TPMS (f-l 29psi,21C f-r 29psi,24C r-l 39psi,27C r-r 39psi,26C)
 1481650321.330 344 51 3D 50 40 6E 43 6E 42      --- TPMS (f-l 29psi,21C f-r 29psi,24C r-l 39psi,27C r-r 39psi,26C)
 1481651002.588 344 51 3D 50 40 6E 43 6E 42      --- TPMS (f-l 29psi,21C f-r 29psi,24C r-l 39psi,27C r-r 39psi,26C)
 1481651739.301 100 93 00 FF FF 00 00 00 00    ->VDS (message to VDS 93)
 1481651868.846 344 51 3D 50 40 6E 43 6E 42      --- TPMS (f-l 29psi,21C f-r 29psi,24C r-l 39psi,27C r-r 39psi,26C)
 1481652434.105 344 51 3D 50 40 6E 43 6E 42      --- TPMS (f-l 29psi,21C f-r 29psi,24C r-l 39psi,27C r-r 39psi,26C)
 1481652813.364 344 51 3D 50 40 6E 43 6E 42      --- TPMS (f-l 29psi,21C f-r 29psi,24C r-l 39psi,27C r-r 39psi,26C)

So, as I guessed yesterday, the drive starts with 00 00 for front right sensor, and the other sensors around 15C-17C.

Then, twenty minutes into the drive, we see VDS 100 93 05 (alert error message, type 0x0199 = 509 decimal = TPMS Hardware Error).

A couple of minutes later, the front right sensor starts to report it's status, and after a couple of good readings are reported, the error fault is cleared. (100 93 00).

So, my TPMS hardware fault is that my front right tyre sensor doesn't seem to work below around 24celcius.
 
  • Informative
Reactions: dhrivnak
my car has been throwing ID 409: TPMS Hardware Error

So, last week I started getting the dreaded #409: TPMS: Hardware error message with associated fault light on the dash. Agree with @DeedWest it is annoying. It occasionally goes away, but comes back after driving for about 15-20 minutes. The VDS display shows no tire pressures (see image).
upload_2017-6-26_16-31-46.png

Even with the error, OVMS shows pressures for the tires. Oddly, the temp and pressure information for the rear tires has remained constant, while the front tires has been variable. See three different screen shots below. The first before driving, the second after driving 8 minutes, and the third a different day after driving 20 minutes.
upload_2017-6-26_16-30-15.png


I had new summer tires installed by the local NTB store a few months ago, but the TPMS had been working normally after this installation. I have read some of the posts on this forum linking this to cold temp, but it is neither cold nor really hot these days on the East coast.

@markwj -- you posted about a similar issue I believe. How did you resolve? Does anything look unusual from the OVMS screen shots above?

My main question is which of the following should I do: a) take it to Tesla SC for repair b) take it back to NTB to fix (they say they used a standard programming tool when the summer tires were installed) c) ignore it because it will eventually go away. I am seeking advice and suggestions. Any other diagnostics I should do?
 
So, last week I started getting the dreaded #409: TPMS: Hardware error message with associated fault light on the dash. Agree with @DeedWest it is annoying. It occasionally goes away, but comes back after driving for about 15-20 minutes. The VDS display shows no tire pressures (see image).
View attachment 232881
Even with the error, OVMS shows pressures for the tires. Oddly, the temp and pressure information for the rear tires has remained constant, while the front tires has been variable. See three different screen shots below. The first before driving, the second after driving 8 minutes, and the third a different day after driving 20 minutes.
View attachment 232878

I had new summer tires installed by the local NTB store a few months ago, but the TPMS had been working normally after this installation. I have read some of the posts on this forum linking this to cold temp, but it is neither cold nor really hot these days on the East coast.

@markwj -- you posted about a similar issue I believe. How did you resolve? Does anything look unusual from the OVMS screen shots above?

My main question is which of the following should I do: a) take it to Tesla SC for repair b) take it back to NTB to fix (they say they used a standard programming tool when the summer tires were installed) c) ignore it because it will eventually go away. I am seeking advice and suggestions. Any other diagnostics I should do?

Option A, tell them to simply reprogram the sensors antennas.. and be belligerent. ( Is this a Roadster 2? )
(Option C isn't an option. The code clears every few system starts, then comes back after about 20 minutes... it'll do that forever)
(Option B isn't an option, as you'll see below when the tire store tried in on mine... they can't do it)

Here's why:
I had this happen twice just this year. In Jan, then again last month. I got all new tires last month, and they tried to reprogram the antennas. Apparently, they believe the what the device says: "Read the addresses, then drive for 20 minutes." No plugging into the obd2 connector. When they did that to mine, I drove and it gave me data that was good. Then about a days worth of driving later, I got the error.

I examined the error, and it was EXACTLY THE SAME as the cause of the error I got in Jan. And the cause I got in October, when they told me to buy a new antenna. The system actively CORRUPTED the programmed addresses on one of the antennas. It was the rear antenna first in October, then the front antenna in Jan, then again in the new rear antenna they convinced me to buy.

I was talking to the service guy when I was in to pick up something else at Tesla. I told him the tire store device said to just drive on it for 20 minutes. He said that's baloney, that they have to reprogram them when they put new valve stem transmitters in.

So, what's happening? Either the system decided it needed to change the known valve stem transmitter addresses which are stored in the antennas, and failed miserably at it, or the system is INTENTIONALLY corrupting the data forcing you to go back to Tesla and pay them to correct it (buy new parts is their solution). Either way, Tesla should have a class action lawsuit to fix this.
Again... It's either a serious software flaw or sabotage.

(I am accusing them of the sabotage, because they have always said buy a new antenna)

If you invest in a LIN analyzer device from Microchip, I could talk you through figuring out what is wrong, and attempting to fix it. The device was like $65.
LIN Serial Analyzer - APGDT001 | Microchip Technology Inc.
But it takes sniffing the data, decoding it, and the careful precision of sending the program commands back into the LIN bus. As I said, I've already had to do it twice on my car.

Alternately, pull both antennas, send them to me, and I'll try to do it for you. I need both, because one of them is likely still has the correct addresses in it, so I would read that out, and program the other one with the correct addresses (both antennas know about all four tire transmitters).

That's my rant... :)
 
By the way, when I say "I am accusing them of the sabotage, because they have always said buy a new antenna" it is also based on my reaching out to the national manager complaining about the TPMS defects, and the inferior service when I call in, ( no one EVER answers the phone or calls back). They have conveniently ignored the TPMS.

I got a reply that said "Sorry it was taking so long to get the alignment shims you wanted. We are trying to improve our service center efficiency." Nothing about the TPMS.

And I didn't complain about the time to get parts. I complained that no one every answers the phone or calls back.