Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.

TPMS disable / delete on Model S 2012 to late 2014 "Baolong"


12/2013 Model S P85
Nov 25, 2021
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:
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 00

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.
Last edited:
There's valuable information in for instance this thread and especially this summarized thread, on the Roadster side and this old post on the Model S side that brought me to this forum thanks to its google search hit, although I had registered the account earlier. @scotty2541 has basically done most of the real research work I in my turn summarized in the start message.
Also, the OVMS project has something that can fake the TPMS messages on the CAN bus. It would be likely the entire Balong unit could be removed and the OVMS unit just send fake messages.

Also, the OVMS project has something that can fake the TPMS messages on the CAN bus. It would be likely the entire Balong unit could be removed and the OVMS unit just send fake messages.
Ok, I'll have to research that. Didn't see anything of the sort mentioned but it might be undocumented features or something in some certain fork of it only.
Apparently, the 2008-2012 Roadster does use the exact same Baolong system, though. The location of the module is different though.
Nit picking but Tesla started using the Baolong system in the 2.0 and 2.5 versions of the Roadster, not the 1.5 . So OVMS configured for a 1.5, and other solutions for the 1.5 Roadsters won’t help you with the Model S.

Ok, I'll have to research that. Didn't see anything of the sort mentioned but it might be undocumented features or something in some certain fork of it only.
The OVMS experts know a lot more about this than I do but there’s a lot of discussion about it in the Roadster OVMS threads.
You will find this post from the OVMS Developers Mailing List, July 2020, interesting:

TPMS subsystem, Roadster, Model S, Baolong, and some UDS hacking/cracking

Back then, I too was told that the early Model S and 2.x Roadster TPMS systems were 'the same'. They aren't. The only thing in common is the supplier Baolong (who, based on my experience with corresponding with them, go by the emoticon 🤐). 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 (or cheaper) on eBay :)

The manufacturer uses UDS Security authentication to protect writes, but implements it with a trivial protection scheme that took less than a night to break. At the time, it did make me wonder what is the point of even attempting to add a security layer so trivially easy to crack, and I I did consider commissioning a T shirt with the slogan "OR R, AND r".

The focus of that work was (a) to be able to write tyre sensor IDs to the Baolong ECU, and (b) to be able to display tyre pressures and temperatures on OVMS. Both goals were achieved, and in the public OVMS firmware today. I consider Baolong Model S TPMS a solved problem.

If I had a problem with mine, I would either swap out the sensors with bad batteries, or the ECU (both reasonably priced) - as I do consider TPMS a useful feature. But for me it has been rock-solid for 8 years now. I haven't looked much at spoofing the ECU signals, but given the above write-up, availability of cheap units for bench testing, and public disclosure of TPMS messages, it should not be difficult. A small javascript plugin to OVMS could output the required values. Alternatively, a small CAN bus device could do it relatively simply.

There are plenty of documents (DBCs, etc) on the Model S CAN bus out there, and they cover the basic TPMS messages. Brianman's Tesla Model S DBC is comprehensive, and covers TPMS, but I think only Continental messages, not Baolong. Not sure what you would need to spoof to keep the car happy, but I don't think it would be hard. Your 0x343 message is for the Roadster - on Model S Baolong it is 0x31f.

One starting point is the open source OVMS vehicle support module for the Tesla Model S:

OVMS Tesla Model S vehicle support code
Last edited:
I have 2014 Model S with the Baolong TPMS system. A long time ago, it started giving an error that says something like "sensor fault may clear next drive". I immediately went out and spent $240 replacing all 4 TPMS sensors but the error didn't go away. Tesla service said that the issue is with the now unsupported Baolong TPMS ECU. The only fix they offered was to upgrade to the newer Continental system for a cost of just over $1000. No thanks.

So I have been ignoring the error for more than 2 years now, even though I suspected it would fairly simple send packets on the CAN bus to spoof the MCU into thinking that everything was OK and turning the error message off. I just wasn't motivated enough to put forth any effort.

But I recently starting looking into this again and found Jammi's post with most of the technical legwork done. Bravo!

I just finished loading a Raspberry Pi Zero W that I paid way too much for. Arriving on Wednesday is this: PiCAN FD Zero - CAN FD HAT for Raspberry Pi Zero with 1A SMPS

I also located this http://maxwellautotech.com/wordpress/wp-content/uploads/2018/02/TDC-Sheet-Old.pdf

