TPMS CONTINUES TO FAIL... [RANT] And they are gonna send people the mars?

[scotty2541]

Here's my update:
After seeing that it had the front addresses corrupted (they were not "erased", which by the way in "flash" non-volatile memory is setting all bits on, not off) and I reprogrammed them, the system is working again. Fully functional. After two weeks, still working fine.

So, here are the details. Again, from my post:
That TPMS issue, summarized
There are four messages that the main unit uses to ask the antennas for addresses:
0x14 = Dear Front antenna, tell me what you think the two front tire addresses are
0x15 = Dear Front antenna, tell me what you think the two rear tire addresses are
0x16 = Dear Rear antenna, tell me what you think the two front tire addresses are
0x17 = Dear Rear antenna, tell me what you think the two rear tire addresses are
(Logically, command 14 and 16 will have the same responses, as will 15 and 17)

The only thing that was messed up was what the FRONT antenna thought the front addresses were. The front antenna had the rear tire addresses correct, and the rear antenna had all four tire addresses correct.

So the antenna CPU had a part, and a VERY SPECIFIC PART, of it's memory scrambled. Or something, somewhere sent the command to program the front antenna, front addresses with garbage (0x10 is the command for that), plus had a correct checksum in the message. The units do not accept messages when the check sum is invalid... or shouldn't anyway.

Things like this bring out the conspiracy theory in me: that this isn't simply a part failure, it's actually the system performing self sabotage, to force a service visit. Just because the damage was so precise. And almost identical to last time, except it was the rear antenna.

I wish I had a solution for everyone else being screwed by this process. I'd even happily reprogram antennas for people, if the user could tell me what address to set. But there is no way to know without the tools. Maybe, just maybe, a local tire store has an RF tool that could read the addresses. I know my local Discount Tire offered to check mine (but I didn't need to at that time).

Anyway, here is my output from the sniffer (parity check bits omitted from the commands for clarity) Remember, 4 bytes make one tire address, two addresses for front, two for rear.
.......BAD.................... |..........GOOD..........
-------------------------------|----------------------------------
14 ... 44 50 45 6C 45 6C 44 71 | 14 ... 08 06 66 2E 08 06 66 EC
15 ... 08 06 66 05 08 06 67 2F | 15 ... 08 06 66 05 08 06 67 2F
16 ... 08 06 66 2E 08 06 66 EC | 16 ... 08 06 66 2E 08 06 66 EC
17 ... 08 06 66 05 08 06 67 2F | 17 ... 08 06 66 05 08 06 67 2F

You can see, #16 has my correct front tire addresses on the good and bad, but #14 had rather random garbage when it went bad.

Hope this continues to educate. Good luck out there.

-Scott

 

[scotty2541]

As for your "rant", my suggestion to you is that ranting is counterproductive. Rational, reasoned discussion can be productive.

But it sure made me feel better! LOL!!

Seriously, though, I've had productive posts on this topic several times. And other topics too. But this one is getting old. And when their service center won't call you back, and the company is ignoring you trying to reach them, it's time to turn to some social media.

 

[scotty2541]

Is it possible that the addresses are getting corrupted by some weird kind of cross talk or interference? I hate to jinx myself but we have not had any problems with our TPMS with the exception of one sensor needing to be replace most likely because of the battery. Seems like some cars are prone to constant failures and others are not.

Yeah, those are called "lemons"

I find it difficult to see how some cross talk corrupted it. See my summary up a few posts. It takes a precise address, and valid checksum. Not impossible, but unlikely.

 

[markwj]

No, disconnecting the antenna doesn't make it forget. It stores the address in some "flash" or "EEPROM" (don't know which). I originally reprogrammed the old antenna on my work bench when I was reverse engineering it. Refer back this this long thread:
That TPMS issue, summarized

I pulled the bench power supply, disconnected it from my sniffer/programmer, and installed it in the Roadster. It remembers just fine.

I found the referenced service bulletin that mentions this:

TSB-10-34-011 19 August 2010

TPMS Antenna Connection.
Checking TPMS Antenna Connection Integrity on 2.0 Roadsters.

Under some instances, one or both of the TPMS antennas on 2.0 Roadsters may not be fully seated. If not fully seated, the ECU may lose its memory of the sensor ID numbers for those respective antennas. Loss of connectivity at one or both of the two antennas (front and/or rear) will cause a blank reading on the touch screen and set a warning for the customer. Once the antenna loses connection for 24 hours, the ECU will forget the ID numbers of the sensors for that specific antenna.

It seems that the antenna module needs to be disconnected for 24 hours before thje ECU forgets the ID numbers of the sensors.

 

[PowerSource]

there is an off the shelf scanner that works with the Roadster TPMS costs about 2-300dollars. The issue is writing these values to the VDS. I have two of these units (very similar to the units used by Tesla even labeled SmarTool).

 

[scotty2541]

I found the referenced service bulletin that mentions this:



It seems that the antenna module needs to be disconnected for 24 hours before thje ECU forgets the ID numbers of the sensors.

Thanks, I assume the "ECU is the main control unit that polls the antennas...

