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

[markwj]

Interesting. Any pointers to those tools?

The Valor Smartool seems to be what Tesla is based on. ATEQ list Tesla compatibility for some of theirs. The ones with OBDII support are $$$.

The 4 CAN attempts, for example, appear to simply be asking for what the car supports.

The wiring guide lists a diagnostic CAN on that connector, but I've never seen it. Also a K-line bus to the TPMS. But no ECU to respond to standard PID enquiries.

What I was suggesting was to use an OBDII dongle, and async terminal software to talk to it using ELM327 commands. Set to K-line 10.4kbaud, and "monitor all" to see what shows up.

 

[PowerSource]

The Valor Smartool seems to be what Tesla is based on. ATEQ list Tesla compatibility for some of theirs. The ones with OBDII support are $$$.



The wiring guide lists a diagnostic CAN on that connector, but I've never seen it. Also a K-line bus to the TPMS. But no ECU to respond to standard PID enquiries.

What I was suggesting was to use an OBDII dongle, and async terminal software to talk to it using ELM327 commands. Set to K-line 10.4kbaud, and "monitor all" to see what shows up.

ATEQ is only for S/X (ie VTxx) Valor Smartool is for Roadster. If the owners can get the settings from Tesla branded SmarTool, we could all do a bulk buy of the non Tesla branded Valor SmarTool around $2-300 from a re seller in Canada. This would solve the issue once and for all.

 

[markwj]

ATEQ is only for S/X (ie VTxx) Valor Smartool is for Roadster.

http://www.iapdirect.com/images/T/VT30_VT15_Application_Chart.pdf

If the owners can get the settings from Tesla branded SmarTool, we could all do a bulk buy of the non Tesla branded Valor SmarTool around $2-300 from a re seller in Canada. This would solve the issue once and for all.

That is a great price.

 

[PowerSource]

http://www.iapdirect.com/images/T/VT30_VT15_Application_Chart.pdf



That is a great price.

I have the VT30, it does not work on the Roadster (won't read the sensor)

 

[gregd]

What I was suggesting was to use an OBDII dongle, and async terminal software to talk to it using ELM327 commands. Set to K-line 10.4kbaud, and "monitor all" to see what shows up.

So, there appear to be 3 protocols related to K-line, ISO 9141-2, 14230-4 slow and fast init. For reference, ELM327 has these as protocols 3, 4, and 5, respectively. Put the dongle in Monitor mode (ATMA), and turned on the ignition (er, whatever we call it) key. Nothing reported for any of the three protocol settings. Is there something I should do to trigger a K-line message? It certainly isn't very chatty, if it's even there.

To be fair, I tried the same with my ICE (2013 Honda CR-V). It was also totally quiet. Protocol 6 (500kb CAN), however was very active on the ICE, verifying that my manual sending of commands to the ELM dongle was working. The Windows software that normally drives it (OBDWiz) supports the K-line protocols, so I assume (yes, I know) that the dongle does too. It's an OBDLink SX model (USB).

So, now what?

 

[markwj]

So, there appear to be 3 protocols related to K-line, ISO 9141-2, 14230-4 slow and fast init. For reference, ELM327 has these as protocols 3, 4, and 5, respectively. Put the dongle in Monitor mode (ATMA), and turned on the ignition (er, whatever we call it) key. Nothing reported for any of the three protocol settings. Is there something I should do to trigger a K-line message? It certainly isn't very chatty, if it's even there.

To be fair, I tried the same with my ICE (2013 Honda CR-V). It was also totally quiet. Protocol 6 (500kb CAN), however was very active on the ICE, verifying that my manual sending of commands to the ELM dongle was working. The Windows software that normally drives it (OBDWiz) supports the K-line protocols, so I assume (yes, I know) that the dongle does too. It's an OBDLink SX model (USB).

So, now what?

I think the approach is correct. Two possibilities:

1] You need to drive (as TPMS only outputs data when driving)
2] The TPMS ECU doesn't send anything, but instead needs to be actively polled

What we are looking for is a way to read the IDs from the car, and write them back.

The best way of doing this would be to get one of those Scantools for Roadster, put in an OBDII Y cable with the dongle on one and scantool on the other, then upload the IDs to the car while getting a trace of the traffic. Anyone here have one who could work with Gregd on it?

 

[PowerSource]

I can send him one of my Valor's... Where is greg located?

Hopefully an owner with the official Tesla branded tool is willing to volunteer their tool

 

[gregd]

