TPMS Continues to fail. The "New" customer service is non-existent.

[scotty2541]

Me again, the model S dude who posted into this thread wrongly above.

I've been reading along... and I work with electronics and would like to toss in an idea. Because this smells like EEPROM corruption and I've got some experience with that in automotive products...

I'm assuming you've tried 4 x new senders somewhere along the line, or at least tested them to rule out weak batteries there.

Just trying to be helpful, because I feel you. And this would drive me mad too.

Scott,
All excellent ideas. It is EEPROM or FLASH corruption, either from the head unit or an antenna. But the values being corrupted are addresses value being replaced with bytes that are clearly pressure and temperature values. So it's more like the system is active when it corrupts the non-volatile memory locations. These aren't pure random values.

Now that you bring this up, it was in fact exactly two months after my 2016 service that this started. After that service, my AM radio was being swamped with interference where it had never done that before. I took it back several times. They took the dash out, blaming the antenna, the antenna booster, radio grounding... except the original service never involved any of that. It was all around the PEM and power systems. AND it actually destroys radio reception on a portable, unconnected radio. So you can't blame the radio in the car, or any of it's connections. Here's what it does:

It did NOT do that before the 2016 service.

Two months later, the self destruction of the TPMS antennas began. And now repeats like clockwork.

Now, I'm sure it's not memory in the head unit, it's the actual antennas. My original post summarizing the problem shows how the antennas are polled, and how I reprogrammed the antennas and they worked fine. I never did anything with the main controller head unit. And I have to reprogram the antennas over and over...
And the antennas are powered from the head unit, they are isolated (floating) from the chassis ground. (Three wire connection: + , - , data, in a plastic case)

Also, yes all the tire senders had been replaced. In Sept 2015, a year before.

I'm equipped to do all you suggest, it's just a matter of finding time. This is a corner of my home office

 

[scotty2541]

Anybody got a schematic of the TPMS part of the car?

I've the a connection diagram. Nothing on the internals of the unit. It's some company named Balong. I've done searches, but they appear to only be for OEMs so I can't find anything of detail.

 

[PV-EV]

Me again, the model S dude who posted into this thread wrongly above.

I've been reading along... and I work with electronics and would like to toss in an idea. Because this smells like EEPROM corruption and I've got some experience with that in automotive products.

Supplying low voltage to the TPMS head unit, when in the OFF state, might be massaging its brains (causing it to forget the tire sender addresses). And this is very unpredictable as to if/when it might strike but the presence of low voltage within the unit is a clue. If the unit is only supposed to be fully powered (+12v or whatever) when the car is running but is somehow getting some very low voltage instead of zero volts when the car is off, it could corrupt EEPROM while in the off state. I've seen this happen overnight. It takes a while change EEPROM bits with voltage strays.

Get a meter that is sensitive in the 0 to 2 volt range and probe not only the supply line to the TPMS head unit, but also all other lines going into the unit when the car is turn off. This includes bus and data lines or any I/O. It's typically voltages leaking in through I/O lines while the MPU is de-powered is what causes internal EEPROM to get goofy. What's really tough on EEPROM is not just a too-low constant DC voltage but something with a nice little ripple to it.. And it may be rippling about zero so a DC meter will show zero. Flip your meter to A/C and look something there too, or use a scope.. Improperly terminated data lines going into the unit can hit the EEPROM like A/C when signaling is going on.

Similarly if ground is not ground but floating by one diode drop so that it is really +/- 0.7 volts instead of ground this can cause EEPROM to get goofy while "powered off". Clean the grounds and maybe add an extra ground line that runs directly to the +12v battery or whatever is sourcing the power to the unit.

In the most bizarre cases, if you disconnect the power and the ground to the unit, but leave just the data / I/O lines connected, that can be enough to fnark up the EEPROM too. One data line will act as ground as another data line will carry low voltage into the unit with its signaling.

Why is this happening on your car but few others? If you've hooked up any aftermarket electronic stuff, and I'm talking about even simple stuff like LED signal bulbs or a relay or ... anything. Try probing all the TPMS head unit lines with your stuff connected and then disconnected to see if there's a difference. Maybe other cars having same issue all have a similar option or version of some module elsewhere in the car that comes from the factory, and others don't, so you're the lucky ones. And explains why changing the TPMS units again and again is not the answer if something elsewhere is causing leakage into it.

I'm assuming you've tried 4 x new senders somewhere along the line, or at least tested them to rule out weak batteries there.

Just trying to be helpful, because I feel you. And this would drive me mad too.

