I’ve been spending the last month or so hacking away at TPMS. This has been an ongoing project for the Tesla Roadster that is finally coming to fruition. About a year or so ago, we already made changes to: Modify the Tesla Roadster cable to connect the k-line pin on the diagnostic connector through to the DB9 connector on OVMS. We labelled this cable ‘OVT1’. Modify the OVMS module to connect that k-line pin to GEP7. I’m now working on an optional expansion board that will include a little TJA1027T transceiver and map it to EXP1 and EXP2 (for async comms) and EGPIO8 (for enable/disable) on the ESP32 and MAX. This board will include a jumpered option for K-line master (one diode + one resistor), as well as jumpered powered selection (5v from usb, 5v regulated from car 12v, or direct car 12v) for the K-line bus. The hand-soldered prototype, using our breakout boards, works well and the K-line async comms works. The screenshot 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. On the firmware side, I am implementing a new vehicle independent ’tpms’ subsystem within OVMS (enabled via configureable option). This will allow sets of tyres to be maintained in the config and read/written to the car's TPMS ECU. The following commands will be available: 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 initial version will support Tesla Roadster, but the functionality is there for other vehicles to use if they need it (in particular for standard K-line implementations). Comments/suggestions welcome. Regards, Mark. +++Attachments+++ Bench setup, showing (from left to right): Tesla Roadster TPMS ECU opened up Breakout board (power, k, Lin, and can) OVMS for can decode Usb logic analyser Power supply (12v) K-line analysis tool (9010) Windows laptop running k-line software Mac running logic analyser and terminal to OVMS. Hand-soldered prototyping board Async comms over k-line.
Oh! - This is great! I could really use an easy way to switch between summer and winter wheels without traveling to the Tesla dealership to wait in line for one of their techs to use their tool. If you need any help testing, I will buy any boards needed (or make my own prototype, if that makes sense). I have one Tesla Roadster 2.5 and eight wheels that should have working TPMS sensors. We also have PCB fab and assembly shops that are still working here, so I might even be able to make boards locally. I’ll have to check which version of OVMS that I have. I bought a few versions of them, but I may not have the latest version. Brian p.s. I haven’t been following this list for a while. In fact, my email server went down after fourteen years of constant service, so I think I got kicked off the list and had to rejoin. So, I’m very glad to see this feature being worked on. I may need to reconnect, upgrade to the latest firmware releases, and all of that. On May 10, 2020, at 5:56 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I’ve been spending the last month or so hacking away at TPMS. This has been an ongoing project for the Tesla Roadster that is finally coming to fruition.
About a year or so ago, we already made changes to:
• Modify the Tesla Roadster cable to connect the k-line pin on the diagnostic connector through to the DB9 connector on OVMS. We labelled this cable ‘OVT1’. • Modify the OVMS module to connect that k-line pin to GEP7.
I’m now working on an optional expansion board that will include a little TJA1027T transceiver and map it to EXP1 and EXP2 (for async comms) and EGPIO8 (for enable/disable) on the ESP32 and MAX. This board will include a jumpered option for K-line master (one diode + one resistor), as well as jumpered powered selection (5v from usb, 5v regulated from car 12v, or direct car 12v) for the K-line bus.
The hand-soldered prototype, using our breakout boards, works well and the K-line async comms works. The screenshot 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.
On the firmware side, I am implementing a new vehicle independent ’tpms’ subsystem within OVMS (enabled via configureable option). This will allow sets of tyres to be maintained in the config and read/written to the car's TPMS ECU. The following commands will be available:
• 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 initial version will support Tesla Roadster, but the functionality is there for other vehicles to use if they need it (in particular for standard K-line implementations).
Comments/suggestions welcome.
Regards, Mark.
So long as it is a v3.1 or v3.2 module it should be fine. The older ones will need one wire between the DB9 and DA26 connector, which is trivial to add. You will need an OVT1 cable (if you don’t already have one). I’m hoping to be able to nail this down this coming weekend. Regards, Mark.
On 14 May 2020, at 3:23 PM, HONDA S-2000 <s2000@audiobanshee.com> wrote:
Oh! - This is great!
I could really use an easy way to switch between summer and winter wheels without traveling to the Tesla dealership to wait in line for one of their techs to use their tool.
If you need any help testing, I will buy any boards needed (or make my own prototype, if that makes sense). I have one Tesla Roadster 2.5 and eight wheels that should have working TPMS sensors. We also have PCB fab and assembly shops that are still working here, so I might even be able to make boards locally.
I’ll have to check which version of OVMS that I have. I bought a few versions of them, but I may not have the latest version.
Brian
p.s. I haven’t been following this list for a while. In fact, my email server went down after fourteen years of constant service, so I think I got kicked off the list and had to rejoin. So, I’m very glad to see this feature being worked on. I may need to reconnect, upgrade to the latest firmware releases, and all of that.
On May 10, 2020, at 5:56 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I’ve been spending the last month or so hacking away at TPMS. This has been an ongoing project for the Tesla Roadster that is finally coming to fruition.
About a year or so ago, we already made changes to:
• Modify the Tesla Roadster cable to connect the k-line pin on the diagnostic connector through to the DB9 connector on OVMS. We labelled this cable ‘OVT1’. • Modify the OVMS module to connect that k-line pin to GEP7.
I’m now working on an optional expansion board that will include a little TJA1027T transceiver and map it to EXP1 and EXP2 (for async comms) and EGPIO8 (for enable/disable) on the ESP32 and MAX. This board will include a jumpered option for K-line master (one diode + one resistor), as well as jumpered powered selection (5v from usb, 5v regulated from car 12v, or direct car 12v) for the K-line bus.
The hand-soldered prototype, using our breakout boards, works well and the K-line async comms works. The screenshot 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.
On the firmware side, I am implementing a new vehicle independent ’tpms’ subsystem within OVMS (enabled via configureable option). This will allow sets of tyres to be maintained in the config and read/written to the car's TPMS ECU. The following commands will be available:
• 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 initial version will support Tesla Roadster, but the functionality is there for other vehicles to use if they need it (in particular for standard K-line implementations).
Comments/suggestions welcome.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Short story:
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 committed, and in edge release now. Now to start building production K-line expansion boards (to replace my hand-built breadboard kludge). Regards, Mark
On 14 May 2020, at 4:36 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
So long as it is a v3.1 or v3.2 module it should be fine. The older ones will need one wire between the DB9 and DA26 connector, which is trivial to add. You will need an OVT1 cable (if you don’t already have one).
I’m hoping to be able to nail this down this coming weekend.
Regards, Mark.
On 14 May 2020, at 3:23 PM, HONDA S-2000 <s2000@audiobanshee.com> wrote:
Oh! - This is great!
I could really use an easy way to switch between summer and winter wheels without traveling to the Tesla dealership to wait in line for one of their techs to use their tool.
If you need any help testing, I will buy any boards needed (or make my own prototype, if that makes sense). I have one Tesla Roadster 2.5 and eight wheels that should have working TPMS sensors. We also have PCB fab and assembly shops that are still working here, so I might even be able to make boards locally.
I’ll have to check which version of OVMS that I have. I bought a few versions of them, but I may not have the latest version.
Brian
p.s. I haven’t been following this list for a while. In fact, my email server went down after fourteen years of constant service, so I think I got kicked off the list and had to rejoin. So, I’m very glad to see this feature being worked on. I may need to reconnect, upgrade to the latest firmware releases, and all of that.
On May 10, 2020, at 5:56 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: I’ve been spending the last month or so hacking away at TPMS. This has been an ongoing project for the Tesla Roadster that is finally coming to fruition.
About a year or so ago, we already made changes to:
• Modify the Tesla Roadster cable to connect the k-line pin on the diagnostic connector through to the DB9 connector on OVMS. We labelled this cable ‘OVT1’. • Modify the OVMS module to connect that k-line pin to GEP7.
I’m now working on an optional expansion board that will include a little TJA1027T transceiver and map it to EXP1 and EXP2 (for async comms) and EGPIO8 (for enable/disable) on the ESP32 and MAX. This board will include a jumpered option for K-line master (one diode + one resistor), as well as jumpered powered selection (5v from usb, 5v regulated from car 12v, or direct car 12v) for the K-line bus.
The hand-soldered prototype, using our breakout boards, works well and the K-line async comms works. The screenshot 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.
On the firmware side, I am implementing a new vehicle independent ’tpms’ subsystem within OVMS (enabled via configureable option). This will allow sets of tyres to be maintained in the config and read/written to the car's TPMS ECU. The following commands will be available:
• 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 initial version will support Tesla Roadster, but the functionality is there for other vehicles to use if they need it (in particular for standard K-line implementations).
Comments/suggestions welcome.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Just received the prototype production boards from China. Some comments: S1 is a on/off switch used to wire in a diode+resistor to the K-line. It is needed for ‘k-line master’ in some cars. SW1 is a four position switch used to select the power for the K-line bus. It can be one of: 0 = No connection (or a manually added voltage from the test point) 1 = USB5V: Useful for desktop testing from USB (with no 12V connected) - 5v from the USB connector 2 = LDO5V: 5v from by regulating vehicle 12v power 3 = 12V: 12v from vehicle power Board can either go on top of the modem, or underneath it. We have tried to make this as general purpose as possible. Will test for the next 24 to 48 hours, and then give the go-ahead for production. Regards, Mark.
On 17 May 2020, at 5:44 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Short story:
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 committed, and in edge release now.
Now to start building production K-line expansion boards (to replace my hand-built breadboard kludge).
Regards, Mark
On 14 May 2020, at 4:36 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
So long as it is a v3.1 or v3.2 module it should be fine. The older ones will need one wire between the DB9 and DA26 connector, which is trivial to add. You will need an OVT1 cable (if you don’t already have one).
I’m hoping to be able to nail this down this coming weekend.
Regards, Mark.
On 14 May 2020, at 3:23 PM, HONDA S-2000 <s2000@audiobanshee.com> wrote:
Oh! - This is great!
I could really use an easy way to switch between summer and winter wheels without traveling to the Tesla dealership to wait in line for one of their techs to use their tool.
If you need any help testing, I will buy any boards needed (or make my own prototype, if that makes sense). I have one Tesla Roadster 2.5 and eight wheels that should have working TPMS sensors. We also have PCB fab and assembly shops that are still working here, so I might even be able to make boards locally.
I’ll have to check which version of OVMS that I have. I bought a few versions of them, but I may not have the latest version.
Brian
p.s. I haven’t been following this list for a while. In fact, my email server went down after fourteen years of constant service, so I think I got kicked off the list and had to rejoin. So, I’m very glad to see this feature being worked on. I may need to reconnect, upgrade to the latest firmware releases, and all of that.
On May 10, 2020, at 5:56 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I’ve been spending the last month or so hacking away at TPMS. This has been an ongoing project for the Tesla Roadster that is finally coming to fruition.
About a year or so ago, we already made changes to:
• Modify the Tesla Roadster cable to connect the k-line pin on the diagnostic connector through to the DB9 connector on OVMS. We labelled this cable ‘OVT1’. • Modify the OVMS module to connect that k-line pin to GEP7.
I’m now working on an optional expansion board that will include a little TJA1027T transceiver and map it to EXP1 and EXP2 (for async comms) and EGPIO8 (for enable/disable) on the ESP32 and MAX. This board will include a jumpered option for K-line master (one diode + one resistor), as well as jumpered powered selection (5v from usb, 5v regulated from car 12v, or direct car 12v) for the K-line bus.
The hand-soldered prototype, using our breakout boards, works well and the K-line async comms works. The screenshot 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.
On the firmware side, I am implementing a new vehicle independent ’tpms’ subsystem within OVMS (enabled via configureable option). This will allow sets of tyres to be maintained in the config and read/written to the car's TPMS ECU. The following commands will be available:
• 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 initial version will support Tesla Roadster, but the functionality is there for other vehicles to use if they need it (in particular for standard K-line implementations).
Comments/suggestions welcome.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I just received all of the pieces necessary for TPMS on the Tesla Roadster 2.5 and assembled them today. Looks like the K-line board can't go underneath the modem because the sockets are soldered in. I may be out of touch, though. I have a couple of older revisions of the OVMS, but haven't built or installed the firmware in years. I'll have to find some time this weekend to put it all together and re-learn a few things. Thanks for designing and developing this. Brian Willoughby On May 25, 2020, at 7:24 PM, Mark Webb-Johnson wrote:
Just received the prototype production boards from China. Some comments:
• S1 is a on/off switch used to wire in a diode+resistor to the K-line. It is needed for ‘k-line master’ in some cars.
• SW1 is a four position switch used to select the power for the K-line bus. It can be one of: • 0 = No connection (or a manually added voltage from the test point) • 1 = USB5V: Useful for desktop testing from USB (with no 12V connected) - 5v from the USB connector • 2 = LDO5V: 5v from by regulating vehicle 12v power • 3 = 12V: 12v from vehicle power
• Board can either go on top of the modem, or underneath it.
We have tried to make this as general purpose as possible. Will test for the next 24 to 48 hours, and then give the go-ahead for production.
Regards, Mark.
On 17 May 2020, at 5:44 PM, Mark Webb-Johnson wrote:
Short story:
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 committed, and in edge release now.
Now to start building production K-line expansion boards (to replace my hand-built breadboard kludge).
Regards, Mark
On 14 May 2020, at 4:36 PM, Mark Webb-Johnson wrote:
So long as it is a v3.1 or v3.2 module it should be fine. The older ones will need one wire between the DB9 and DA26 connector, which is trivial to add. You will need an OVT1 cable (if you don’t already have one).
I’m hoping to be able to nail this down this coming weekend.
Regards, Mark.
On 14 May 2020, at 3:23 PM, HONDA S-2000 wrote:
Oh! - This is great!
I could really use an easy way to switch between summer and winter wheels without traveling to the Tesla dealership to wait in line for one of their techs to use their tool.
If you need any help testing, I will buy any boards needed (or make my own prototype, if that makes sense). I have one Tesla Roadster 2.5 and eight wheels that should have working TPMS sensors. We also have PCB fab and assembly shops that are still working here, so I might even be able to make boards locally.
I’ll have to check which version of OVMS that I have. I bought a few versions of them, but I may not have the latest version.
Brian
p.s. I haven’t been following this list for a while. In fact, my email server went down after fourteen years of constant service, so I think I got kicked off the list and had to rejoin. So, I’m very glad to see this feature being worked on. I may need to reconnect, upgrade to the latest firmware releases, and all of that.
On May 10, 2020, at 5:56 PM, Mark Webb-Johnson wrote:
I’ve been spending the last month or so hacking away at TPMS. This has been an ongoing project for the Tesla Roadster that is finally coming to fruition.
About a year or so ago, we already made changes to:
• Modify the Tesla Roadster cable to connect the k-line pin on the diagnostic connector through to the DB9 connector on OVMS. We labelled this cable ‘OVT1’. • Modify the OVMS module to connect that k-line pin to GEP7.
I’m now working on an optional expansion board that will include a little TJA1027T transceiver and map it to EXP1 and EXP2 (for async comms) and EGPIO8 (for enable/disable) on the ESP32 and MAX. This board will include a jumpered option for K-line master (one diode + one resistor), as well as jumpered powered selection (5v from usb, 5v regulated from car 12v, or direct car 12v) for the K-line bus.
The hand-soldered prototype, using our breakout boards, works well and the K-line async comms works. The screenshot 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.
On the firmware side, I am implementing a new vehicle independent ’tpms’ subsystem within OVMS (enabled via configureable option). This will allow sets of tyres to be maintained in the config and read/written to the car's TPMS ECU. The following commands will be available:
• 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 initial version will support Tesla Roadster, but the functionality is there for other vehicles to use if they need it (in particular for standard K-line implementations).
Comments/suggestions welcome.
Regards, Mark.
Brian, The K-line board is designed to sit on top of the modem (because of the orientation of pins). Mounting spacers for this are provided in the kit. For users without a modem, a pair of SIP pins is provided (as well as spacers) for mounting raised above the main board. Regards, Mark.
On 25 Aug 2020, at 1:23 PM, HONDA S-2000 <s2000@audiobanshee.com> wrote:
I just received all of the pieces necessary for TPMS on the Tesla Roadster 2.5 and assembled them today.
Looks like the K-line board can't go underneath the modem because the sockets are soldered in. I may be out of touch, though.
I have a couple of older revisions of the OVMS, but haven't built or installed the firmware in years. I'll have to find some time this weekend to put it all together and re-learn a few things.
Thanks for designing and developing this.
Brian Willoughby
On May 25, 2020, at 7:24 PM, Mark Webb-Johnson wrote:
Just received the prototype production boards from China. Some comments:
• S1 is a on/off switch used to wire in a diode+resistor to the K-line. It is needed for ‘k-line master’ in some cars.
• SW1 is a four position switch used to select the power for the K-line bus. It can be one of: • 0 = No connection (or a manually added voltage from the test point) • 1 = USB5V: Useful for desktop testing from USB (with no 12V connected) - 5v from the USB connector • 2 = LDO5V: 5v from by regulating vehicle 12v power • 3 = 12V: 12v from vehicle power
• Board can either go on top of the modem, or underneath it.
We have tried to make this as general purpose as possible. Will test for the next 24 to 48 hours, and then give the go-ahead for production.
Regards, Mark.
On 17 May 2020, at 5:44 PM, Mark Webb-Johnson wrote:
Short story:
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 committed, and in edge release now.
Now to start building production K-line expansion boards (to replace my hand-built breadboard kludge).
Regards, Mark
On 14 May 2020, at 4:36 PM, Mark Webb-Johnson wrote:
So long as it is a v3.1 or v3.2 module it should be fine. The older ones will need one wire between the DB9 and DA26 connector, which is trivial to add. You will need an OVT1 cable (if you don’t already have one).
I’m hoping to be able to nail this down this coming weekend.
Regards, Mark.
On 14 May 2020, at 3:23 PM, HONDA S-2000 wrote:
Oh! - This is great!
I could really use an easy way to switch between summer and winter wheels without traveling to the Tesla dealership to wait in line for one of their techs to use their tool.
If you need any help testing, I will buy any boards needed (or make my own prototype, if that makes sense). I have one Tesla Roadster 2.5 and eight wheels that should have working TPMS sensors. We also have PCB fab and assembly shops that are still working here, so I might even be able to make boards locally.
I’ll have to check which version of OVMS that I have. I bought a few versions of them, but I may not have the latest version.
Brian
p.s. I haven’t been following this list for a while. In fact, my email server went down after fourteen years of constant service, so I think I got kicked off the list and had to rejoin. So, I’m very glad to see this feature being worked on. I may need to reconnect, upgrade to the latest firmware releases, and all of that.
On May 10, 2020, at 5:56 PM, Mark Webb-Johnson wrote:
I’ve been spending the last month or so hacking away at TPMS. This has been an ongoing project for the Tesla Roadster that is finally coming to fruition.
About a year or so ago, we already made changes to:
• Modify the Tesla Roadster cable to connect the k-line pin on the diagnostic connector through to the DB9 connector on OVMS. We labelled this cable ‘OVT1’. • Modify the OVMS module to connect that k-line pin to GEP7.
I’m now working on an optional expansion board that will include a little TJA1027T transceiver and map it to EXP1 and EXP2 (for async comms) and EGPIO8 (for enable/disable) on the ESP32 and MAX. This board will include a jumpered option for K-line master (one diode + one resistor), as well as jumpered powered selection (5v from usb, 5v regulated from car 12v, or direct car 12v) for the K-line bus.
The hand-soldered prototype, using our breakout boards, works well and the K-line async comms works. The screenshot 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.
On the firmware side, I am implementing a new vehicle independent ’tpms’ subsystem within OVMS (enabled via configureable option). This will allow sets of tyres to be maintained in the config and read/written to the car's TPMS ECU. The following commands will be available:
• 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 initial version will support Tesla Roadster, but the functionality is there for other vehicles to use if they need it (in particular for standard K-line implementations).
Comments/suggestions welcome.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Very nice. I wonder can this be optimized to support other metrics? Like using GPS coordinates from CAN instead of the GPS module itself for cars that have it available? Regards, Jaunius Kapkan [Sent from cellphone]
On 2020-05-11, at 03:57, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I’ve been spending the last month or so hacking away at TPMS. This has been an ongoing project for the Tesla Roadster that is finally coming to fruition.
About a year or so ago, we already made changes to:
Modify the Tesla Roadster cable to connect the k-line pin on the diagnostic connector through to the DB9 connector on OVMS. We labelled this cable ‘OVT1’. Modify the OVMS module to connect that k-line pin to GEP7.
I’m now working on an optional expansion board that will include a little TJA1027T transceiver and map it to EXP1 and EXP2 (for async comms) and EGPIO8 (for enable/disable) on the ESP32 and MAX. This board will include a jumpered option for K-line master (one diode + one resistor), as well as jumpered powered selection (5v from usb, 5v regulated from car 12v, or direct car 12v) for the K-line bus.
The hand-soldered prototype, using our breakout boards, works well and the K-line async comms works. The screenshot 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.
On the firmware side, I am implementing a new vehicle independent ’tpms’ subsystem within OVMS (enabled via configureable option). This will allow sets of tyres to be maintained in the config and read/written to the car's TPMS ECU. The following commands will be available:
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 initial version will support Tesla Roadster, but the functionality is there for other vehicles to use if they need it (in particular for standard K-line implementations).
Comments/suggestions welcome.
Regards, Mark.
+++Attachments+++
Bench setup, showing (from left to right): Tesla Roadster TPMS ECU opened up Breakout board (power, k, Lin, and can) OVMS for can decode Usb logic analyser Power supply (12v) K-line analysis tool (9010) Windows laptop running k-line software Mac running logic analyser and terminal to OVMS.
<image0.jpeg>
Hand-soldered prototyping board
<image0.jpeg>
Async comms over k-line.
<image1.jpeg>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Jaunius, The board will look like this (pcb layout for the first few samples): I’ve tried to make it as generic as possible. SW1 is a four position switch #0 - no connection (with test point that can inject custom voltage if required) #1 - USB 5v. Bus is powered with 5v from the USB (useful for bench testing) #2 - LDO 5v. Bus is powered with 5v using a LDO to regulate down vehicle 12v power #3 - 12v. Bus is powered from vehicle 12v S1 is a on/off switch. When on, it adds a diode+resistor to the K-Line (which is required by some cars for K-line tools being master). Test points everywhere, to help debugging For roadster, SW1 is #2 and S1 is off. It is exposed to the ESP32 as an async port, at 3.3v levels. But the transceiver handles the bus at 5v or 12v. It works with K-line, and should also work with LIN, if required. EGPIO8 is used to enabled/disable the transceiver (normally disabled). Regards, Mark. P.S. Circuit schematic attached.
On 18 May 2020, at 9:14 PM, Jaunius Kapkan <jaunius@gmx.com> wrote:
Very nice.
I wonder can this be optimized to support other metrics? Like using GPS coordinates from CAN instead of the GPS module itself for cars that have it available?
Regards, Jaunius Kapkan [Sent from cellphone]
On 2020-05-11, at 03:57, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I’ve been spending the last month or so hacking away at TPMS. This has been an ongoing project for the Tesla Roadster that is finally coming to fruition.
About a year or so ago, we already made changes to:
Modify the Tesla Roadster cable to connect the k-line pin on the diagnostic connector through to the DB9 connector on OVMS. We labelled this cable ‘OVT1’. Modify the OVMS module to connect that k-line pin to GEP7.
I’m now working on an optional expansion board that will include a little TJA1027T transceiver and map it to EXP1 and EXP2 (for async comms) and EGPIO8 (for enable/disable) on the ESP32 and MAX. This board will include a jumpered option for K-line master (one diode + one resistor), as well as jumpered powered selection (5v from usb, 5v regulated from car 12v, or direct car 12v) for the K-line bus.
The hand-soldered prototype, using our breakout boards, works well and the K-line async comms works. The screenshot 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.
On the firmware side, I am implementing a new vehicle independent ’tpms’ subsystem within OVMS (enabled via configureable option). This will allow sets of tyres to be maintained in the config and read/written to the car's TPMS ECU. The following commands will be available:
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 initial version will support Tesla Roadster, but the functionality is there for other vehicles to use if they need it (in particular for standard K-line implementations).
Comments/suggestions welcome.
Regards, Mark.
+++Attachments+++
Bench setup, showing (from left to right): Tesla Roadster TPMS ECU opened up Breakout board (power, k, Lin, and can) OVMS for can decode Usb logic analyser Power supply (12v) K-line analysis tool (9010) Windows laptop running k-line software Mac running logic analyser and terminal to OVMS.
<image0.jpeg>
Hand-soldered prototyping board
<image0.jpeg>
Async comms over k-line.
<image1.jpeg>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (4)
-
Greg D. -
HONDA S-2000 -
Jaunius Kapkan -
Mark Webb-Johnson