I'm calling this bulletin irrelevant. Here's why:

• The power lines to the antennas are OFF when the car is off. I measured them. I assume they are coming from the ECU. What this implies is leave the car off for a day, and your TPMS is screwed.
• In this failure, the ECU isn't the one who forgot the address. It was the antenna. When I reprogrammed the antenna, it all started working.
• As far as I can tell, the ECU doesn't even care. And it shouldn't. Message ID 23 is to tell it the pressure and temp of the front tires, message ID 33 for the rear tires... etc.... Those messages don't have the tire addressed in them.
• I pulled my old antenna out of the bottom of a box where I tossed it last Christmas. I power it up, and sent it a command asking it what the addresses are for the front and rear tires (messages 16 and 17, it was a rear antenna), and to spit the correct tire addresses back at me. That's 2+ months of not having any power.

Quoting: "Loss of connectivity at one or both of the two antennas (front and/or rear) will cause a blank reading on the touch screen and set a warning for the customer.". Yes, because there will be no reply from that antenna unit.

If, after 24 hours, the ECU decides it doesn't know the tire addresses, what difference does it make? When the antenna comes back online, it will report the tire addresses to the ECU based on the ECU poll, when the ECU asks. And the ECU should accept the reply. If the antenna is bad, missing, etc, then the ECU will complain that no one is answering for messages 14, 15, 23, etc... (or whichever antenna is dead).

Remember that both antennas know the addresses of all four tires. And both antennas reply with data for all four tires. So the system can know about all four tires if one antenna is dead. But obviously the distance will cause signal strength issues for the far tires. It decides to complain that there is a system failure if one antenna stops responding (or apparently has a tire address mismatch).

So, regardless of power being off, turn the system on, the ECU should start polling: Asking the antennas what tire addresses they are programmed with (and should match), then asking each antenna what they have for data from each tire (which may not match if one antenna missed a transmission from a tire). If everyone replies, the system is happy.

A lose connection will make the system report a problem. But it won't cause an antenna to forget. I just tested and proved it.

But thanks for the bulletin. I bet there is a lot more bulletins out there that would make for interesting reading. Personally, I've love to have a service manual on this thing.

 

[scotty2541]

there is an off the shelf scanner that works with the Roadster TPMS costs about 2-300dollars. The issue is writing these values to the VDS. I have two of these units (very similar to the units used by Tesla even labeled SmarTool).

If it can program, then it can read the addresses to. What he did was walk around the car, pointing it at each tire, and "prompted" the tire sensor to transmit. It grabbed the address for each tire.
Then, when he plugged it into the ODBC II connector, it sent the message to program the antennas. I took the car home, removed the antenna and re-read it to see the difference. So it's the same thing I can do, except I physically accessed the LIN bus from under the car, rather than plugged it into the ODBC II plug. (I wonder if one of the ODBC II connector pins is the LIN signal?? ).

So if someone wanted to send me their antenna and tell me the addresses, I could do it for them.

 

[gregd]

So it's the same thing I can do, except I physically accessed the LIN bus from under the car, rather than plugged it into the ODBC II plug. (I wonder if one of the ODBC II connector pins is the LIN signal?? ).

I was wondering the same thing. If so, and with a bit of a hardware / firmware hack, one might be able to archive and restore the values via OVMS? Maybe the upcoming v3 as a base? It would be awesome if we could make the TPMS system more robust with a simple add-on... Just a thought.

 

[strider]

As markw said, the early S's had the baolong system too. It crapped out back in December (almost exactly 4 years old). The new cars use a Continental system. I had them "upgrade" our S to the Conti system. We'll see how it fares.