These are excellent ideas and would help explain why a small but significant number of cars exhibit the problems but many cars do not. My 2.5 has been TPMS trouble free since new. Even after having the rear antenna ejected from the car in an accident (and subsequently repaired). I notice that there seems to be a pair of unused RS232 lines on the TPMS MCU. I wonder if these could cause a problem, depending on how they are (or aren't) terminated. It is possible that during assemble of a small volume car like the Roadster that some things got wired slightly differently on some cars than on others.

 

[scottm]

@scotty2541 I think we have the same identical oscope on the bench. And same first name. Uncanny.

It sounds like you've narrowed the issue down to antennas instead of head unit. The antennas themselves are what's storing the learned addresses of wheels on that end of the car. The whole low voltage leak conversation can be directed at the antenna module and its data lines.

This:

values being corrupted are addresses value being replaced with bytes that are clearly pressure and temperature values

sounds like a software bug. However, can be attributed to EEPROM corruption if the pointer to the values is also stored in EEPROM. If the pointer corrupts the temp/pressure values will be written to wrong spot... like over top of the unique address.

The most susceptible position in EEPROM to get corrupted is $0 because that's the resting position of an unpowered chip's read/write pointer. So if you're massaging the chips with low voltage position $0 is the recipient. BUT it can also happen at any other location on the chip!

What's weird is why would BaoLong (same brand as in my 2014 Tesla S) be writing temp & pressure values to non-volatile memory at all? If it's doing this all day long, it will literally wear out memory's ability to store values. You get so many cycles and she degrades. If they're doing some cyclic pattern to spread the wear evenly, that helps... but if the sampling and writing rate is too high it's still going to wear out memory. This phenomena is in the realm of "planned obsolesce"... like "who cares if it goes kaput after 1,000,000 cycles by then the product is obsolete..." but if the software is glitching or restarting 10x or 100x or 1000x as often as it should... (e.g. intermittent power connection causing reboots) ... you'll hit the million faster than anybody planned.

Or writing too often with a wear spreading algorithm in place may cause a "wrap" back around to $0 and then starts wiping out stuff that it was never intended to reach, or never tested to reach... you know, too lazy to run it through a million cycles. I'm moving my betting chips to this scenario. Especially if after testing you find no ghost voltages at the antenna end... then it's software reacting to atypical series of events.

You have the ability to directly read/write values on these antennas? Then read the whole range of memory and how big is the memory... is it filled with nearly the same values? Runaway code, or the wear leveling pointer has been incrementing a lot. (The pointer itself must also be in non-volatile by definition.. so it's dicey if a single spot pointer is too frequently changing the pointer will wear out before the more important memory holding the values does! So the pointer must also move along in rotation through memory too.. tricky to do this stuff right.)


With the discussion about eeprom wear leveling ... I would now suspect something causing too-frequent reboots of the antenna modules. Which can be noise induced, or quality of power / disruption of power happening at the antenna. The connectors are a good place to start. Jiggle them, as in driving vibration.... And watch for glitches on your cool scope connected to the inside of the antenna.

Little dropouts present?? Add some bad ass big power filtering capacitors inside the antenna unit. Prevent those caps from back-powering the source line by introducing a diode like this:

----------power--line--------------|| connector on module --||-----inside module now----->|----// cap -----better power for module

Friend of mine has experience with airbag systems and says some can be so susceptible to intermittent / poor quality connector induced noise, and will throw fault codes...after replacing all modules that the only cure left to do is eliminated connectors and start soldering wires together. Works!

You do know that FCC has something to say about causing that kind of radio interference!? It's on the manufacturer to STOP IT... here you can show the car is a noise emitter. You have a case. You can try to hunt it down by unplugging random stuff until your AM ghetto blaster shuts up. Maybe you find the component to show Tesla and FCC what's creating too much noise, file a complaint, and ask for a fix.

 

[gregd]

Thinking about this in terms of the overall population of 2.x cars, who may be unwittingly subject to a similar failure mode in the future. Would it be possible to get a really detailed account of what was done in that infamous 2016 service event? Assuming you can get their attention, of course. The possibility that a connector was loosened / removed, or mis-inserted (bent pin?), seems like something that could happen to any of us, and we (I, at least) would want to be armed with this knowledge should mine "fail" prematurely.

A normal yearly service involves removing the PEM and other related stuff in the rear of the car for the ritual de-leafing ceremony. Do any of the antenna wires route through it? I have a hard time believing they would, but odder things have been discovered. Your AM radio demo sounds similar to my in-dash unit, but yours seems to be worse, like a ground is missing. I can at least hear the local powerhouse (though not cleanly), unless strongly in acceleration or regen. Since you now have access to the LIN bus, perhaps string a wire to the power / ground lines and monitor them while driving. Bets are that there is a lot of junk on them...

 

[scottm]

If power is solid at the antennas... and there's no ghost power, then the problem shifts to ambient noise or software related. You know you picked up noise in the 2016 service.

But you may have also picked up new software.

If they downloaded new firmware into the TPMS unit during 2016 service, that software may be the culprit... even if new software did not propagate as far as into the antenna. Maybe TPMS is now programmatically polling or causing too many resets of the antenna module.

From the antenna module's perspective: it may be receiving an explicit reset from TPMS too often. Or it may be receiving a poorly formed command or even a properly formed command but of an invalid operation which has a side effect of causing the antenna to reset. A very innocuous "read" command of the antenna could trigger it, if, say, the TPMS is asking to read a value type or address that is out of range for your poor antenna's version of software or capability. Different versions of BaoLong antennas may have different capabilities and ranges of values it can answer to. The TPMS might not know which version of antenna it's dealing with, or for some reason has gotten it mis-matched with the commands it's trying to use with it.

How often does TPMS poll the antenna to collect its values? Every 5 seconds maybe? Each poll with a malformed command causes a reset, advances the memory leveling algorithm counters and pointers to increment.... hit a million or whatever and you wrap. You could do the math of driving time hours multiplied by number of polls to predict when the next fail will happen.

 

[Stefan T]

My car have no TPMS hardwere, but after som voltage drop in 12V system i got hardwere error, and TPMS error code evrytime i start my car,
Tesla can fix it but not on the nearst service center, so in that case i need go to Denmark for have it done, but it's to far to drive to,(can do it now after JeDemo installation)

If this is hint how i t works, idon't know

 

[dpeilow]

@Kerios was having similar issues and fitted an aftermarket system. I forget the maker, perhaps he can remind us.

 

[dhrivnak]

It is possible that during assemble of a small volume car like the Roadster that some things got wired slightly differently on some cars than on others.

YES. At one point my accelerator potentiometers would not agree and they had to replace the rear wiring harness there was a 9 pin plug to detect if the charge port for was closed as the car will not run with it open. The wires on the new wire harness were different and we had to splice wires to get it to work.