Roadster 2.x TPMS Tool

[markwj]

A lot of good work has been done to decode the CAN, LIN and K-Line messages related to the 2.x Roadster TPMS system. We have a good understanding of how it works, and can manually manipulate things from the LIN and K-Line buses. In particular, we now know how to read and write tyre IDs from/to the TPMS ECU.

However, to make this useful we need to make a tool. Either something standalone, or an extension to OVMS. The protocol used by the TPMS system over K-line is not complex, but it is non-standard both in software (not based on ISO9141) and voltage (5V vs 12V).

I am very willing to help with this, but I quite simply don't have the car any more. If I did, I could probably knock up the solution in a weekend now. I know of a couple of roadsters in Hong Kong, but none have the TPMS option installed. There is one in China, but with the travel restrictions that won't be usable for the near future. All the other roadsters that I know of with TPMS are dead in the service centre waiting for new batteries.

I had hoped that my 2014 Tesla Model S would work as a test bed for this, but despite reports that the TPMS is the same, it is not. The tyre sensors maybe, but the ECU is certainly not.

I see two options:

1. We collectively obtain an ECU + 2xantennas + cables, and use that to work from on the bench. The electrics are well documented, so bringing such a system up on the bench should not be hard. We could probably even do without the cables. These would have to come from a salvage car, or spare parts bins. This could be crowd-funded, or handled on a loan basis.
   
   
2. Someone in USA / Europe takes on the hardware side of the project.

As the Tesla tool is no longer available, and the batteries in the tyre sensors die over time, this will become more of an issue for Tesla Roadster owners going forward.

Ideas / suggestions? @CM_007, @racevpr ?

P.S. My direct eMail is mark (at) openvehicles (dot) com, if anybody wants to suggest/offer off-list.

 

[Bunnak]

Thanks Mark for continually working to improve things for us roadster owners, even when you no longer own a roadster! I hope Carl and/or Pete can assist. I'm sure owners here will be willing to assist in anyway we can.

 

[drewski]

This parts car may have the parts needed? I'll chip in on costs
Parting Out Roadster Sport 945

 

[TOBASH]

I have newly installed your OVMS, I have the TPMS option in my car, and I can Skype with you to make things work. I am in New York City. I own a Roadster 2.5 base model with original TPMS sensors on my tires that are still functioning.

I can work with you on the hardware side if you explain what I need to do. I learn fast. I can spend hours and hours with you because of my office practice grinding almost to a halt during this period of "social distancing".

I would of course like the idea of working on the hardware as it seems like a great challenge. Just tell me what I need to purchase on my end. I also have several spare laptop computers if needed to act as an interface with the correct plugs and such. I can keep them in Windows or alternatively switch them to Ubuntu type LINUX if you prefer. I can also set up "TeamViewer" on the system to allow you access from Hong Kong.

Alternatively, I can chip in to help purchase the TPMS onboard sensor that is being parted out on Roadster 945, and chip in for shipping to you.

How can I help MarkJ?

 

[markwj]

I can work with you on the hardware side if you explain what I need to do. I learn fast. I can spend hours and hours with you because of my office practice grinding almost to a halt during this period of "social distancing". How can I help MarkJ?

Thanks for the offer.

For a possible OVMS solution, we made some changes last year. Recent production batches should include this:

1. We changed the cable design for our early Tesla cable. The new cable wires pin #3 at the 173851-2 (Tesla DIAG) end to pin #1 at the DB9-F (OVMS). That is the K-line single wire bus, and is in addition to the 3 CAN buses already wired. The cable is labelled OVT1 (in black-on-white lettering). That change brought K-line from the car into the OVMS module. You (or others who want to help) can verify that with a meter in continuity test mode, to make sure you have that latest cable.
   
   
2. We changed the OVMS v3 board design to connect DB9 pin #1 to GEP #7 (pin #10 of internal expansion connector, and pin #21 of DA26 external expansion connector). That change mapped the K-line signal onto a general expansion pin, so we could handle it either externally or on an internal expansion module. You (or others who want to help) can verify that with a meter in continuity test mode, to make sure the connection is on your version of module. If not, it is a very simple hack to add it (just solder a small bridge wire between DB9 pin#1 and either pin#10 of internal expansion connector or pin #21 of the DA26 external expansion connector.