I'm in Northern CA (30 mi east of Sacramento), but lemme try doing a drive first. The car was on, but still plugged in to the EVSE and not in drive. Always looking for an excuse to go for a drive... Maybe Thursday - supposed to be a storm coming through tomorrow, but will see what I can do.

How often are the TPMS sensors polled? I thought from the earlier discussion that it was every 2 seconds (at least on the LIN Bus).

 

[gregd]

So it occurred to me late last night that I don't actually need to go for a drive. I can sit in my car in the garage with the door closed and the heat on. Duh... Nice and toasty.

So, results. Or rather, the lack thereof.

Protocols 3-7 (the three K-line and two CAN) all turned up negative. Waited 2 minutes on each setting; no traffic at all. I verified on the VDS that the tire pressures were being measured (changed from "---" to actual numbers) on the Info -> Tires screen. So the sensors were being read, just not reported summarily on the OBDII port, at least not that I could see. This is on a 2.0 Roadster non-Sport, in Drive (foot on brake!).

For documentation purposes, the commands used with the ELM327 dongle were:

atz (Reset)
atl1 (enable linefeeds on output)
ath1 (enable header logging)
ats1 (print spaces)
atal (allow long >7 byte messages)
atspn (set protocol to 'n' - 3,4,5,6, & 7 tried)
atma (monitor all)

{sigh...}

 

[PowerSource]

PM me your address and I can send you my Valor SmarTool (similar to the Tesla tool)

It reads the TPMS sensors but I cannot get the right config to output to the VDS. You may have better luck, figuring out the settings.

 

[markwj]

So it occurred to me late last night that I don't actually need to go for a drive. I can sit in my car in the garage with the door closed and the heat on. Duh... Nice and toasty.

So, results. Or rather, the lack thereof.

Protocols 3-7 (the three K-line and two CAN) all turned up negative. Waited 2 minutes on each setting; no traffic at all. I verified on the VDS that the tire pressures were being measured (changed from "---" to actual numbers) on the Info -> Tires screen. So the sensors were being read, just not reported summarily on the OBDII port, at least not that I could see. This is on a 2.0 Roadster non-Sport, in Drive (foot on brake!).

For documentation purposes, the commands used with the ELM327 dongle were:

atz (Reset)
atl1 (enable linefeeds on output)
ath1 (enable header logging)
ats1 (print spaces)
atal (allow long >7 byte messages)
atspn (set protocol to 'n' - 3,4,5,6, & 7 tried)
atma (monitor all)

{sigh...}

That all looks correct. So most likely the K-line on OBDII is only used for setting (or reading?) the sensor IDs from the OBDII TPMS tool.

If we want a third party (perhaps OVMS) way of reading/writing those IDs to the ECU, then the best approach would seem to be capturing the traffic while the OBDII TPMS tool was in use.

 

[gregd]

If we want a third party (perhaps OVMS) way of reading/writing those IDs to the ECU, then the best approach would seem to be capturing the traffic while the OBDII TPMS tool was in use.

Agreed. For what it's worth, here's the "Y" cable I've been using for a different project. It has all 16 wires (some just do the CAN ones).
Amazon.com: Tonsiki 16 Pin OBD2 OBDII Female Splitter Extension Auto Car Connector J1962 Y Cable: Automotive

PM me your address and I can send you my Valor SmarTool (similar to the Tesla tool)

It reads the TPMS sensors but I cannot get the right config to output to the VDS. You may have better luck, figuring out the settings.

