Yes! That's my point. Glad to see my write-ups are being understood... I'm not always sure I can get the instruction across.
-
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
Yes! That's my point. Glad to see my write-ups are being understood... I'm not always sure I can get the instruction across.
This whole system just seems needlessly complicated.
We have four sensors (one in each wheel). Then, we have 4 trigger units, 2 antennas (each with their own cpu), and an ECU control module. I make that 11 boxes.
Then, that ECU speaks over two different LIN buses (to the two antenna modules), CAN to the VMS/VDS, and K-Line to the OBDII port. Three different protocols. No idea how the trigger units connect.
We have four sensors (one in each wheel). Then, we have 4 trigger units, 2 antennas (each with their own cpu), and an ECU control module. I make that 11 boxes.
Then, that ECU speaks over two different LIN buses (to the two antenna modules), CAN to the VMS/VDS, and K-Line to the OBDII port. Three different protocols. No idea how the trigger units connect.
6 years on the tire transmitters?? I'm sure they are fading by now.
As I suspected, they don't actually troubleshoot, they just pull and replace hoping for a hit.
I'd go visit a Discount Tire store, and ask him to check the tire transmitters. I bet they could replace and reprogram them to, with the device that was shown in an earlier post.
Well there's my motivation. I'll have to start designing something in my part time. The only disadvantage is the need to disconnect the antennas to install it, because there cannot be two devices replying to the same message.
I knew I'd get some nice jokes on this one.
I just wish I could correct my typo in the title. "Send People to Mars"...
Maybe...
Even though there are two LIN connectors, it's only one bus. I know this because:
- I spliced into the rear antenna connector and I could see the message request and reply that went to the front antenna
- I was able to INJECT a programming message into the spliced connection on the rear antenna, and fix the front antenna.
So, clearly, those connections are just bridged inside the ECU... I wonder is the "K" line is just a LIN data line bridged from the antenna buss, and we could talk to it that way. I'd have to hook up a scope to examine it.
The LIN spec is that someone sends a one byte message, which is predefined by cooperation that it means "Write" or "Read". It's is only one wire and each guy simply "pulls it to ground" to send a bit. (Pulled low to ground is a "1" bit, If it's left high means a "0" bit, I believe).
All the routine messages from the MCU are "Read" message comands, because all it does it read the data from the antennas. So, the master sends a "23" and a predesignated slave knows to respond with his message (8 bytes). If the master doesn't detect any bit being pushed onto the line, it knows the slave is dead (the final checksum will be wrong, as it's just all "0" bits ).
A "10" is a command that means the master is also writing 8 bytes afterward in this case, it's a "Set Tire Address" message. No slave should be pushing data onto the line if it hears a "10"
Because of this design, another slave device could not reply to the same message. That data would collide on the wire. If I wanted to create an emulator to fake it out, the actual antenna we are replacing would have to be disabled.
OTOH, it also means any other device could act as a master and inject a command, as long as he times it right so he's not colliding with the real master. That is how I was able to reprogram the front antenna on an active bus. I fired the command in between the 2 second pauses from the ECU messages.
If the "K" line is just the LIN data bus wire, we could attach a programmer there to reprogram the device, or even an emulator there once the physical antennas are unplugged.
strider
Active Member
That would be awesome. IIRC they quoted something like $500 for the module plus labor to tear the whole dash out. Plus it'll just fail again at some point so I'd end up doing it all again.
I am handy so have no problem finding and disconnecting the antennas.
I was thinking the same thing as I was reading your post. However, many of us have a Tattler or OVMS plugged into the ODBII port (at least I think it's the ODBII port - the one in the passenger footwell) so if you go that route w/ the emulator make sure it has a pass-through for the other wires to another ODBII port for the Tattler/OVMS. The upside is it's a lot more environmentally friendly in the cabin vs how it would need to be built to survive where the antennas are.
Last edited:
The OBDII port is the one by the driver's right leg (LHD cars). The one in the passenger footwell is the Roadster-specific diagnostic port.
The standard OBDII dongles don't work on the OBDII port - the required CAN bus interface doesn't appear to be present (or otherwise not working). If it's got other interfaces (K-line?), that would be a bit of a surprise.
The front antenna is under the front undershield. The front trigger modules are inside the front wheel arch liners.
The rear antenna is under the rear diffuser tray panel. The rear trigger modules are inside the rear wheel arch liners.
The TPMS ECU is under the dash, driver's side, beneath the aircon duct.
At least that is what the documentation I saw a while ago said.
As that K-line pin on the OBDII connector talks to standard TPMS tools, it should talk standard OBDII protocols. For K-line, that is ISO 9141-2 and ISO 14230-4. Async 10.4kbps with a weird 5bps initialisation sequence. A standard OBDII dongle should be able to talk to that connector. The higher-level protocol should also be standard OBDII style PID queries.
From what I have seen, the trigger units in the wheel well are only on the 1.5
Okay, so I see that "K-Line" is an ODBC II protocol, and it's not "LIN". So I can't just plug in my LIN tool and reprogram the units.
Now, thinking about this, the ECU losses power when the car if off, so it would logically forget the tire addresses. Studying this protocol, the ECU really doesn't need to know them anyway. Every 90 seconds, it asks the antennas what tire addresses are set, and it appears the two antennas have to match, or the system gives an error (as mine did when the front antenna lost it's mind).
So, to create an emulator, all I have to do it have a single unit that replies to ALL messages (four messages every 2 seconds for the tire data, and four messages every 90 seconds to reply what the tire sensor addresses are). Set the unit to reply with some phony addresses, because who cares?! LOL!
Then, disconnect the front and rear antennas, and plug the emulator in, it should fool the system and shut it up.
I am ordering the parts, developing the micro code, and starting the circuit board design. No promises as to when I actually finish it, since it's a side project.
But anyone interested?
Now, thinking about this, the ECU losses power when the car if off, so it would logically forget the tire addresses. Studying this protocol, the ECU really doesn't need to know them anyway. Every 90 seconds, it asks the antennas what tire addresses are set, and it appears the two antennas have to match, or the system gives an error (as mine did when the front antenna lost it's mind).
So, to create an emulator, all I have to do it have a single unit that replies to ALL messages (four messages every 2 seconds for the tire data, and four messages every 90 seconds to reply what the tire sensor addresses are). Set the unit to reply with some phony addresses, because who cares?! LOL!
Then, disconnect the front and rear antennas, and plug the emulator in, it should fool the system and shut it up.
I am ordering the parts, developing the micro code, and starting the circuit board design. No promises as to when I actually finish it, since it's a side project.
But anyone interested?
Except that it doesn't / isn't. I think the only thing standard about the Driver's side OBDII port are its shape and the +12 and Ground pins. At least, the CAN-H / CAN-L pair (pins 6, 14) aren't doing any 500kbit CAN protocol stuff.
I just re-verified mine, hooking a CAN bus hat on a Raspberry Pi to the OBDII port, with a SyncUP Drive dongle (telematics + Wi-FI hotspot) attached via a "Y" cable. All I see are the dongle's requests for capabilities (7DF 02 01 00, and the extended version of the same), totally unanswered. No other traffic on the pins, specifically nothing from the car at all. This is with the key in and on (contactors engaged). After 5 minutes, the dongle thinks the car is off and goes into standby (so there's nothing else on the other pins that might keep it happy either).
I mean from a hardware and protocol point of view. There is no standard OBDII ECU in there that will respond to the PIDs for speed, fuel, etc, so normal OBDII software won't find anything.
But, there are a few TPMS tools out there that claim to be able to re-program the TPMS ECU in Teslas (including roadster) and they use standard OBDII hardware. K-line is a standard protocol (ok, two standard protocols). We'll still need to drive the software, but the hardware should be simple.
Interesting. Any pointers to those tools?
I tried my OBDWiz dongle (USB) on "Auto", and it failed all the different protocols to connect with the car. (Note, I have not been able to figure out what "connect" actually means on a protocol level.) Per the logs, it tried:
- J1850 PWM, 41.6k [no data]
- J1850 VPW, 10.4k [no data]
- 9141-2, 5 baud init, 10.4k [Bus init: ...error]
- 14230-4 KWP, 5 init, 10.4k [Bus init: ...error]
- 14230-4 KWP, fast init, 10.4k [Bus init: error]
- 15765-4 CAN, 11 bit 500k 01 00: [CAN Error]
- 15765-4 CAN, 29 bit 500k 01 00: [CAN Error]
- 15765-4 CAN, 11 bit 250k 01 00: [CAN Error]
- 15765-4 CAN, 29 bit 250k 01 00: [CAN Error]
- Auto 01 00 [Searching... unable to connect]
The 4 CAN attempts, for example, appear to simply be asking for what the car supports. "01 00" is pretty basic stuff, if I understand the protocol right, yet there were no replies.
What protocol / rate did it miss?
oh, p.s.: It did report 13.6 volts, so at least I've confirmed that part working
Similar threads