I had the Burlingame SC crawl all through my Roadster trying to fix the TPMS before I left Cali. They replaced both antennas, swore that the sending units in the tires were ok (even though they're 6 years old), and that I would need to swap the "main TPMS module" in the car. But it's buried in the dash and they didn't have time to do it before we were moving away.

I would LOVE to have an emulator to silence the messages. I would be willing to pay a few hundred dollars to not ever have to hear this stupid thing beep at me again. I am well versed in using a tire gauge.

 

[NomoC8]

Well, guess what...
I hooked up my LIN sniffer tool,and saw that the addresses to the FRONT antenna were bad. This is the device they repleeaced a couple years ago. In between the 2 second spacing of the messages, I inserted the "program" command to tell it to set the tire transmitter addresses for the front sensor. Now it all works great.
Ultimately, this is also what was wrong with my rear sensor that I replaced in December. Probably the same life time too.

I don't know what a "LIN sniffer" is, but I would like to. Is there a way to get someone to reassign the addresses on my TPMS?

 

[wiztecy]

I don't know what a "LIN sniffer" is, but I would like to.

Google's your friend.

LIN Serial Analyzer - APGDT001 | Microchip Technology Inc.

 

[markwj]

If, after 24 hours, the ECU decides it doesn't know the tire addresses, what difference does it make? When the antenna comes back online, it will report the tire addresses to the ECU based on the ECU poll, when the ECU asks. And the ECU should accept the reply. If the antenna is bad, missing, etc, then the ECU will complain that no one is answering for messages 14, 15, 23, etc... (or whichever antenna is dead).

The Tesla TPMS tool uses radio to get the IDs from the sensors, then K-line on the OBDII port to talk to the ECU. Then, the ECU has two separate LIN buses to talk to the front and rear antenna modules. The ECU also has a CAN bus connection to talk to the VMS and VDS. So, no direct connection between the TPMS tool on that OBDII port and the antennas.

So, the only way it can work is for the Tesla TPMS tool to send the IDs to the ECU, then the ECU sends them along each of those LIN buses to the antenna module. The question is does it do that once (at program time from the tool), or does the ECU retain the IDs and send them out when required? The answer is in the service bulletin:

the ECU may lose its memory of the sensor ID numbers

So, most likely the IDs are in both the ECU and in the antennas, with the ECU doing the reprogramming of the antennas.

The only way the service bulletin makes sense (based on what you've seen, and what it says) is for the ECU to deliberately remove (forget) the sensor ID numbers from an antenna that has been disconnected for 24 hours. I suspect that the ECU periodically reprograms those antenna modules with the sensor ID values it has.

What were your ID values corrupted to?

But thanks for the bulletin. I bet there is a lot more bulletins out there that would make for interesting reading. Personally, I've love to have a service manual on this thing.

Wouldn't we all. In particular for the CAN bus messages. The holy grail would be to find CAN bus messages for reading and reprogramming the IDs in the ECU.

 

[markwj]

If it can program, then it can read the addresses to. What he did was walk around the car, pointing it at each tire, and "prompted" the tire sensor to transmit. It grabbed the address for each tire.
Then, when he plugged it into the ODBC II connector, it sent the message to program the antennas. I took the car home, removed the antenna and re-read it to see the difference. So it's the same thing I can do, except I physically accessed the LIN bus from under the car, rather than plugged it into the ODBC II plug. (I wonder if one of the ODBC II connector pins is the LIN signal?? ).

The OBDII connector has a single K-line connection to the TPMS ECU.

 

[cwerdna]

Perhaps if enough people actually experiencing TPMS failures file safety complaints w/NHTSA at Home | Safercar -- National Highway Traffic Safety Administration (NHTSA), that might force Tesla's hand.

A quick Google search for tpms recall has revealed such recalls before, so it sounds like failures of such systems are considered recall class, since they are technically safety related.

 

[PowerSource]

Here is the unit I have that reads the sensors. You can program it to write the sensor values through the options menu. If we can get the correct addresses from an official tesla Smartool these TPMS tools can be modified to work on the Roadster. Maybe a future option?

 

[scotty2541]

I suspect that the ECU periodically reprograms those antenna modules with the sensor ID values it has.
.

I doubt it. Since my antennas (rear back in December, and front a few weeks ago) were corrupted, and not restored for days on their own. I had to do it myself.

What were your ID values corrupted to?
.

Look up a few posts you can see my data. But here it is again.

My actual tire addresses were 08 06 66 2E and 08 06 66 EC. You can see these tire sensors are close to each other in numerical addresses

They were corrupted to 44 50 45 6C and 45 6C 44 71

 

[supersnoop]

They were corrupted to 44 50 45 6C and 45 6C 44 71

So, they both had 08 06 66 before, and both had 44 45 6C afterwards (albeit in different orders). Seems like a memory address is getting shifted. Probably a bug somewhere in the firmware.

 

[hcsharp]

Here is the unit I have that reads the sensors. You can program it to write the sensor values through the options menu. If we can get the correct addresses from an official tesla Smartool these TPMS tools can be modified to work on the Roadster. Maybe a future option?

Good find. I wouldn't be surprised if the address on the K-line to the TPMS ECU is already programmed into that tool. It probably just doesn't show up on the menu of car models. Somebody on this board purchased one of those SmarTools before Tesla stopped selling them. If we can find out who it is I bet they would be willing to help us.

 

[markwj]

I doubt it. Since my antennas (rear back in December, and front a few weeks ago) were corrupted, and not restored for days on their own. I had to do it myself

What I mean is that the corruption occurred in the ECU and those corrupted values were what was written out to the antennas. But, then again if that was the fault, why would the front and rear antennas have different values, and only the front be corrupted?

 

[scotty2541]

So, they both had 08 06 66 before, and both had 44 45 6C afterwards (albeit in different orders). Seems like a memory address is getting shifted. Probably a bug somewhere in the firmware.

Nice blue... same as my 2.5.

"They both...?" Only the front antenna had bad addresses, and only 2 of 4 addresses.

The correct address is 08 06 66 2E for the left tire
and for the right tire is 08 06 66 EC
Four bytes, in an eight byte message.

When corrupted it was 44 50 45 6C for the left tire
and for the right tire is 45 6C 44 71

Doesn't appear to be a shift. Just looks scrambled.

If it's a bug in the firmware, why does it reliably take about two years to reoccur? Wouldn't the bug manifest itself at the same time in each sensor? Instead, a sensor seems to decide to forget it's tire address after some period of time.