Our idea is to make a small expansion board. That takes a couple of GPIOs from the ESP32 microprocessor as a UART port, then uses a K-line transceiver (MC33660) to connect to the K-line single wire bus on GEP #7 (and thence DB9 pin #1). I have a prototype for that, but it was based on 12V K-line signals (recent research suggests the K-line is 5V for the roadster 2.x TPMS ECU). Supposedly, the TPMS ECU talks 9600baud 5volt standard async, with a unique start and stop byte to differentiate it from other traffic on that bus. It doesn't talk the normal ISO9141 protocol at all. Credit for this research is due to Shawn Ashbaugh (who worked it out the hard way). We don't have 5V generally available in the internal expansion (only available when USB is plugged in), but we do have 12V and it is trivial to LM* that down to 5V.

I really have zero experience with K-line, and the wiring diagrams for slave vs master appear to be different. The circuit _should_ be simple, but all examples are based on 12V. In our case, we will be the master. This is one example:

But I've found a bunch of others.

We could also simply prototype this using a USB-to-serial adaptor, connected to a K-line transceiver circuit on a breadboard, off a laptop. It is ultimately just 9600baud async. My issue is that without the car (or TPMS ECU on the bench), I have no ability to test/iterate.

Anybody here with K-line experience?

 

[markwj]

With many thanks to the guys in Canada, we have a roadster TPMS ECU on loan.

From left to right:

• ECU opened up
• Breakout board (power, k, Lin, and can)
• OVMS for can decode
• Usb logic analyser
• Power supply (12v)
• USB K-line diagnostic tool (aka 9010)
• Windows laptop running k-line software
• Mac running logic analyser and terminal to OVMS

The TPMS ECU is pretty simple. A very old 8 bit microcontroller with:

1. A K-Line serial interface (data is 9600N81, 5v, simple asynchronous framing)
2. A single LIN bus (connecting the ECU to both the front and rear antenna modules)
3. A CAN bus connected to the instrumentation CAN (that OVMS also connects to)
4. An unpopulated serial interface (RS232 driver chip not installed)

Design seems pretty neat and well made. Lots of clearly labeled test points on the board. I can read and write tyre IDs now, over k-line, using the ow-level commercial tool. Also confirmed that the TPMS IDs used on the CAN bus (0x343, 0x344, and 0x345) - very clear to see what is going on when this is the only module on the bus.

Now working on the hardware interface board for OVMS to be able to talk to this. The idea is to provide a ‘tpms’ command within OVMS, that plugs into a driver in the vehicle module. That command will allow to store IDs in sets (e.g. ‘winter’, ‘summer’, etc), as well as read the current IDs recorded in the ECU and re-write a set of IDs back to the ECU. We can’t read the IDs from the wheels themselves, but that is something any tyre garage can do.

Onwards...

 

[Bunnak]

Thank you Mark for continuing to update our Roadsters!

 

[markwj]

Kludgy hand-built expansion board, but it works. Implementing this as a new vehicle independent 'tpms' subsystem within OVMS v3. This will allow sets of tyres to be maintained in the config and read/written to the car's TPMS ECU. This is for the v2.x Tesla Roadster TPMS.

• tpms status - show status of the system
• tpms list - list tyre id sets in config
• tpms read <set> - read IDs from tpms ecu and store in config tyre set
• tpms write <set> - write IDs to toms ecu from config tyre set
• tpms set <set> {<id>} - config a set of IDs manually
• tpms delete <set> - delete the specified tyre set

The expansion board provides an interface to the K-line bus in the car, used to talk to the TPMS ECU. That ECU, in turn, will talk to the antennas in the front and rear (via LIN bus). Picture below shows OVMS sending a 19 byte request to the ECU (0x0f 0x04 .... 0xf0) and the ECU responding 19 bytes (0x0f 0x05 ... 0xf0) with the 4 tyre IDs. There is a similar command to re-program the ECU with new IDs. The roadster TPMS ECU K-line is at 5v, but I am trying to make the expansion board as flexible as possible with jumpered options for (a) 5v from USB, (b) 5V regulated from the car's 12v supply, or (c) 12v direct from the car.

Once the firmware is done, and everything validated, we will be getting the guys in China to make this board up properly as an expansion option. You will need the latest cable (labelled OVT1 as "OVMS cable for Early Teslas"), and a fairly recent OVMS module with support for K-line (or make one very simple solder connection between the DB9 and DA26 pins). Anything within the last year or so should be fine.

