TPMS CONTINUES TO FAIL... [RANT] And they are gonna send people the mars?

[int32_t]

I "fidgeted" with some of them at the tire store... Demo units. They are sealed tight. Vibrations may make the tuned circuits mess up, but the batteries are really tight. Then the battery doesn't have the instant power to transmit anyway, so I'm sure there is a capacitor to absorb supply spikes. Finally, they only transmit every few minutes. A lost unit for a minute or two is insignificant.

The antennas store their "listening" addresses in EEPROM or flash. When I bench analyzed a unit, I could reprogram it, and remove power, then test it later, and the addresses remain.

Yeah, I get that. This is going years back now, but our devices had supposedly non-volatile memory and excellent battery contacts too, but due to memory corruption issues we ran into years ago with slightly imperfect battery contacts and/or on-off switches, we developed a suite of tests to stress the system and try to corrupt the memory. The tests primarily involved making a mess of the supply voltage while the device was initialising. It worked (i.e., caused things to fail) at first, but as the years went by the silicon got better, and it hasn't been a problem in years since modern silicon isn't bothered by voltage dips during power-up: the device's POR circuit holds the device in reset until the supply voltage is above a reasonable threshold to guarantee proper operation.

The thing is, tight or not, any battery contact short of actually soldering or spot-welding the battery to the electronics is going to disconnect given the vibration a tire will see on the road, however briefly. (We didn't think our battery contacts were the problem either until some testing proved otherwise.) Whether or not these brief disconnects can affect memory is a function of how good the chip's brown-out detect circuit is and other stuff. It's much easier to go with @markwj's hypothesis that it's software-related -- because I missed that minor point that two units went bad, not just one.

 

[ShawnA]

Hi All,
Please be kind to the rookie here...
I have a Valor TPMS VSMARTOOL arriving from Canada tomorrow.
It was not too expensive $247 US including air freight from Canada.
I would like to be in better control of programming the sensors to the car myself.
Would anyone with a Tesla branded tool care to share the wiring diagram for the harness?
What I know so far is that there are only 2 wires from the RS 232 DB9 connector on the Tesla harness that go to the
cars ODB II connector.
On the car the ODB II connector only has contacts in positions 1, 4, 5, 6, 7, 9, 12, 14, and 16.
My car is a Roadster Sport 2.0 serial 785.
Thank you for your help, Shawn

 

[PV-EV]

7 and 12 are Kser. 6 is CanH and 14 is CanL. 4 and 5 are grd. Not sure if that is helpful. I don’t have the Tesla tool.

 

[markwj]

I have a Valor TPMS VSMARTOOL arriving from Canada tomorrow.
It was not too expensive $247 US including air freight from Canada.
I would like to be in better control of programming the sensors to the car myself.
Would anyone with a Tesla branded tool care to share the wiring diagram for the harness?
What I know so far is that there are only 2 wires from the RS 232 DB9 connector on the Tesla harness that go to the
cars ODB II connector.
On the car the ODB II connector only has contacts in positions 1, 4, 5, 6, 7, 9, 12, 14, and 16.
My car is a Roadster Sport 2.0 serial 785.

For 2.0 cars, the TPMS ECU is connected to both the instrumentation CAN bus and the K-line. Of those two, only the K-line is exposed on the OBDII connector, so most likely that is what you want. Take care; that K-line also has ABS and SRS ECUs on it.

Pin out for OBDII (Roadster 2.x):

1. Switchpack Power Sense (link to #9)
2. n/c
3. n/c
4. Ground (link to #5)
5. Ground (link to #4)
6. Diagnostics CAN-H
7. K-line (link to #12)
8. n/c
9. Switchpack Power Sense (link to #1)
10. n/c
11. n/c
12. K-line (link to #7)
13. n/c
14. Diagnostics CAN-L
15. n/c
16. Fused Power

I think you want #7/#12 (K-line) and #4/#5 (GND).

If you do get it to work, a diagnostic dump of the messages sent/received on that K-line bus during sensor ID read/program would be invaluable to the community.

P.S. It is theoretically possible (connection-wise, at least) for the TPMS programming to go through OBDII CAN4 into the VMS, get bridged/translated by the VMS out the instrumentation CAN bus, and then on to the TPMS ECU. But, highly unlikely. More likely it just goes the direct route via K-line.

 

[ShawnA]

Thank you for your replies.
I believe the Tesla Smartool harness links DB9 Pin 1 to ODB2 Pin 4 and may be bonded to ODB2 pin 5.
The other line (there are only 2 of them in the Tesla harness) DB9 Pin 7 to ODB2 Pin 7.
The Valor Smartool readily reads the Baolong sensors and some recently installed Dill 2112 which are the same as Baolong.
I have made a harness like this to try to load IDs from sensors to car - It did NOT work.
Some differences I have noted between the Tesla tool and the Smartool are the Tesla reads 4 tires and transmits them.
The Smartool defaults to a 3 axle vehicle. The Smartool has a "vehicle ID" (6 characters) on the same screen as the
start of the listing of tire sensor IDs which are 8 characters..
Mine is blank. I believe Tesla assumes or spoofs the vehicle ID because from what I can see it never "asks" to retrieve them.
To transmit with the Tesla tool transmits - the tool is changed from by the operator from "wireless" to "Serial port" after the change it shows "K-line."
I don't know if the K-line is a "choice" or just an indication of how the data is transmitting.
On my Valor Smartool I select "Transmit" then change from "Wireless" to "Serial Port."
When I press "enter" it shows "transmitting" followed by "Failed."
I never see "K-line" like the Tesla tool...

Markwj - Are you suggesting that perhaps ODB2 Pin 7 and ODB2 Pin 12 should be bonded in my harness?
I know nothing about Can Bus and K-line communications.

Thank You for your comments and questions,
Shawn

 

[markwj]

Markwj - Are you suggesting that perhaps ODB2 Pin 7 and ODB2 Pin 12 should be bonded in my harness?
I know nothing about Can Bus and K-line communications.

Pins #7 and #12 are the same. If you do a continuity check on them, you should see them connected together somewhere in the vehicle OBDII side harness wiring.

 

[ShawnA]

Hi Markwj,

Thank you. If there is continuity there is no need for me to connect them to each other in my harness.

I have a Valor ECU on order. It will be here soon. The harness is on order from Canada.
While I am waiting for the harness, I will be able experiment with the tool and their ECU.
I will keep you posted.

Thanks again, Shawn

 

[ShawnA]

Progress!!!
I have figured out part of the "mystery" of the Tesla tool.
They are using non-standard pin locations in the RS232 DB-9 connector.
DB-9 Pin 1 for ground and DB-9 Pin 7 for the serial (K-line) signal.
I bought and RS232 connection tester that has an LED for each of the nine pins.
I did not see any activity from the Valor Smartool using the above pin locations.

Last night I got a Valor ECU in the mail. I also got many Valor wiring diagrams for their harnesses
AND the RS232 connection.
They use DB-9 Pin 5 for ground not pin 1 like Tesla.
They use DB-9 Pin 2 for transmit not pin7 like Tesla.
So my new 2 wire harness from the Valor Smartool to the Tesla:
Valor Smartool now connects DB-9 Pin 5 to OBD2 pin 4 and pin 5. (Chassis and Signal Grounds)
Valor Smartool now connects DB-9 Pin 2 to OBD2 pin 7 (K-line)

With the Valor configuration the transmit light barely flickers when I send a wheel sensor configuration
to the car.
The communication ultimately fails, but the good news is that now I have a "visible" signal heading
toward the Roadster...

I just ordered one DB-9 double female cable and a DB-9 double female null modem cable.
I want to connect the transmitting Valor Smartool to my laptop through a simple serial program.
I hope to be able to see the format of the data transmitted from the Valor Smartool...

Hurry up and wait for the cables on Saturday...

Shawn

 

[markwj]

I just ordered one DB-9 double female cable and a DB-9 double female null modem cable.
I want to connect the transmitting Valor Smartool to my laptop through a simple serial program.
I hope to be able to see the format of the data transmitted from the Valor Smartool...

The K-line protocol is a little bit more tricky than straight RS232 serial. Negotiation uses a different baud rate, and some other hoops to jump through. That said, you may be able to see something on a serial terminal.

The other option is a simple OBDII dongle. Bluetooth / wifi / usb. These talk all the protocols, and you can command them to force K-line, and monitor all traffic (showing you received K-line commands and responses).

What you are doing here is incredibly valuable to the Roadster community. I really hope you can get this tool working, and get dumps of (a) reading IDs from car, (b) writing IDs to car.

 

[ShawnA]

Hi Mark,
Thank you. I get looking at all of this and forgot to mention that the tool does easily read the IDs of the sensors
in the tires. With the Valor tool, I just walk around the car and take readings, just like the Tesla man...
I believe the tool sends a 125 (Mhz?) signal to wake up the tire and tell it to "report." It sends its ID and the tool
records it. Somewhere in this thread or other there was a mention of "senders" in an earlier version of the car.

I would like to see and record the output from the tool - probably normal RS232 - and if so we could use another dongle
or whatever to force K-line communications into the car. The Tesla tool before or during communications shows the display
"K-line."

Sorry for the giant picture. The Valor tool readily picked up (by RF) the vehicle ID from the Valor ECU.

I wonder if it would be a candidate to replace the Tesla/Baolong ECU because Valor I believe is also Baolong...

Waiting for the cables Saturday... ... Shawn

 

[ShawnA]

I received the DB-9 cables today.
I used a null-modem cable to bring in data transmitted by the Valor Smartool.
The data was as if it was programming the ECU.
I did receive data at 9600 baud 8, N, 1 into my laptop into a serial communication program.
I do not know what encoding scheme was used.
Anyone who recognizes these strings, please let me know what the encoding is...

4e 22 00 43 a0 N".C
ef 09 4f ef af ï.Oï¯
ef 09 4f ef af ï.Oï¯
ef 09 4f ef af ï.Oï¯
ef 09 4f ef af ï.Oï¯
ef 09 4f ef af ï.Oï¯

The only ID in the Valor tool was the ID of the Valor ECU.
It is "001B9D". Those are leading zeroes.

The first line or part of it may be a request for acknowledgement or handshake.
After that all of the data was the same repetition.

Thank you, Shawn

 

[markwj]

Anyone who recognizes these strings, please let me know what the encoding is...

4e 22 00 43 a0 N".C
ef 09 4f ef af ï.Oï¯
ef 09 4f ef af ï.Oï¯
ef 09 4f ef af ï.Oï¯
ef 09 4f ef af ï.Oï¯
ef 09 4f ef af ï.Oï¯

Maybe K-Line StartCommunications request. That is:

• Format byte
• Target address byte
• Source Address byte
• Service byte
• Checksum

But k-line is 10,400baud.

I thought checksum for K-line was just straight 8bit addition. But that gives:

4E+22+00+43
B3
EF+09+4F+EF
236

which doesn't match. Maybe the data is getting corrupted by the 9600baud vs 10400baud issue?

 

[scotty2541]

Maybe K-Line StartCommunications request. That is:

• Format byte
• Target address byte
• Source Address byte
• Service byte
• Checksum

But k-line is 10,400baud.

I thought checksum for K-line was just straight 8bit addition. But that gives:

4E+22+00+43
B3
EF+09+4F+EF
236

which doesn't match. Maybe the data is getting corrupted by the 9600baud vs 10400baud issue?

On his image, those definitely look like tire addresses. (Shawn, on the reply, you can select to insert an image as a "thumbnail", and it'll be smaller, then show the larger one when clicked)

If you can't get the baud rate correct, then the checksum values will never appear correct. So don't count on any terminal program to give you anything useful, because it's going to have half-assed data and framing errors. And the difficulty is that there is no 10,400 baud setting on a conventional UART for a PC (or terminal).

For example, 4E 22 00 43 has to really be 00 1B 9D, so 24 bits of 10,400 baud tries to stretch out to 32 bits at the lower 9600 baud speed, with all the framing and parity errors.

My solution, if I were doing it, would be to hook up a scope, and decipher the waveform to match what I see being sent (the first 16 bits would be enough). Then measure the timebase to determine the baud rate. Then, I could program an MCU with that non-standard baud rate and have it read the data, and either display it, or re-transmit it.
But that is me... if I had the time on my hands, I'd nerd out on it.

But on the positive side, you may not need to. If the SmarTool talks the same as the ECU, then they are the only ones that care... You may not need to sniff it, assuming you can figure out what to send. Maybe something in the service display tells you the vehicle ID, or maybe it's the same for every Tesla using that Balong system. (I don't recall the Tesla guy programming an ID from the service screen or even the VIN before he re-programmed the sensors)

Hope this helps.

-Scotty

 

[ShawnA]

Hi Scotty,

Thank you. I will install 2 more sensors tomorrow. Just after the first 2 sensors were installed the second two died.
I know we normally install all 4 at once but I seem to remember Tesla installing only 2 for new tires
and I cannot find the invoice...

I am with you on the ECU/MCU. Tesla never has programmed this on the portable tool that I could see.
It either picks it up during the transmission or transmits to a universal ECU ID.

On the communication front: I am hoping that they are using "fast" K-line communications.
The "slow" K-line first sends a 5 baud handshake request and then steps up the speed.
If they are using the "slow" I am confident that this tool will not work.

I will keep you posted tomorrow night after the second two sensors are installed.

Thanks again, Shawn

 

[scotty2541]

Hi Scotty,

Thank you. I will install 2 more sensors tomorrow. Just after the first 2 sensors were installed the second two died.
I know we normally install all 4 at once but I seem to remember Tesla installing only 2 for new tires
and I cannot find the invoice...

I am with you on the ECU/MCU. Tesla never has programmed this on the portable tool that I could see.
It either picks it up during the transmission or transmits to a universal ECU ID.

On the communication front: I am hoping that they are using "fast" K-line communications.
The "slow" K-line first sends a 5 baud handshake request and then steps up the speed.
If they are using the "slow" I am confident that this tool will not work.

I will keep you posted tomorrow night after the second two sensors are installed.

Thanks again, Shawn

Watch him if you can... I am on good terms with the guy who did mine, and he let me write down the addresses as he scanned them.
Ask him about this ECU ID. He might know something about it.

 

[Timothy]

My TPMS has always seemed to work fine so far. But now I think it has a neurologic disease--left right confusion.

I had low pressure in the right rear tire--and the TPMS said it was the left. So I filled and lowered the pressure in each of the tires and checked TPMS readings. The front were fine. The rear tires had left right confusion. Has anyone had this issue? Is this something Tesla can fix by computer? Or does one need to swap the TPMS units in the rear tires to the opposite side?

 

[scotty2541]

My TPMS has always seemed to work fine so far. But now I think it has a neurologic disease--left right confusion.

I had low pressure in the right rear tire--and the TPMS said it was the left. So I filled and lowered the pressure in each of the tires and checked TPMS readings. The front were fine. The rear tires had left right confusion. Has anyone had this issue? Is this something Tesla can fix by computer? Or does one need to swap the TPMS units in the rear tires to the opposite side?

They can fix it with their device. On a roadster, they would need to plug into the dash connector. But it takes about 90 seconds.

Alternately, next time you are at the tire store, they can swap the tires and reverse the wheels (most likely un-mount the tires because of directional rotation)

 

[Timothy]

They can fix it with their device. On a roadster, they would need to plug into the dash connector. But it takes about 90 seconds.

Alternately, next time you are at the tire store, they can swap the tires and reverse the wheels (most likely un-mount the tires because of directional rotation)

Thank you. The first method seems the simple. The second sounds more difficult.

 

[csummers]

I have Roadster #302 v1.5 and the original TMPS finally failed after 9 yrs. The original manuf was bought out by HUFF. Amazon/ebay or better yet local auto parts store usually carry replacements since they have been mandated since early 2000s. (?) [ about $150 set/4] Since they are so common even local Firestone can replace in a pinch. I brought mine to Svc Ctr cause I had them mount new tires anyway

 

[strider]

I have Roadster #302 v1.5 and the original TMPS finally failed after 9 yrs. The original manuf was bought out by HUFF. Amazon/ebay or better yet local auto parts store usually carry replacements since they have been mandated since early 2000s. (?) [ about $150 set/4] Since they are so common even local Firestone can replace in a pinch. I brought mine to Svc Ctr cause I had them mount new tires anyway

Yep. The older cars had a much better system. The 2.5's have the craptastic Baolong system which is the subject of this thread.