I already have an adapter cable attached to the diagnostic connector to run 'scan my tesla' and on closer inspection it include connections to both GND and 12V of course, but also the 'chassis bus', CAN6.

I have almost everything ready to start hacking. The eventual goal will be to replace the Raspi with a super cheap microcontroller and CANBUS chip. The Raspi is a poor choice for a permanent solution, but should be a great way to figure things out and do some testing.

I'll post here later this week with my results.
Well, I got on the chassis CAN bus. I can see and send messages. The bitrate is 500K, not 1M. Trying to set a 1M bitrate took the whole bus down and everything on it become very unhappy for a while.

Address 0x344 is definitely related to the parking brake ECU, not the TPMS. Sending messages there had pop-up warnings about about the parking brake appearing on the MCU.

I confirmed via candump that 0x318 is the 'GWT CAR State' as described in the OVMS code that makrwj linked. Thanks for that!

And of course, I also confirmed that 0x31F is seeing all zeros once every second. I believe this is coming from my failed Baolong TPMS ECU.

Sending (hopefully correct) data to 0x31F had no effect on the TPMS error message on my car, but I'm guessing that's because I need to unplug the bad ECU to stop all the zeroes its sending.

Since that requires getting under the car and removing or partially removing an underbody aero panel, it might be a few days before I get to it.

But I think this is progress!
Another update. I was able to get under the car and remove the Baolong TPMS ECU.

Once it was unplugged, the regular once per second all-zero messages on 0x31f ceased.

And the 'reset failed' message that says "Tire pressure monitor sensors were not reset. Would you like to try again?" stopped appearing. This would appear every time the car was driven, coming up about 20-30 seconds after the car was started, requiring a touch on the screen to dismiss. Good riddance!

Also, the message: "MCU_w012 Tire pressure monitoring system fault / Pressure sensor fault may clear next drive" has also disappeared and is no longer an active warning.

However, I still have the TPMS MIL (malfunction indicator lamp) on the instrument panel.

I have tried sending all three of the messages that Jammi calculated to 0x31f, but nothing happens. I even tried send them once per second for a few minutes and still nothing.

If someone has CAN logs / recordings from a Baolong-equipped Model S, they could look for 0x31f and report what messages appear there under normal operating conditions. Maybe someone like WK057 could help here.

Lastly, sending all zero messages to 0x31f does not make the MCU_w012 message return. So I suspect that there might be another CAN address involved with the Baolong TPMS as well.

So close, and yet so far.

I put the old ECU on the bench to see what messages it is sending. It had only 4 pins numbered 1 through 4. I took a guess that pin 1 was still ground with pin 2 being +12V. I then measured the voltage between ground and the remaining two pins to determine that one was CAN+ and one CAN-. Hooked these to the Pi CAN hat and was able to get valid data from candump after terminating the bus with a jumper.

I saw the following CAN data (forgive me if I'm not following proper formatting conventions, I'm new to this):

30f 00 00 00 0F 00 00 02 80
31f 00 00 00 00 00 00 00 00
35f 90 18 01 00 26 26 26 26

These all came once every second or so, with another one appearing with much less frequency:

33f 00 00 00 00 00 00 00 55

Sending the above at 35f had the 'reset' message appear on the MCU.

And sending the above for 30f had the 'MCU_w012' tmps system fault message appear on the MCU.

But changing the message data on 30f from 00 00 00 0F 00 00 02 80 to 00 00 00 00 00 00 20 F0 quenched the TPMS MIL on the dash immediately.

But it seems that the car needs to see this message regularly or the TPMS MIL reappears. So I will be probably creating a better solution to send this message than a Raspi with CAN hat. A small microcontroller with a CAN chip attached should be able to handle it.

This is good enough for me. I recently fitted an aftermarket TPMS that I am quite satisfied with, and just wanted to clear the TPMS faults on the car.
  • Like
Reactions: Gtech
(Just spotted the link to the thread after I replied to your message elsewhere... oops.)

Is there any value to a product designed to ditch the Baolong TPMS entirely?

I'm pretty sure I could whip something up that'd do this that'd just stay plugged into the diagnostic port and probably cost a couple hundred bucks.

The gateway does request things of the TPMS occasionally, and expects it to change state with the state of those requests. The faults are generally a result of the TPMS not properly fitting into those modes. I already emulate the TPMS for another project, so porting that over to something to do this would be pretty trivial. I also already have shippable hardware that could perform this task...