If we need to go in through the OBDII or Diag port for this, an off-the-shelf scan tool will not work. Assuming your tool can talk to the OBDII port (I don't have their datasheet, but it has a serial port on the side, no?), I would bet the PIDs would be different, and we won't know the right ones until we can capture a Tesla-branded one in action. I appreciate the offer, but there's not much I can do with it that you haven't already done.

 

[scotty2541]

Last night I got the code working. The project is in bare metal assembler, since timing is rather precise and I am trying to use one of the lowest cost MCU's (small size, small footprint, small memory). It is a high quality component (Microchip pic16F628A or pic16F819).

Next, I will design the circuit board. Does anyone have any leads on where I can get the connector?
Removing a connector from an existing device has some problems:

• The entire circuit board is covered with a rubberized coating
• Obviously, there is a limited supply of antennas to cannibalize.

Here are a couple of images:



I'd really like to make it a "plug in" replacement. Rather than make someone splice into the wires.

-Scott

 

[scotty2541]

After digging... I see that this is the end which has the wire harness.
Search Results | TE Connectivity

And this appears to be the mate for it.
Search Results | TE Connectivity

At least I am hoping. I have samples coming.

 

[hcsharp]

Last night I got the code working. The project is in bare metal assembler, since timing is rather precise and I am trying to use one of the lowest cost MCU's (small size, small footprint, small memory). It is a high quality component (Microchip pic16F628A or pic16F819).

Next, I will design the circuit board. Does anyone have any leads on where I can get the connector?
Removing a connector from an existing device has some problems:

• The entire circuit board is covered with a rubberized coating
• Obviously, there is a limited supply of antennas to cannibalize.

Here are a couple of images:

View attachment 220298 View attachment 220299

I'd really like to make it a "plug in" replacement. Rather than make someone splice into the wires.

-Scott

Nice work! I suspect you'll spend way more $ on those connectors than you will on the microcontroller. Sooo... you might want to use a MCU that cost $2 more and program it in a language that's much easier to maintain and others can modify. Just my .02

Microchip makes a few 8-bit MCUs that have built-in CAN bus and LIN functionality.

Thanks for the progress report!

 

[scotty2541]

Nice work! I suspect you'll spend way more $ on those connectors than you will on the microcontroller. Sooo... you might want to use a MCU that cost $2 more and program it in a language that's much easier to maintain and others can modify. Just my .02

Microchip makes a few 8-bit MCUs that have built-in CAN bus and LIN functionality.

Thanks for the progress report!

I was digging and didn't come up with any that supported LIN. The entire PIC 10-18 line parametric search only shows UART, I2C, SPI, USB. All the AN's on their site are materials on coding the interface yourself.

As for connector prices, I can't find it in stock at Mouser or Digikey. TE's site doesn't list a price, nor direct me toward distributor who carries it. However, right now it's free. I requested a few samples, and they came up as no charge.

If successful, I have a market of what? 10 units? I don't expect to recoup my design labor in that quantity. It's the educational value for me. And hopefully, it will be a device that has a lifespan of more than 15 months.

 

[scotty2541]

Nice work! I suspect you'll spend way more $ on those connectors than you will on the microcontroller. Sooo... you might want to use a MCU that cost $2 more and program it in a language that's much easier to maintain and others can modify. Just my .02

Microchip makes a few 8-bit MCUs that have built-in CAN bus and LIN functionality.

Thanks for the progress report!

I see the PIC24 series has some devices which contain a LIN module (16 bit). Some are extremely low cost. Maybe for version #2

 

[scotty2541]

Nice work! I suspect you'll spend way more $ on those connectors than you will on the microcontroller. Sooo... you might want to use a MCU that cost $2 more and program it in a language that's much easier to maintain and others can modify. Just my .02

Microchip makes a few 8-bit MCUs that have built-in CAN bus and LIN functionality.

Thanks for the progress report!

I'm going to retract my last statement... The datasheets for those PIC 24 devices that claim to support LIN, don't seem to provide any details. All they say is LIN/J2602...

The structure of an automotive LIN message is such that you can't just feed it through a UART and expect it to work. It would be necessary to tell the MCU device that the inbound message is a LIN message, and there doesn't appear to be any configuration to do such a thing.

i.e. The commencement of a LIN packet is a > 11 bit (13 bit typical) sync break. A UART would see that and immediately go into failure mode as a framing error.

But since the balance of a LIN packet is an 8bit/1stop bit message, I suspect they are claiming that it can talk to some kind of LIN BUS Interface controller, which strips the sync break, and reframes the bit timing.

In fact, further digging shows only this device:
PIC16F1829LIN - Microcontrollers and Processors
And it still requires the level of coding I did. The only thing the device gives is an integrated MCP2021 bus access chip to let the MCU handle bidirectional 12 volt signal levels.

My circuit has a separate MCP2021 chip.

 

[strider]

If successful, I have a market of what? 10 units? I don't expect to recoup my design labor in that quantity. It's the educational value for me. And hopefully, it will be a device that has a lifespan of more than 15 months.

Thank you for the update! I am very excited by this. As I said before I will certainly buy one. A plug-in version would be nice but I'm no stranger to splicing wire. I still have a bunch of Scotchlok UY2 connectors from my days at the phone company.

 

[hcsharp]

I don't have much experience with LIN but I used a PIC18Fxx80 with built in CAN. The chip is obsolete but the newer versions like the PIC18F66K80 family have CAN, ECAN and LIN/J2602 functionality built in. A quick look at the datasheet for the 18F66K80 shows how to configure LIN to work on one or both of the USART.