Regards, Mark.

 

[JohnGarziglia]

Mark, this is great news! Thank you for your work on this.
-- John

 

[driver_EV]

I am interested in migrating/updating my OVMS when this is in production. It seems like most every Roadster in private hands will benefit from this long-term owner-empowering capability. TPMS has been such a challenge and frustration for many.

 

[markwj]

It seems like most every Roadster in private hands will benefit from this long-term owner-empowering capability. TPMS has been such a challenge and frustration for many.

I agree. The antenna corruption bug in particular has been frustrating. My roadster had three antennas replaced (under warranty) before it become stable. The functionality should also be useful for those with winter/summer tyre sets.

Getting very close to complete now. Hopefully one more weekend to finalise things then we can make some boards.

 

[Nvbob]

Looking forward to this! Thanks Mark and all who worked on this!

 

[markwj]

Had a good weekend hacking away at this. Short story is that it is done and dusted.

OVMS# tpms list

Tyre Sets:
  canada: 01010fd3,01010fdb,01010f8a,01011c14
  testing: a1a2a3a4,b1b2b3b4,c1c2c3c4,d1d2d3d4

OVMS# tpms read
TPMS read as a1a2a3a4,b1b2b3b4,c1c2c3c4,d1d2d3d4

OVMS# tpms write canada
Tyre set 'canada' written to vehicle TPMS successfully

OVMS# tpms read
TPMS read as 01010fd3,01010fdb,01010f8a,01011c14

Code is in the latest firmware ('edge' release), and board design has gone to manufacturing.

I also spent some time looking at the LIN bus (alongside the K-Line we use to program the ECU). It behaves pretty much as expected, as described by Scott in his good work on this, and is suitably non-standard (9600 baud, 12v logic levels, protocol 1.x). When programming (as seen from the TPMS ECU point of view) the sequence is (a) K-line request to write IDs arrives, (b) the IDs are written to the ECU, (c) the IDs are written to the antennas (over LIN bus), (d) IDs are read back over LIN to confirm, and (e) then the K-line response is sent. If you try to program the ECU without the antennas connected (or with a broken antenna), you get a nice error code back from the ECU (which tells you the ECU is programmed, but the antennas are not). in normal operation, the ECU polls each of the antennas for their IDs, pressures and temperatures.

I have a 140+ page document now describing this. I'll try to boil that down to something more manageable (leaving out the gory details) when this is released. Perhaps a month or so and boards should be available.

 

[Rotarypower]

Wow @markwj great work!

 

[markwj]

Production prototype:

 

[jfischer]

Absolutely OUTSTANDING WORK @markwj !

This is yet another reason for every roadster to have a OVMS installed.

I just installed a new OVMS 3.1 in my 2.5 (#1042) and am willing to test, purchase, etc anything required to help you further in this endeavor and help the group as well.

Just let me know what piggyback boards I need to purchase, updated cables to install and firmware to use and I'll be glad to be a tester.

 

[markwj]

Absolutely OUTSTANDING WORK @markwj !

This is yet another reason for every roadster to have a OVMS installed.

I just installed a new OVMS 3.1 in my 2.5 (#1042) and am willing to test, purchase, etc anything required to help you further in this endeavor and help the group as well.

Just let me know what piggyback boards I need to purchase, updated cables to install and firmware to use and I'll be glad to be a tester.

Thanks for your kind words. Testing of this is done, and it works fine in real cars. Will start production of the first batch today. Should be available within this month. The component parts for this are cheap, but R&D cost has been crazy expensive, for low volume. So, most likely this will be donation based (to try to recoup R&D costs). More details when the kits are available.

Regards, Mark.

 

[jfischer]

Thanks for your kind words. Testing of this is done, and it works fine in real cars. Will start production of the first batch today. Should be available within this month. The component parts for this are cheap, but R&D cost has been crazy expensive, for low volume. So, most likely this will be donation based (to try to recoup R&D costs). More details when the kits are available.

Regards, Mark.

Count me in for one of the boards and whatever you want for a "donation"

 

[Nvbob]

Count us in & also let us know what the "donation" will be.

 

[drewski]

what ^^^these^^^ guys said!