Hello, this is a topic about disabling TPMS or producing a fake signal to fake "always good" TPMS info on CANBUS.
This is not a topic about US legal implications or legal implications in the other areas where TPMS is required by law, so please don't sidetrack this with that. At least Finland, Canada and Sweden are confirmed as countries without TPMS requirements.
There are also other topics for discussing replacing TPMS sensors and/or topics about upgrading the system from Baolong to Continental, so please don't sidetrack with that either.
I'm creating this new thread since the other topics on this subject were long ago in the Roadster forums and they're pretty much buried and/or sidetracked. Apparently, the 2008-2012 Roadster does use the exact same Baolong system, though. The location of the module is different though.
I have a late 2013 Model S with the Baolong system, and since TPMS is not a legal requirement in Finland, TPMS is just purely a continuous source of unnecessary problems. Therefore, I'd rather have it deleted from my car. Tesla however won't co-operate regarding such service requests, and I don't want to invest in the Continental system either, because it'd just be another money pit, gets pretty expensive with all 8 required TPMS sensors and tire work for 8 wheels (we are required to have a set of winter and summer tires and to use them in the corresponding seasons).
So, according to my research notes on this forum, the Baolong box uses something called LIN for communicating with the front and back antenna computer modules (they work on a 3-wire principle of proprietary serial over a single wire, and +12V and GND). This could just be some dumb 9600N1 serial data indicated by the fourth unused wire which is apparently unused in this application.
The data they send to the Baolong box resembles raw TPMS sensor data, including unique sensor IDs, and of course pressure and temperature. Faking this would mean leaving the ageing Baolong box itself in the car, which isn't desirable. It's also more complex to fake than the CANBUS signal the Baolong box sends forward.
This is the pin-out of the relevant pins of the Baolong box itself:
So, the relevant pins of the Baolong box are the pins 15 and 31, they'll need to be disconnected and the replacement box needs to produce a similar signal on CANBUS. The ODB-II wires and antennas can be ignored, either spend the effort to remove them completely, cut them or whatever. Regardless, we can't have the original box producing conflicting CAN signals.
So, this brings us to my notes on the CAN protocol:
The signalling is at a 1 MHz rate and the update interval is roughly one second. The Baolong box writes data to addresses 0x343, 0x344 and 0x345, all three of them in subsequent order. It's unclear how much the rest of the Tesla software cares about these values. At least they seem to ignore the tire pressure and tire temperature altogether unlike the Continental upgrade present on all Teslas from mid-September 2014 onward.
I'm using the convention of describing each CAN address as 64 bits arranged in 8 bytes named B1, B2, B3, B4, B5, B6, B7 and B8 from the most significant (or leftmost) byte onward. Each value is presented as hexadecimal unless indicated otherwise.
The order of wheels in the data (left to right) seems to be: front left, front right, rear left, and rear right.
On address 0x343, the important bytes are:
- B8, where the highest 4 bits (high nibble) are each wheel's "OK" status in order. 1=ok, 0=error. Therefore, 0xf0 (0b11110000) means every wheel's senor is ok and present.
- B7, which seems to always be 0x20.
- B6, which is 0x01, when no sensors are detected, 0x02 when some sensors are detected and 0x0a when all sensors are detected.
- B3, which is 0x04, when all sensors are detected and 0x00, when no sensors are detected.
- The rest of the bytes are always 0x00.
At address 0x344, we have pressure and temperature, each as a byte for each wheel. Therefore two bytes per wheel and eight bytes total. The pressure value seems to be 45 PSI * 2.755 (45 PSI is 3.1). Therefore, the ideal value would be 0x7C. Temperature seems to be reported in °C but offset by 40, which means the value 0x00 is -40°C and 0x28 would be 0°C and 0x3c would be 20°C. Therefore the value of 0x3c would be regarded as ideal.
Lastly, we have 0x345, where all the bytes are 0x00 when there's an error and B2 is 0x22 when everything is ok. It's possible the Tesla MCU only reads this value, ignoring everything else, but verifying this might need experimentation. At least their primitive level of "error" vs "no error" in the MCU notifications would indicate something of this sort. Otherwise, they'd have built a similar UI to the Continental system to support Baolong-equipped cars.
Therefore, we have this ideal CAN package table to send at 1Hz intervals to CANBUS:
That's likely all there is to it in theory. Now, for the practice, I haven't even found where the Baolong box is located, except Tesla's upgrade instructions say it's under the third wind deflector, apparently meaning the bottom shield plate at the rear of the car.
I have also never written any CANBUS code and never connected any device on CANBUS. However, I understand its principles, I'm familiar with software development including embedded code, and I have CAN-capable microcontroller development boards including STM32 Bluepill and STM32 Nucleo boards. I'll need to buy some CAN transceiver chips however to have a working circuit. I have plenty of tools including oscilloscopes, power supplies and very good soldering equipment among other things.
Therefore, please help me with achieving this first-level goal if you can, and let's make this an open source project. It could expand into something that helps people who have to keep their TPMS system in place, helping them troubleshoot what's wrong by for instance producing an auxiliary display to read from CAN the status, temperature and pressure of each wheel detected and to indicate which of the error bytes have a non-OK value. This information would be trivial to fit on an HD44780 LCD. However, reading this information is already possible on OMVS and their fancy $100 box and mobile application.
This is not a topic about US legal implications or legal implications in the other areas where TPMS is required by law, so please don't sidetrack this with that. At least Finland, Canada and Sweden are confirmed as countries without TPMS requirements.
There are also other topics for discussing replacing TPMS sensors and/or topics about upgrading the system from Baolong to Continental, so please don't sidetrack with that either.
I'm creating this new thread since the other topics on this subject were long ago in the Roadster forums and they're pretty much buried and/or sidetracked. Apparently, the 2008-2012 Roadster does use the exact same Baolong system, though. The location of the module is different though.
I have a late 2013 Model S with the Baolong system, and since TPMS is not a legal requirement in Finland, TPMS is just purely a continuous source of unnecessary problems. Therefore, I'd rather have it deleted from my car. Tesla however won't co-operate regarding such service requests, and I don't want to invest in the Continental system either, because it'd just be another money pit, gets pretty expensive with all 8 required TPMS sensors and tire work for 8 wheels (we are required to have a set of winter and summer tires and to use them in the corresponding seasons).
So, according to my research notes on this forum, the Baolong box uses something called LIN for communicating with the front and back antenna computer modules (they work on a 3-wire principle of proprietary serial over a single wire, and +12V and GND). This could just be some dumb 9600N1 serial data indicated by the fourth unused wire which is apparently unused in this application.
The data they send to the Baolong box resembles raw TPMS sensor data, including unique sensor IDs, and of course pressure and temperature. Faking this would mean leaving the ageing Baolong box itself in the car, which isn't desirable. It's also more complex to fake than the CANBUS signal the Baolong box sends forward.
This is the pin-out of the relevant pins of the Baolong box itself:
1: GND
2: +12V ("ignition" power)
15: CAN Hi
31: CAN Lo
5: K-Line (to the OBD-II connector)
20: RS-232 Rx (to the OBD-II connector)
21: RS-232 Tx (to the OBD-II connector)
17: Front antenna +12V
22: Front antenna GND
18: Front antenna LIN (serial)
16: Rear antenna +12V
14: Rear antenna GND
30: Rear antenna LIN (serial)So, the relevant pins of the Baolong box are the pins 15 and 31, they'll need to be disconnected and the replacement box needs to produce a similar signal on CANBUS. The ODB-II wires and antennas can be ignored, either spend the effort to remove them completely, cut them or whatever. Regardless, we can't have the original box producing conflicting CAN signals.
So, this brings us to my notes on the CAN protocol:
The signalling is at a 1 MHz rate and the update interval is roughly one second. The Baolong box writes data to addresses 0x343, 0x344 and 0x345, all three of them in subsequent order. It's unclear how much the rest of the Tesla software cares about these values. At least they seem to ignore the tire pressure and tire temperature altogether unlike the Continental upgrade present on all Teslas from mid-September 2014 onward.
I'm using the convention of describing each CAN address as 64 bits arranged in 8 bytes named B1, B2, B3, B4, B5, B6, B7 and B8 from the most significant (or leftmost) byte onward. Each value is presented as hexadecimal unless indicated otherwise.
The order of wheels in the data (left to right) seems to be: front left, front right, rear left, and rear right.
On address 0x343, the important bytes are:
- B8, where the highest 4 bits (high nibble) are each wheel's "OK" status in order. 1=ok, 0=error. Therefore, 0xf0 (0b11110000) means every wheel's senor is ok and present.
- B7, which seems to always be 0x20.
- B6, which is 0x01, when no sensors are detected, 0x02 when some sensors are detected and 0x0a when all sensors are detected.
- B3, which is 0x04, when all sensors are detected and 0x00, when no sensors are detected.
- The rest of the bytes are always 0x00.
At address 0x344, we have pressure and temperature, each as a byte for each wheel. Therefore two bytes per wheel and eight bytes total. The pressure value seems to be 45 PSI * 2.755 (45 PSI is 3.1). Therefore, the ideal value would be 0x7C. Temperature seems to be reported in °C but offset by 40, which means the value 0x00 is -40°C and 0x28 would be 0°C and 0x3c would be 20°C. Therefore the value of 0x3c would be regarded as ideal.
Lastly, we have 0x345, where all the bytes are 0x00 when there's an error and B2 is 0x22 when everything is ok. It's possible the Tesla MCU only reads this value, ignoring everything else, but verifying this might need experimentation. At least their primitive level of "error" vs "no error" in the MCU notifications would indicate something of this sort. Otherwise, they'd have built a similar UI to the Continental system to support Baolong-equipped cars.
Therefore, we have this ideal CAN package table to send at 1Hz intervals to CANBUS:
Address B1 B2 B3 B4 B5 B6 B7 B8
0x343 00 00 04 00 00 0A 20 F0
0x344 7C 3C 7C 3C 7C 3C 7C 3C
0x345 00 22 00 00 00 00 00 00That's likely all there is to it in theory. Now, for the practice, I haven't even found where the Baolong box is located, except Tesla's upgrade instructions say it's under the third wind deflector, apparently meaning the bottom shield plate at the rear of the car.
I have also never written any CANBUS code and never connected any device on CANBUS. However, I understand its principles, I'm familiar with software development including embedded code, and I have CAN-capable microcontroller development boards including STM32 Bluepill and STM32 Nucleo boards. I'll need to buy some CAN transceiver chips however to have a working circuit. I have plenty of tools including oscilloscopes, power supplies and very good soldering equipment among other things.
Therefore, please help me with achieving this first-level goal if you can, and let's make this an open source project. It could expand into something that helps people who have to keep their TPMS system in place, helping them troubleshoot what's wrong by for instance producing an auxiliary display to read from CAN the status, temperature and pressure of each wheel detected and to indicate which of the error bytes have a non-OK value. This information would be trivial to fit on an HD44780 LCD. However, reading this information is already possible on OMVS and their fancy $100 box and mobile application.
Last edited:
). My car (a 2014 Model S) uses a Baolong ECU, and can’t display the tyre pressures or temperatures. It is a simpler system than the roadster, with just one ECU, one CAN bus connection, no k-line, no Lin bus, and no external antennas. Also about US$40 (
