Ironic to think that a TPMS might get to Mars before people.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
TPMS CONTINUES TO FAIL... [RANT] And they are gonna send people the mars?
- Thread starter scotty2541
- Start date
An Update on my quest for a functional TPMS setting tool for Roadster Serial 501 and up and 2012-2014 Model S.
The cars listed all have the Baolong sensors...
The Telsa tool is a custom modified Valor/Baolong SmartTool custom manufacturer by Valor for Tesla.
Unfortunately the tool I bought from Valor was not the same as Tesla - They will not sell the Tesla tool.
The Valor SmartTool is their model GJ002 and the Valor Tesla SmartTool is their Model GJ005B.
I was hoping to get some help from Valor on getting the tool to output K-line data to update the Tesla ECU.
I got no help at all from Valor. They all got lockjaw when I asked questions about Tesla and protocols.
The would not even answer questions about their tool and the protocol of the output for Valor applications.
I sent the tool back for a refund.
In the meantime I researched the ATEQ product line.
The ATEQ product literature claimed compatibility with Tesla - Roadster, Model S, and Model X.
I purchased the VT55 tool for $497. This was close to the $500 Tesla sold their tool for...
The ATEQ VT55 was obsoleted in January 2017 and used to sell for $1200.
They have promised to support the tool to or through 2022.
There are more available on eBay($497 or best offer) and through Amazon.
The tool readily acquired the addresses of the tire sensors.
The problem was the tool could not send them to the car by OBDII.
I have been in touch with ATEQ support which has been good.
They have asked intelligent questions.
My last contact with them confirmed that their tests matched my tests and they know that they need to
add the OBDII output by K-line to update the Tesla cars.
They have committed to do this.
When they are done, the change will be released as an internet update to the tool's software.
I do not know what their schedule is for the update but I am watching closely.
I will post an update when I see and successfully test the new software release.
Shawn
The cars listed all have the Baolong sensors...
The Telsa tool is a custom modified Valor/Baolong SmartTool custom manufacturer by Valor for Tesla.
Unfortunately the tool I bought from Valor was not the same as Tesla - They will not sell the Tesla tool.
The Valor SmartTool is their model GJ002 and the Valor Tesla SmartTool is their Model GJ005B.
I was hoping to get some help from Valor on getting the tool to output K-line data to update the Tesla ECU.
I got no help at all from Valor. They all got lockjaw when I asked questions about Tesla and protocols.
The would not even answer questions about their tool and the protocol of the output for Valor applications.
I sent the tool back for a refund.
In the meantime I researched the ATEQ product line.
The ATEQ product literature claimed compatibility with Tesla - Roadster, Model S, and Model X.
I purchased the VT55 tool for $497. This was close to the $500 Tesla sold their tool for...
The ATEQ VT55 was obsoleted in January 2017 and used to sell for $1200.
They have promised to support the tool to or through 2022.
There are more available on eBay($497 or best offer) and through Amazon.
The tool readily acquired the addresses of the tire sensors.
The problem was the tool could not send them to the car by OBDII.
I have been in touch with ATEQ support which has been good.
They have asked intelligent questions.
My last contact with them confirmed that their tests matched my tests and they know that they need to
add the OBDII output by K-line to update the Tesla cars.
They have committed to do this.
When they are done, the change will be released as an internet update to the tool's software.
I do not know what their schedule is for the update but I am watching closely.
I will post an update when I see and successfully test the new software release.
Shawn
Here's an update on my situation...
I haven't done any work on it because apparently, I got someone's attention. The new manager of the service center called me and stated that he wants to look at this issue, and would prefer that I deal with him personally. No doubt that complaining on this, and many other social media sites has been noticed. So I have left it to fail, and let him deal with it, and he is contacting engineering often (to use a car analogy, ironically, the "squeaky wheel"...).
So if he is fighting for me, I don't want the company to come back and say it's all because I've been monkeying around with it. So I'll be hands off.
Up until September of 2017, I was getting failures every 3 months, then 2 months, and getting more frequent. And I was examining the problem, and seeing that the antenna addresses were being corrupted, and I was reprogramming them myself. The most recent corruption was about two weeks after my last fix. I accused it of sabotage, more out of sarcasm than seriousness.
I took my car and all my data in, and discussed it with the manager. He understood what I saw, and explained that it was beyond the scope of what they examine, which I understand from the point of view of a service operation. But I also pointed out that I suspect some things:
Well, it now took over 5 months before the data was corrupted again. So apparently the wire harnesses has something to do with it. I left the system untouched and unsniffed until I was able to take it into the service center. Then the manager and I ran some testing.
I returned to the service center and he read the control unit to see what addresses it thought it was seeing. They were wrong, I could tell right away, because one address was far afield from the others, and all my tire transmitters were about the same number range. Then he read the actual tires. We could see the difference. I then hooked up my sniffer and showed him the communication, and the corrupted addresses. In this case, it was the rear antenna. While I was sniffing it, he reprogrammed the antennas, and I showed him the correct sniffer data, and that it matched what his tool had.
I suspect inferior or noisy wiring coupled with poor data validation.
How could it happen? Imagine this:
Since this is a common bus, imagine that the control unit sends a command on the bus to tell the front antenna to report it's pressure/temp data. But due to noise the rear antenna hears not a command for someone else to report data, but a command to reprogram itself (a "23" was heard as a "13" due to some noise). The rear antenna sees the reprogram command followed by 8 bytes of data on the bus which came from the front antenna (it can't tell who put that data on the bus, it all looks legitimate). Next thing that occurs, is the addresses of the rear antenna have been set to values that are temp/pressure data which the front antenna was sending. This is possible because the message checksum does NOT include the command byte, only the 8 byte payload data.
So, that's my theory. Solving the design means altering the protocol. Every 90 seconds the control unit asks the antennas what addresses they have. If the control unit actually stored the addresses (which it does not appear to do), it could correct an antenna that got corrupted.
If I knew the CAN messages, I'd just build my own control unit to do that. But as they said... "we aren't telling you anything, and we aren't fixing anything" (paraphrased). So, we are currently at the mercy of our own research.
Enjoy!
-Scotty
I haven't done any work on it because apparently, I got someone's attention. The new manager of the service center called me and stated that he wants to look at this issue, and would prefer that I deal with him personally. No doubt that complaining on this, and many other social media sites has been noticed. So I have left it to fail, and let him deal with it, and he is contacting engineering often (to use a car analogy, ironically, the "squeaky wheel"...).
So if he is fighting for me, I don't want the company to come back and say it's all because I've been monkeying around with it. So I'll be hands off.
Up until September of 2017, I was getting failures every 3 months, then 2 months, and getting more frequent. And I was examining the problem, and seeing that the antenna addresses were being corrupted, and I was reprogramming them myself. The most recent corruption was about two weeks after my last fix. I accused it of sabotage, more out of sarcasm than seriousness.
I took my car and all my data in, and discussed it with the manager. He understood what I saw, and explained that it was beyond the scope of what they examine, which I understand from the point of view of a service operation. But I also pointed out that I suspect some things:
- All those TMPS failures over the years where they replaced parts, I now suspect were memory corruption issues, and the parts replacement was unnecessary
- The frequency of these failures suddenly increased when they kept taking apart the dash trying to determine why suddenly the car was jamming AM radios (see Suddenly, the car is jamming AM radio stations. )
Well, it now took over 5 months before the data was corrupted again. So apparently the wire harnesses has something to do with it. I left the system untouched and unsniffed until I was able to take it into the service center. Then the manager and I ran some testing.
I returned to the service center and he read the control unit to see what addresses it thought it was seeing. They were wrong, I could tell right away, because one address was far afield from the others, and all my tire transmitters were about the same number range. Then he read the actual tires. We could see the difference. I then hooked up my sniffer and showed him the communication, and the corrupted addresses. In this case, it was the rear antenna. While I was sniffing it, he reprogrammed the antennas, and I showed him the correct sniffer data, and that it matched what his tool had.
I suspect inferior or noisy wiring coupled with poor data validation.
How could it happen? Imagine this:
Since this is a common bus, imagine that the control unit sends a command on the bus to tell the front antenna to report it's pressure/temp data. But due to noise the rear antenna hears not a command for someone else to report data, but a command to reprogram itself (a "23" was heard as a "13" due to some noise). The rear antenna sees the reprogram command followed by 8 bytes of data on the bus which came from the front antenna (it can't tell who put that data on the bus, it all looks legitimate). Next thing that occurs, is the addresses of the rear antenna have been set to values that are temp/pressure data which the front antenna was sending. This is possible because the message checksum does NOT include the command byte, only the 8 byte payload data.
So, that's my theory. Solving the design means altering the protocol. Every 90 seconds the control unit asks the antennas what addresses they have. If the control unit actually stored the addresses (which it does not appear to do), it could correct an antenna that got corrupted.
If I knew the CAN messages, I'd just build my own control unit to do that. But as they said... "we aren't telling you anything, and we aren't fixing anything" (paraphrased). So, we are currently at the mercy of our own research.
Enjoy!
-Scotty
Hi Hcsharp,
Ateq is committed to be the best TPMS supplier in the world.
Although they discontinued the tool last year, there were 4 major software releases for it last year.
Don't forget that programming the TPMS for Roadster with Baolong sensors is the same as programming Model S with
Baolong sensors 2012-2014. That makes the population of cars benefitting from the software larger.
If you look at a larger picture, most, if not all of the cars they program for are obsolete...
It does not mean they do not need their TPMS programmed.
The protocol to update the ECU in Tesla is very similar to Toyota, so they will not be reinventing the wheel,
just fine tuning their programs for another use. Like all programmers have done forever...
Their VT56 which is their flagship product has continuously advancing software for new and older cars.
Since the software is nearly identical to the VT55, the effort required to port the software to VT55 is minimal...
Scotty,
I will upload the diagrams from the Valor system, I believe they may have the codes you need on the last page.
To all interested readers,
The way I have always envisioned this project is to divide the project into steps.
The first step is to get a tool that will read and write the TPMS to the car. Roadster or Model S
The second step is to put our monitoring tools on the K-line and CAN BUS while this writing is occurring.
Since we know the sensor addresses being transmitted - it should be fairly straightforward to monitor the K-line
to interpret and decode this transmission of data.
I believe it is only during the TPMS programming that the K-line is active.
That is why no one monitoring the K-line has yet seen any data on it.
Part of the second step is to also monitor the CAN BUS while the TPMS ECU is updated.
The antennas are receiving the tire IDs by CAN BUS or by K-line.
Whichever protocol is used, if captured during the update we should have the information
on how they are updated.
When we have that information there are many ways to proceed...
Scotty could make a spoofer, a filter, or a periodic rewrite of the proper addresses...
We must know the protocols and data structures first and I am continuing to pursue them...
Shawn
Ateq is committed to be the best TPMS supplier in the world.
Although they discontinued the tool last year, there were 4 major software releases for it last year.
Don't forget that programming the TPMS for Roadster with Baolong sensors is the same as programming Model S with
Baolong sensors 2012-2014. That makes the population of cars benefitting from the software larger.
If you look at a larger picture, most, if not all of the cars they program for are obsolete...
It does not mean they do not need their TPMS programmed.
The protocol to update the ECU in Tesla is very similar to Toyota, so they will not be reinventing the wheel,
just fine tuning their programs for another use. Like all programmers have done forever...
Their VT56 which is their flagship product has continuously advancing software for new and older cars.
Since the software is nearly identical to the VT55, the effort required to port the software to VT55 is minimal...
Scotty,
I will upload the diagrams from the Valor system, I believe they may have the codes you need on the last page.
To all interested readers,
The way I have always envisioned this project is to divide the project into steps.
The first step is to get a tool that will read and write the TPMS to the car. Roadster or Model S
The second step is to put our monitoring tools on the K-line and CAN BUS while this writing is occurring.
Since we know the sensor addresses being transmitted - it should be fairly straightforward to monitor the K-line
to interpret and decode this transmission of data.
I believe it is only during the TPMS programming that the K-line is active.
That is why no one monitoring the K-line has yet seen any data on it.
Part of the second step is to also monitor the CAN BUS while the TPMS ECU is updated.
The antennas are receiving the tire IDs by CAN BUS or by K-line.
Whichever protocol is used, if captured during the update we should have the information
on how they are updated.
When we have that information there are many ways to proceed...
Scotty could make a spoofer, a filter, or a periodic rewrite of the proper addresses...
We must know the protocols and data structures first and I am continuing to pursue them...
Shawn
Hi Markwj,
I was hoping the information in the explanation column could be helpful.
From the time I worked with their tool, they used a numbering system of 4 tires per axle.
First axle left would be 1A, second left tire if used would be 1B, inside right would be 1C, and the outside would be 1D.
Second axle left outside would be 2A, second left tire on second axle would be 2B, inside right on the second axle would be 2C,
and the outside right on the second axle would be 2D.
I was hoping that the hex codes and formatting could relate to something on the Roadster system...
That document comes from large equipment where a low pressure is 100 psig.
Shawn
I was hoping the information in the explanation column could be helpful.
From the time I worked with their tool, they used a numbering system of 4 tires per axle.
First axle left would be 1A, second left tire if used would be 1B, inside right would be 1C, and the outside would be 1D.
Second axle left outside would be 2A, second left tire on second axle would be 2B, inside right on the second axle would be 2C,
and the outside right on the second axle would be 2D.
I was hoping that the hex codes and formatting could relate to something on the Roadster system...
That document comes from large equipment where a low pressure is 100 psig.
Shawn
An update,
Ateq is committed to updating the software in their tools to correct for the Tesla update process.
When.........? Who knows.
In the meantime, I purchased the Microchip LIN serial analyzer APGDT001.
This is the tool Scotty reported using in his development work...
I keyed the commands Scotty gave in his writings into the OBD2 connector.
The car seemed to accept the commands without error into the K-line (Pin 7), CAN High line (Pin 6),
and the Mfr. discretion K-line (Pin12).
Unfortunately after issuing the commands into these points nothing updated.
Then I removed the rear antenna and used the tool on the antenna removed from the rear of the car.
According to Scotty:
Command 12 and 16 bytes (characters?) of data update the front tire addresses into the rear antenna.
So 12 08811495 0881136B and update. I left a space between the two groups of 8 for legibility.
Command 13 and 16 bytes of data update the rear tire addresses into the rear antenna.
So 13 08811B51 088118B2 and update. Again I left a space for legibility.
These are my tire's addresses as obtained from the Valor Smartool and the Ateq VT55.
I replaced the rear antenna and I took a test drive without the bottom pan in place.
I was barely out of the drive and all 4 tires pressures and temperatures populated.
All good data!!!
Scotty - "You are the Man!"
Shawn
Ateq is committed to updating the software in their tools to correct for the Tesla update process.
When.........? Who knows.
In the meantime, I purchased the Microchip LIN serial analyzer APGDT001.
This is the tool Scotty reported using in his development work...
I keyed the commands Scotty gave in his writings into the OBD2 connector.
The car seemed to accept the commands without error into the K-line (Pin 7), CAN High line (Pin 6),
and the Mfr. discretion K-line (Pin12).
Unfortunately after issuing the commands into these points nothing updated.
Then I removed the rear antenna and used the tool on the antenna removed from the rear of the car.
According to Scotty:
Command 12 and 16 bytes (characters?) of data update the front tire addresses into the rear antenna.
So 12 08811495 0881136B and update. I left a space between the two groups of 8 for legibility.
Command 13 and 16 bytes of data update the rear tire addresses into the rear antenna.
So 13 08811B51 088118B2 and update. Again I left a space for legibility.
These are my tire's addresses as obtained from the Valor Smartool and the Ateq VT55.
I replaced the rear antenna and I took a test drive without the bottom pan in place.
I was barely out of the drive and all 4 tires pressures and temperatures populated.
All good data!!!
Scotty - "You are the Man!"
Shawn
I got my 2010 2.5 in 2011. About a months ago all my TPMS transmitters died within a few weeks of each other. I figure seven years is not bad for these things.
On the subject of going to Mars: Half of all Mars probes have crashed, destroying the mission. No magnetosphere, almost no atmosphere. Literally 55 million to 400 million miles from "anywhere." Seven months for help in case of emergency. Only the most basic medical facilities on your ship. (The ISS has only basic facilities, but in an emergency you are a few hours from home.) Confined in crowded quarters with people you cannot get away from when you get sick of the stink of their farts or their habit of sucking their teeth.
Joseph Heller's book, Catch 22, defines the "catch 22" of the title as: You can be relieved of duty if you are insane. But you must request it. And if you request to be relieved of duty, that is proof that you are sane, and your request is denied.
A Mars mission is doomed to fail if the crew are all insane, but no sane person would volunteer to go. Unless you are suicidal and want to be remembered as the first human to die on Mars. The chances that a bad TPMS will cause the failure of a Mars mission are one in a billion, because there are a billion other things that will go wrong first. We could send people to Mars today, if we didn't care that they'd be dead when they got there. They still have no idea how to shield the capsule from cosmic rays. A sufficient amount of lead would do it, but that costs to much to launch and then to accelerate and decelerate for the trip. No idea at all how to do it. (The ISS is within the Earth's magnetosphere, which protects it. The Apollo astronauts were outside the magnetosphere only for about 5 days.)
PV-EV,
I purchased a CAN analyzer, and wired an adapter for the under dash plug (driver side).
These pins match other research I've done. I also confirmed at least that the BATT line is 12V
I set it for 1Mbs data speed, listen mode. Turned on the car, and got the usual "Door Open" alert on my VDM.
But I'm not getting any CAN at all. No data.
I also hooked my DVM on the CanL and CanH lines, and both are rock solid at 2.44 V So it looks like the line is just idle.
Is there any trick to getting the CAN data to appear on the plug?
-Scott
Sorry but I can’t help you. I only have the pinouts, not the info on how to use them. My TPMS has worked without fault for 7 years so I haven’t needed to look into it. I have been expecting a failure for some time which is why I’m following this thread.
You and Shawn are the go to guys when it comes to TPMS
Okay, so I can expect silence on the driver side connector?
Do we have the pinout for that Diag? I haven't even looked at it.
-Scott
CAN1 on 1 and 6 (VDS, TPMS ECU, Instruments, etc)
CAN2 on 2 and 7 (HVAC, ESS)
K-Line on 3 (TPMS)
CAN3 on 4 and 11 (SwitchPack, ABS, GearShift, PEM)
CAN4 on 5 and 12 (same as OBDII connector - unknown functionality)
GND on 9
+12V on 10 (constant)
The standard OVMS cable for Tesla Roadster exposes PWR, GND, and CAN1 to a DB9-F.
We are working on a new OVMS Tesla Roadster (and early Model S) cable that exposes PWR, GND, CAN1, CAN2, CAN3, and K-Line, to the same DB9-F. That should be available in a couple of weeks (just going into production early next week).
Okay, hang on...
The post from PV-EV says CAN are on pins 6/14, which match the industry standard.
What connector are you referring to? Clearly not a DB9, and not the driver because I confirmed BAT on pin 16
Hi Scotty,
I think he is referring to a New Harness soon to be made for the new OVMS3. (DB9)
PV-EV was referring to the OBD2 on the driver's side.
Mark is referring to the one we hook up to OVMS3 on the passenger side.
The genders of the connections are different too.
Female on driver's side and male on the passenger side.
Shawn
I think he is referring to a New Harness soon to be made for the new OVMS3. (DB9)
PV-EV was referring to the OBD2 on the driver's side.
Mark is referring to the one we hook up to OVMS3 on the passenger side.
The genders of the connections are different too.
Female on driver's side and male on the passenger side.
Shawn
I am referring to the Tesla Diagnostic connector (in the passenger footwell). That is the only one with the useful CAN buses on it. PV-EV is referring to the OBDII connector (which has nothing of use to use except for power and K-line, and is on the driver's side). The DIAG connector looks like this (and instrument bus pins highlighted):
automixcars
Member
Hallo ALL
after reading ALL your reverse troubleshooting I am still not sure how to find the TPMS hardware fault on my 2.0 roadster.
my questions are ?
is there a "new antenna that can be installed in the front that works" and I can bye?
will the new owms 3. be able to fix the problem?
is there a other tool that can tx the wheel sensores id to the car?
is there a way to get the car not to set the tpms fault and just not have the values on the screen?
I have installed 4 new sensores universal from autel and programed them to balong 2010-2012 (found this to be the correct after hacking the old with external 3v power supply on them
I have also x changed from a other roadster tmps unit
next step change antennas
was at DK tesla dealer for 2 hours and they was not able to help me :-(
therefore I look to you ALL on this forum
Kind regards Michael
after reading ALL your reverse troubleshooting I am still not sure how to find the TPMS hardware fault on my 2.0 roadster.
my questions are ?
is there a "new antenna that can be installed in the front that works" and I can bye?
will the new owms 3. be able to fix the problem?
is there a other tool that can tx the wheel sensores id to the car?
is there a way to get the car not to set the tpms fault and just not have the values on the screen?
I have installed 4 new sensores universal from autel and programed them to balong 2010-2012 (found this to be the correct after hacking the old with external 3v power supply on them
I have also x changed from a other roadster tmps unit
next step change antennas
was at DK tesla dealer for 2 hours and they was not able to help me :-(
therefore I look to you ALL on this forum
Kind regards Michael
In answers to your individual questions...
1. Is there a new antenna? I don't think so.
2. I am not familiar with owms.3...
3. Is there a tool? The Tesla service is supposed to do that.
(Note, if he couldn't read the addresses, or he programmed the controller and it can't hear the wheel sensors, then you may have the wrong transmitters... The local tire shop *thought* they new which sensor types were for my car, but their information was wrong)
My Balong antennas use a 5V supply.
4. Is there a way to get the car to not send the TPMS fault? We haven't found a way. There were some ideas, but nothing worked out.
The following link is a VERY long read, but it is my research, and many helpful contributors adding to the research.
That TPMS issue, summarized
In my case:
A year and a half ago, I was contacted by my local service center and asked to bring my car in so they could look at the problem. I guess all my complaining got someones attention.
Of course, the limit of their understanding is simply replace parts.
I summarized all this data, and gave it to the service manager. He told me clearly it was out of the realm of the service center, and he sent it to the factory. He said he'll let me know what they say, in the mean time, call him if it fails again.
It failed about 2 weeks later... :-(
I did hook up my sniffer and could see the rear antenna was de-programmed AGAIN. I did not fix it myself.
Naturally, I never heard back from the factory. I don't think the service manager ever did either. He was transferred shortly after.
(Opinion - Tesla, as a car company, clearly doesn't give a CRAP about customer relations... They tried to address it, and commenced to just drop it again, thinking just one empty "reach-out" would make me satisfied.
Which is why the next cars I bought were from companies that DO follow up and care about customers. Who cares about how cool EV is, if the company sucks??)
Well, oddly enough, it has not given me an error again. And I do have reading for all four wheels. Then I went in for service, and they told me nothing about it. I do not believe anyone ever reprogrammed the antenna that was erased/corrupted, and I haven't examined it since. So as far as I can tell, only the front antenna is still correctly programmed, and it is detecting all four wheels, and the back antenna is still corrupted.
So I conclude somewhere, some time, someone tweaked the car firmware to say "If I have readings from just one antenna, I won't complain". And never told the customer anything.
Hope this is helpful.
-Scott
1. Is there a new antenna? I don't think so.
2. I am not familiar with owms.3...
3. Is there a tool? The Tesla service is supposed to do that.
(Note, if he couldn't read the addresses, or he programmed the controller and it can't hear the wheel sensors, then you may have the wrong transmitters... The local tire shop *thought* they new which sensor types were for my car, but their information was wrong)
My Balong antennas use a 5V supply.
4. Is there a way to get the car to not send the TPMS fault? We haven't found a way. There were some ideas, but nothing worked out.
The following link is a VERY long read, but it is my research, and many helpful contributors adding to the research.
That TPMS issue, summarized
In my case:
A year and a half ago, I was contacted by my local service center and asked to bring my car in so they could look at the problem. I guess all my complaining got someones attention.
Of course, the limit of their understanding is simply replace parts.
I summarized all this data, and gave it to the service manager. He told me clearly it was out of the realm of the service center, and he sent it to the factory. He said he'll let me know what they say, in the mean time, call him if it fails again.
It failed about 2 weeks later... :-(
I did hook up my sniffer and could see the rear antenna was de-programmed AGAIN. I did not fix it myself.
Naturally, I never heard back from the factory. I don't think the service manager ever did either. He was transferred shortly after.
(Opinion - Tesla, as a car company, clearly doesn't give a CRAP about customer relations... They tried to address it, and commenced to just drop it again, thinking just one empty "reach-out" would make me satisfied.
Which is why the next cars I bought were from companies that DO follow up and care about customers. Who cares about how cool EV is, if the company sucks??)
Well, oddly enough, it has not given me an error again. And I do have reading for all four wheels. Then I went in for service, and they told me nothing about it. I do not believe anyone ever reprogrammed the antenna that was erased/corrupted, and I haven't examined it since. So as far as I can tell, only the front antenna is still correctly programmed, and it is detecting all four wheels, and the back antenna is still corrupted.
So I conclude somewhere, some time, someone tweaked the car firmware to say "If I have readings from just one antenna, I won't complain". And never told the customer anything.
Hope this is helpful.
-Scott
Similar threads
