TMC is an independent, primarily volunteer organization that relies on ad revenue to cover its operating costs. Please consider whitelisting TMC on your ad blocker and becoming a Supporting Member. For more info: Support TMC

That TPMS issue, summarized

Discussion in 'Roadster' started by scotty2541, Nov 27, 2016.

Tags:
  1. scotty2541

    scotty2541 Member

    Joined:
    Mar 2, 2014
    Messages:
    152
    Location:
    Arlington, TX
    #1 scotty2541, Nov 27, 2016
    Last edited: Nov 27, 2016
    Here is what I determined to the consistently failing TMPS issue:

    This is a followup to:
    TPMS - Again on my LEMON. 4 times 37,000 miles

    To solve this, thry this first: Go back to your Tesla service center, and have them get their proprietary, confidential, only for Tesla use, TPMS programmer and simply reset the system to the sensor addresses. A process that can be done in less than 5 minutes.

    What follows is the result of my investigating the failed TPMS system on my Tesla Roadster. This report is rather technical, but in an abstract summary, something caused the antenna modules (both of them) to simply erase the memorized addresses of the rear tires. Such stuff doesn't (or shouldn't) happen on its own. Did something decide to mess up my sensor addresses, generating a service visit? Whatever it was, it had to be internal to the car.

    The system has (obviously) 4 sensors in the tires, and they transmit every minute or so. The content of that message is the 32 bit address of the transmitter, plus the sensor data. There are two antennas which listen for the sensors to transmit and then forward that information to a master CPU. The antennas have little CPU's in them and must be told what transmitter address to listen to, otherwise you get tire information from the guy's car next to you... or even a dozen other guys next to you at a traffic light.

    Before you try doing what I did, do yourself a favor... Go to the local hardware store and buy nine 5mm Hex head screws. The ones on the car are crappy, and the ones I purchased are infinitely better. They get a better bite with a 4mm hex drive, and won't strip out.
    crappyscrew.jpg screws.jpg betterscrew.jpg

    I purchased a new rear antenna unit from Tesla, and installed it. Of course it didn't work, because the unit didn't know my tire address codes. I also bought a LIN diagnostic device, to allow me to monitor the communication, or even insert messages.
    pinned.jpg sniffer.jpg
    So I attached my diagnostic device and collected some data. (I've got tons of logs of data, if anyone wants to consult them...)

    Then I went back and had Tesla reprogram the unit. I then read the data out of the unit again, and compared it to my failed unit. I could see what was wrong.

    Here's how it works:

    The system is a "Local Interconnect Network" (LIN) which is commonly used in the automotive industry to have sensors and systems communicate with a master controller, such as a CPU. Communication is accomplished by the master sending out an "address ID" on a bus, all slaves listening, and one (or more) doing something. There are exactly 8 bytes following the ID, but they could come from the master or a slave. I know that's vague, but it's all at the whim of the guy (or gal) who designed the communication specifications. For example, sending out an id of "2" and 8 bytes could mean "every slave do such-and-such, while sending out a "3" and 8 bytes could mean "only slave X, you need to do something". Then, maybe, sending a "4" could mean the slave needs to send 8 bytes back in, because the master doesn't send anything (data comes in, rather than goes out). Clearly, two slave units hearing a number they think is theirs, and both trying to send data back to the master would collide, and the data would be garbage.

    As for that ID number, there are 64 ID numbers (6 bits) sent as an 8 bit (1 byte) ID. Two of the bits in the ID are used as parity checking, totaling 8 bits. The higher order bits are the parity. So, for people who know base 16 (hexadecimal), an ID of 24 (hex) is the same as an ID of 64 (hex), because of the extra parity. As I compose this, I may list ID with or without the parity bits. Because my notes have them all mixed. Forgive me if I do so, it's mostly the lower nibble that matters anyway…

    From this point forward, all ID numbers and data will be in HEX notation, except where obvious (like the PSI).

    With that foundation, let's take a look at the system.
    There are two antennas; each seems to have several ID numbers that is responds to. Let's look at them:
    24 and 34 are responded to by the rear unit, because there was no reply when it was disconnected.
    23 and 33 are responded to by the front unit, (logic by elimination).
    Then there are less frequent 14, 15 which are responded to by the front as address confirmations.
    And 16, 17 which are responded to by the rear as address confirmations.

    Every 2 seconds, the master sends out 4 ID's and the slaves should respond. It appears that "23" replies with the 8 bytes, two bytes for each tire. This is the front antenna. Then ID "24" which is the rear, also replies with the same data (or maybe slightly different if it missed a message that the other antenna heard).

    So, next we have to ask: how does the antenna know what tire transmitter is what? Each tire transmitter has a 4 byte (32 bit) address is sends out. Since all mine were replaced about the same time, each one had to have an address that was close to each other. The service tech let me write down the addresses as he walked around the car reading each tire:
    Front R 08 06 66 ec
    Front L 08 06 66 2e
    Rear R 08 06 67 2f
    Rear L 08 06 66 05


    As I'm examining the data, I see that every thirty seconds, the master also sends out the following address IDs: 14, 15, 16, 17. Also, when the rear unit was disconnected, 16 and 17 were not responded to, so they clearly belong to the rear antenna. The front antenna responds with the following (left column is the ID):

    ID 8 bytes of Data
    -------------------------------------
    14 08 06 66 2E 08 06 66 EC
    15 08 06 66 05 08 06 67 2F

    Look! Those are my tire transmitter addresses!

    Also, when IDs 16 and 17 are sent, it also gave the same replies (after the device was reprogrammed).
    16 08 06 66 2E 08 06 66 EC
    17 08 06 66 05 08 06 67 2F


    Clearly, both antennas are aware of all four tires.

    So, what we have learned so far is there are 4 ID address sent every two seconds that tell it to reply with the tire pressure/temp, and 4 ID addresses sent every 30 seconds that tell it to reply with the tire sensor addresses. Here is a complete data dump, with time stamps on the left, and my comments on the right:

    (I left the parity bits on second column, which is the ID)
    Time ID Data My comments
    ----------------------------------------------------------------
    613.164944 14 08 06 66 2E 08 06 66 EC (front antenna, tell me your front addresses)
    613.189484 55 08 06 66 05 08 06 67 2F (front antenna, tell me your rear addresses)
    613.214024 D6 08 06 66 2E 08 06 66 EC (rear antenna, tell me your front addresses)
    613.238564 97 08 06 66 05 08 06 67 2F (rear antenna, tell me your rear addresses)

    (the above four ID's are sent every 30 seconds)

    613.268830 A3 52 44 51 44 6D 43 72 43 (front antenna, tell me your data)
    613.292961 73 07 00 04 00 0C 00 02 00 (front antenna, tell me your data)
    613.317092 64 52 44 51 44 6D 43 72 43 (rear antenna, tell me your data [it's the same] )
    613.341632 B4 07 00 04 00 0C 00 02 00 (rear antenna, tell me your data [it's the same] )

    (the above four IDs are send every 2 seconds)

    Lastly, from power on, I've seen it take up to 190 seconds for data to appear on all four slots.

    Examining the data:
    I lowered a tire pressure to see what would change. Here is a sample message where the front tires are 28 PSI, and the rear tires are 37 and 38, and all four tires are the same temperature 64 degrees F:
    23 52 44 51 44 6D 44 6E 43 (with the parity bits, this is "A3" from the data above)
    Here is a message where the right rear tire has been lowered to 23 PSI
    23 52 44 51 44 6D 44 42 43
    The 6E went down to 42. When I filled the tire back up, the value went back up.

    These messages came from both ID 23 and 24 (front and rear antennas). A little algebra and we could easily determine the conversion from the hex value to the displayed PSI and temperature. But I won't get into that now.

    ID numbers 33 and 34 I'm not sure about. But they gave the same message from both the front and rear antenna. The message that matches the above tire pressure of 37/38 was this:
    24 07 00 04 00 0B 00 0F 00

    When I lowered the right rear tire, the temperature also dropped from 64F to 62F. This changed
    24 07 00 04 00 0B 00 01 00
    I'm not going to worry about what these mean for now. The goal was to get the system functioning, and make that message go away.

    What went wrong:
    When I initially did the diagnostic, I attached the device, spliced into the wires, and inserted pins so I could attach the monitor device. These are the values which I read from the system:
    16 55 53 00 00 00 00 AF 00 ( Supposed to be addresses, but are not! )
    17 55 53 00 00 00 00 AE 00


    These ID's are supposed to be the addresses of all four tire sensors (I didn't know that at the time, only later when I diagnosed the working system). Clearly they are not. Somehow, they became corrupted.

    Also, examining the data, it is apparent that the rear wheel addresses for the *front* antenna are also corrupted:
    14 08 06 66 2E 08 06 66 EC ( Front Tire addresses - correct )
    15 70 53 70 52 27 00 A9 00 ( Supposed to be addresses, but are not! )


    The addresses on ID 14 are correct for my front tires, but the addresses on 15 are wrong.

    Also, 14 should match 16. And 15 should match 17. As they do in the system after Tesla reprogrammed it. But here, none of them do.

    Here is a block of data, again from the monitor, when I initially read the data from the old, failed antenna. Comments again, are on the right:
    (Addresses of tires)
    359.650363 14 08 06 66 2E 08 06 66 EC front antenna has correct address for front tires
    359.674903 55 70 53 70 52 27 00 A9 00 front antenna has incorrect address for rear tires
    359.699443 D6 55 53 00 00 00 00 AF 00 rear antenna has incorrect address for front tires
    359.723983 97 55 53 00 00 00 00 AE 00 rear antenna has incorrect address for front tires
    (Tire pressure data)
    361.652418 A3 52 40 55 41 00 00 00 00 front antenna has data on only front tires
    361.676549 73 03 00 05 00 00 00 00 00 front antenna has data on only front tires
    361.701089 64 00 00 00 00 00 00 00 00 rear antenna has nothing….
    361.725629 B4 00 00 00 00 00 00 00 00 rear antenna has nothing….


    The rear antenna was sending all zeros for all the tire data. The front antenna was sending all zeros for the rear tires, because it no longer knew the addresses of the rear tire sensors.

    What next?

    Well, there are 8 ID code we have determined so far. And all of them are codes that tell the system to send data into the master. By playing and predicting which individual bits are used, and was able to try some guesses. I pulled the bad unit, placed in on my workbench, and powered it up. Then I used my PC and the diagnostic (sniffer) device as a host, and started sending IDs to the device. I found that I could actually set the value that appears in ID 16 and 17 using ID's 12 and 13. I then have to predict that I could set the values in 14 and 15 using IDs 10 and 11. However, that unit is in the front, and I didn't remove it to test it.

    So I went ahead and reprogrammed the tire transmitter addresses on the old rear unit to match what the Tesla technician had programmed the new device for. I plugged it in, replacing the new unit and viola! Both units replied with the 14, 15, 16, 17 IDs properly. Eventually, tire data started appearing from the front antenna. When all four tires were heard from, the display showed the tire information.

    By the way, the new unit looked very old, dirty and used. He told me it was likely that someone had tried replacing it before, and decided it was not the failed part, so took it back out. However, my unit, after I cleaned it, looked newer than the one I purchased.

    Because I pried opened my old unit, and generally messed with it, I did not leave it in my car. I am using the replacement unit instead. For a reason that will become apparent later. See entry #43 on the other page:
    TPMS - Again on my LEMON. 4 times 37,000 miles

    Now, I let the old, reprogrammed, unit run for several minutes, and it never heard anything, so it never sent any tire information. Everything it sent was all zeros. But the front unit was taking up the slack for it. Here is a sample data dump:
    Data block from reprogrammed old antenna:
    258.779638 A3 52 45 52 45 6E 45 6E 45 (front antenna, all four tires)
    258.803769 73 06 00 06 00 09 00 09 00 (front antenna, not sure what it is)
    258.828309 64 00 00 00 00 00 00 00 00 (rear antenna hasn't heard anything)
    258.852849 B4 00 00 00 00 00 00 00 00 (rear antenna hasn't heard anything)
    260.958381 14 08 06 66 2E 08 06 66 EC (front antenna address confirmation)
    260.982921 55 08 06 66 05 08 06 67 2F (front antenna address confirmation)
    261.007461 D6 08 06 66 2E 08 06 66 EC (rear antenna address confirmation)
    261.032001 97 08 06 66 05 08 06 67 2F (rear antenna address confirmation)


    What I don't know is what the system would do if, after 10 or so minutes, it still never got anything from the rear unit. Would it care?

    Here is a summary of the ID numbers I found, and what they do:

    ID Purpose
    -----------------------------------------------------------------------
    To a slave unit:
    10 Set the transmitter addresses for the front tires in the front antenna
    11 Set the transmitter addresses for the rear tires in the front antenna
    12 Set the transmitter addresses for the front tires in the rear antenna
    13 Set the transmitter addresses for the rear tires in the rear antenna
    From a slave unit:
    14 Read the transmitter addresses for the front tires in the front antenna
    15 Read the transmitter addresses for the rear tires in the front antenna
    16 Read the transmitter addresses for the front tires in the rear antenna
    17 Read the transmitter addresses for the rear tires in the rear antenna
    From a slave unit:
    23 Read the tire data (press and temp?) from the front antenna
    33 Read the data (unknown) from the front antenna
    24 Read the tire data (press and temp?) from the rear antenna
    34 Read the data (unknown) from the rear antenna


    In summary, something, somewhere, decided to corrupt the tire transmitter addresses, resulting in a failure. Even if the antenna itself isn't hearing from the tires, and may not have been for several months for all I know, the other one can work.

    The process of reprogramming the correct addresses is easy, as long as you go to Tesla and have them do it. He walked around the car, reading each 32 bit address from the tire with his Tesla customer proprietary device, then plugs in his device in the ODBC II plug, and tells the host to update all the antennas. Even if one antenna isn't picking up data, the other one can take up the workload, provided the units are given the correct tire sensor addresses.

    This does open the possibility of creating a phony device that can fake out the system, just to shut it up next time it fails. You just need to know what the tire sensor addresses are that the system is expecting to hear from. Because it doesn't tell you that.
    OTOH... Maybe it's doesn't need to know, Maybe it's only important that the addresses all match up (which they didn't when my rear antenna failed).

    I hope this has been educational.
     
    • Informative x 6
    • Like x 3
  2. gregd

    gregd Active Member

    Joined:
    Dec 31, 2014
    Messages:
    1,105
    Location:
    CM98
    Excellent write-up. The November Sherlock award to you! Thanks for posting.

    But I'm a little confused... Has your original unit failed, or is something else wrong? You say it responded after you reprogrammed it, but then never heard anything after letting it run for a few minutes. Is the receiver part not working?
     
  3. scotty2541

    scotty2541 Member

    Joined:
    Mar 2, 2014
    Messages:
    152
    Location:
    Arlington, TX
    Yes, perhaps I should have tried to be more clear. First draft, after all. More anxious to post it than to clean it up.

    So, referring to the original post (linked at the beginning of this one, where I called it a lemon), plus the diagnosis steps that "MLAuto" recommended, it was determined that the rear unit had failed.

    After re-attaching the reprogrammed rear antenna which we decided had failed, it never seemed to receive any RF signal, and always sends all zeros for the data. I ran it for over five minutes. I would conclude that it is not working, and I could dig into it from the RF point of view to figure out why it died. It's possible that my action of attempting to clean the rubber like material from the circuit board actually hurt the receiver circuit. Regardless, the small MCU still communicates, so it still has the micro-code in it, and I doubt that my cleaning would have caused it to forget the tire sensor address. I conclude that some other factor actually erased, reprogrammed, corrupted those rear tire sensor addresses.

    What freaked me out was that fact that the antennas get signals from all 4 tires. So even if the rear receiver failed, the other antenna would still get the messages. So, the unit really isn't needed, except that it's memory was messed up.

    And regardless of if the rear unit was correctly receiving any signals from the tires, if the addresses were reprogrammed by Tesla, the error would have gone away and I would have gotten valid readings.

    Thanks for the "Sherlock award".
     
  4. scotty2541

    scotty2541 Member

    Joined:
    Mar 2, 2014
    Messages:
    152
    Location:
    Arlington, TX
    Followup... I forgot to include in my write up.
    Something else I was told when I picked up the replacement receiver antenna: These are the sames units that are used in the "S". So the ID commands have to be the same for both vehicles. Therefore, pretty much everything here would apply to that model as well.

    And, obviously, there are different part numbers for the front and rear antenna units. Which would be needed since they react to different ID commands.
     
  5. gregd

    gregd Active Member

    Joined:
    Dec 31, 2014
    Messages:
    1,105
    Location:
    CM98
    I'm sorry for the owners of the MS... :(

    So, final question... I'm guessing that if one of the two units has lost its memory, the bad one messes up the valid reports from the remaining good unit, right? Perhaps the overall system is actually more reliable with one of the units removed? Maybe switch one of them into "cold standby" with a toggle switch to the power line, and manually fail over when one dies? (Like having a spare bulb in your overhead projector.)
     
  6. markwj

    markwj Moderator, Asia Pacific

    Joined:
    Apr 10, 2011
    Messages:
    3,923
    Location:
    Hong Kong
    Nice. Very nice. +3 brownie points.

    So, presumably all this traffic is on the LIN bus accessible from the OBDII connector in the driver's footwell.

    A summary of this is bridged onto the Instrumentation CAN bus (DIAG connector, passenger's footwell). We've seen these CAN messages on that bus:

    OVMS uses that message do display per-wheel temperate and pressure.

    We've always suspected that 0x343 and 0x345 are also TPMS related, but have no data on those.

    The interesting part is if the LIN bus messages are bridged/accessible at all from the CAN bus (via whatever gateway is producing these 0x344 CAN messages). If so, it would open up the possibility if recording the tyre sensor IDs, and reprogramming as necessary. Alternatively, is the LIN bus accessible from an OBDII bluetooth dongle?

    Here is a CAN bus dump for a vehicle starting up and going for a drive. You can see the TPMS sensors come online, one by one...

    You can see that 0x343 byte8 high nibble seems to be 1 bit for each wheel sensor (1=valid, 0=not). bit#4 is r-r, bit #7 is r-l.
     
    • Helpful x 1
  7. hcsharp

    hcsharp Active Member

    Joined:
    Jun 7, 2011
    Messages:
    2,736
    Location:
    Vermont
    Excellent work Scotty! I'm still a little confused about your rear antenna. It sounds like you were able to reprogram the sensor IDs. If that's the case, what else do you need to know in order to design a reprogramming tool? Do you just need a way to get the sensor to give you its ID?
     
  8. wiztecy

    wiztecy Active Member

    Joined:
    Apr 29, 2012
    Messages:
    2,881
    Location:
    Santa Cruz, California, United States
    #8 wiztecy, Nov 27, 2016
    Last edited: Nov 27, 2016
    I was under the impression he still had to use Tesla and the proprietary tool in order to have them programmed in terms of the antenna:

    "The process of reprogramming the correct addresses is easy, as long as you go to Tesla and have them do it. He walked around the car, reading each 32 bit address from the tire with his Tesla customer proprietary device, then plugs in his device in the ODBC II plug, and tells the host to update all the antennas. Even if one antenna isn't picking up data, the other one can take up the workload, provided the units are given the correct tire sensor addresses."

    As for the TPMS sensors themselves, don't they already come with a unique address from the factory? I was under the impression each TPMS gets a unique ID just like the MAC address of a network card or bluetooth device.

    Possibly you could have been referring to some other programming, but this seems like all of it.

    Scotty did lead onto the idea of faking out the TPMS system if it did begin to fail, possibly something along the lines of setting up phony device / addresses to make it happy:

    "This does open the possibility of creating a phony device that can fake out the system, just to shut it up next time it fails. You just need to know what the tire sensor addresses are that the system is expecting to hear from. Because it doesn't tell you that.
    OTOH... Maybe it's doesn't need to know, Maybe it's only important that the addresses all match up (which they didn't when my rear antenna failed)."

    But looking at Mark's analysis on the CAN Bus it sounds like we can capture the appropriate and unique TPMS identifications/addresses for each wheel. The question is however, can we and do we have the power to write these on the LIN bus across the ODBII connector or CAN? And if we do, where do we find the correct location/address and how do we do that?

    Great work Scotty! Such an awesome achievement that many people appreciate.
     
  9. markwj

    markwj Moderator, Asia Pacific

    Joined:
    Apr 10, 2011
    Messages:
    3,923
    Location:
    Hong Kong
    From my understanding, @scotty2541 awesome work is on the LIN bus. The Tesla TPMS tool is part radio (walk around the car, using the radio to read the IDs from each wheel), and part LIN bus (plug into the OBDII port and use LIN bus to send the wheel IDs to the TPMS controller); from that point on, it seems that the TPMS controller talks to both antennas to poll for TPMS readings. I guess that the TPMS controller is what gateways the LIN bus values onto the instrumentation CAN bus and the VMS/VDS takes it from there.

    Anyone got any idea where the TPMS controller is? We know the two antennas (one front, one rear), but what about the controller (with LIN connections to the antennas, and a CAN bus connection to intrumentation).

    The radio side shouldn't be necessary for existing working sensors. We can listen on the LIN bus to pickup the sensor IDs, and that is all that is required. It seems that @scotty2541 has also decoded the LIN bus messages used to program the sensor IDs into the controller (LIN IDs 10,11,12,13 - details of message format would help). That would allow a self-repair, without needing Tesla or their tool.

    The problem with making a community owner tool to do this is the LIN bus. That would require a special hardware interface. Which is why I am wondering if it can be reached either via the TPMS controller from the CAN bus side, or via a simple cheap OBDII bluetooth dongle. If reachable from CAN bus, we can do it in existing OVMS hardware.
     
    • Informative x 1
  10. markwj

    markwj Moderator, Asia Pacific

    Joined:
    Apr 10, 2011
    Messages:
    3,923
    Location:
    Hong Kong
    Oh, and if the same Baolong sensors are used in both Roadster 2.x and Model S before autumn 2014, then why can't those Model S cars display pressure and temperature?
     
  11. markwj

    markwj Moderator, Asia Pacific

    Joined:
    Apr 10, 2011
    Messages:
    3,923
    Location:
    Hong Kong
    Here's a summary of the components to the TPMS system:

    1] Four wheel sensors
    2] Front "antenna module"
    3] Rear "antenna module"
    4] TPMS ECU

    The ECU is connected to the Instrumentation CAN bus, the K-Line on the OBDII connector, the front and rear antenna modules.

    Power goes to the TPMS ECU via fuse #7 in the fuse box (10A), then power, ground, and signal goes to each of the antenna modules. The TPMS ECU itself is up on the top of the dashboard.

    I've seen reference to 4 TPMS "Trigger" modules. No idea what those are.
     
    • Informative x 1
  12. scotty2541

    scotty2541 Member

    Joined:
    Mar 2, 2014
    Messages:
    152
    Location:
    Arlington, TX
    As a followup to a number of questions:
    Yes, "programming" was to set the addresses of the tires into the antenna units. The Tesla guy walked around the car with a portable device, reading the tire sensor addresses. Then plugged it into the OBDII connector, where it updated the antennas. I have to assume it acted as a bridge to the TPMS control device. I know almost nothing about OBDII communication. He showed me the addresses, and I wrote them down, before he plugged into the OBDII. The update over the OBDII was a couple seconds (very fast).

    Yes, each device comes pre-programmed with an address that you don't change. It's a 32 bit number, so you've got 4 billion to play with. (I have reprogrammed other proximity RFID things for other projects, so you probably could in this case, but it's not a good idea randomly assigning numbers)

    That device Tesla plugs into the OBDII plug can't send the addresses directly to the antennas. It's a limitation of the LIN bus protocol design. Only one unit is allowed to be a master, and that's already taken by the TPMS main unit. But there may be some communication into that unit using another physical connection (bridge as mentioned). Maybe that is the CAN bus.

    The main TPMS CPU is under the dash, behind the speedometer (I'm told) and both antenna CPUs seem to be on the same wires (bus).

    Yes, I can now easily reprogram any antenna to the correct tire sensor address. The first problem is figuring out what those addresses are. Once the antenna unit went bad, it had a different address in it (even the front antenna, which wasn't bad!!). And the main unit didn't seem to give any clue what address in may be programmed to listen to (if any). As Wiztecy said, if the OBDII/CAN bus can tell us, it simplifies one step. Alternately, it may be that once the antennas are programmed with the addresses, the main unit doesn't know or care anymore. The two antennas need to have matching address sets programmed in (see IDs 14, 15, 16, 17), and the data for each tire is based only on it's position in the message (IDs 23 and 24, see below)

    Also, physical access to the LIN bus means getting into the car. Into the dash, or at either antenna. Unplugging the rear unit, powering off the car, and proving your own power to the bus (since the master can't be running if we try to send out our own commands) would be the best option. Although not as easy as the OBDII plug. I wonder what that K bus is, when Mark said: "the ECU is connected... the K-Line on the OBDII connector,"

    As for the data that is sent, remember that every LIN "message" is one ID number and 8 bytes.
    Using the CAN messages and formula that Markwj posted:
    Hex 6E = 110 decimal. Divided by 2.755 gives 39. Which is the PSI I had. Viola!
    And hex 44 = 68 decimal, which appears to be the correct temperature, no math needed.

    So, we now know that address ID 23 (and 24) tells us the following: (2 bytes per tire, total of 8)
    F-L F-R R-L R-L
    PSI TEMP PSI TEMP PSI TEMP PSI TEMP
    52 44 51 44 6D 44 6E 43 (my data)


    The TPMS Trigger might be a command to cause the tire sensor to transmit immediately. The Tesla guy didn't hang around each tire for a minute waiting for it to transmit. He "triggered" it with his portable unit. If that's the case, there may be yet another address/command ID which the antenna knows about which can cause the tire sensor to transmit immediately.
     
    • Informative x 2
  13. markwj

    markwj Moderator, Asia Pacific

    Joined:
    Apr 10, 2011
    Messages:
    3,923
    Location:
    Hong Kong
    This is my understanding of the connection arrangement:

    Code:
    
       OBDII pin7                  (fuse#7)              CAN
            K                 GND    +12V               L   H
            |                  |      |                 |   |
            |                  |      |                 |   |
    +------------------------------------------------------------+
    |                                                            |
    |                        TPMS ECU                            |
    |                                                            |
    +------------------------------------------------------------+
              |    |    |                 |    |    |
              |    |    |                 |    |    |
             +12V GND  data              +12V GND  data
          Front Antenna Module        Rear Antenna Module
    
    
    The TPMS ECU transmits IDs 0x343, 0x344, and 0x345 on the instrumentation CAN bus. It may also receive CAN bus command messages, but we have no information on that.

    The OBDII K line (pin #7) is supposedly what is used to talk to the tool. Presumably that updates the TPMS ECU with the sensor IDs. The TPMS ECU is then master for the front and rear antenna modules using LIN protocol. No idea what the protocol for the OBDII K line is.

    I don't have any tools to work with LIN buses; although it is not too hard. Can somebody have a look at pin#7 on OBDII and see what the protocol is there?

    @scotty2541 can you send me the decodes you have, and any data dumps to mark (at) openvehicles (dot) com? What was the baud rate of the LIN stuff you captured? Can you show here the details for how you used LIN IDs 10..13 to reprogram the IDs into the antennae?

    We know that the sensors are from Baolong. Anybody know where the TPMS ECU and antennas come from?

    P.S. A while ago, I saw a service bulletin for the Roadster TPMS that said if the antenna connection comes loose then the antenna can lose it's memory of the programmed sensor IDs. I guess that is the most likely explanation for @scotty2541 problem.

    P.P.S. The reason for my renewed interest in this is explained by the picture below. I've had this for the past two days. Probably cold weather, and the tyre sensors being 5 1/2 years old.

    tpms.png
     
    • Informative x 1
  14. scotty2541

    scotty2541 Member

    Joined:
    Mar 2, 2014
    Messages:
    152
    Location:
    Arlington, TX
    Quick reply on the antennas. They are also Baolong, that's what it says on the box. See my other post. There some pics on post #43.
    I will assemble the logs, and notes in the next day or so. The raw data doesn't tell you much unless I describe what I was doing at that time.
    Also, I'll detail the device I bought to sniff.
     
  15. scotty2541

    scotty2541 Member

    Joined:
    Mar 2, 2014
    Messages:
    152
    Location:
    Arlington, TX
    This is the box from the antenna, with the part number.
    IMAG0267.jpg
     
    • Informative x 1
  16. PV-EV

    PV-EV Member

    Joined:
    Jun 3, 2011
    Messages:
    228
    Location:
    Alaska
    This might help for the physical wiring arrangement:
    TPMS ECU
    2--ign
    15--CANH
    31--CANL
    5--Kline
    21--RS232Tx
    20--RS232Rx
    1--grand
    17--front ant power (pin 2)
    18--front ant LIN(pin 3)
    22--front ant gnd(pin1)
    16--rear ant power(pin2)
    30--rear ant LIN(pin3
    14--rear ant gnd(pin1)

    Pin 4 on antenna is not used (NC)
     
    • Informative x 1
    • Like x 1
  17. PV-EV

    PV-EV Member

    Joined:
    Jun 3, 2011
    Messages:
    228
    Location:
    Alaska
    1--grand should have been 1--grd. Spellcheck isn't always helpful
     
    • Funny x 2
  18. DeedWest

    DeedWest Too Many Roadsters

    Joined:
    Feb 5, 2014
    Messages:
    268
    Location:
    North Dallas, TX
    Interesting read. Thanks for the detailed information, Scotty!

    Ironically, my car has been throwing ID 409: TPMS Hardware Error on every drive now. Hooray...
    I don't have a problem manually keeping up with my tire pressure, but this error is definitely annoying at best (the exclamation point taking place of the ability to move left on the VDS is the LARGEST annoyance of all).

    Hope to see more progress toward a solution to this widely-known issue. And hey...you don't live too far from me. Perhaps I'll contract you instead of my SC to fix the issue once you've mastered it. ;)
     
  19. PowerSource

    PowerSource Member

    Joined:
    Nov 30, 2016
    Messages:
    105
    Location:
    Orange County, CA
    The TPMS scan-tool that tesla uses is commercially available and used with RV's, namely 5th wheel trailers. You can get this product from Valor. This tool queries and reads the codes from the TPMS sensors.

    The device does have a RS232 port on it which I assume is meant for transmitting the ID's to the VDS. Have not tried uploading the ID's to the VDS using this device. Just as an FYI if someone is interested in doing more hacking...
     
  20. dvoid

    dvoid Member

    Joined:
    Sep 21, 2016
    Messages:
    7
    Location:
    Moscow, Russia
    Great post!
    As a MS owner I suffer from stupid TPMS disfunction... (

    Now it seems we have enough data to build a replacement scanner (arduino + RF board) to read sensor addresses.
    As I know tesla uses CAN bus (at least on MS) to reprogram sensor addresses. Wondering if it is possible to reprogram via K-line on ODB-2?
    Will try to build a chip scanner and read/set values on weekends.
     
    • Like x 1

Share This Page