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

OVMS issue: obdii on can3 crashes VMS

This site may earn commission on affiliate links.
I finally got around this week to installing my OVMS v3.1 unit (Firmware 3.2.013) in my roadster (1.5)

Everything is working fine - except activating OBD2 on can3 crashes the VMS. Numerous warnings pop up around lost signal for switchpack, VMS, BMB etc and door handles etc stop working.

Running OBD2 ecu on can1 and can2 works fine. After looking through the developer doc, maybe one of the MCP2515 controllers is shot? As a work around, I am considering cutting open my obd2 cable to rewire the obd connector to can2 on the DIAG port -- other suggestions?

Separately,
Code:
charge cooldown
is not working, the error is
Code:
Error: Could not start cooldown
. Any ideas what I am missing?

Thank you!
 
Um, how are you connecting the OVMS to the car? The obd2ecu task is designed to provide a basic OBDII bus on the OVMS's accessory port, normally on can3. So, OVMS connects with a short cable from its 9-pin port to the car's diagnostic port under the passenger side foot well. There's a separate short cable that goes from the OVMS 26 pin port to an OBDII connector, and your OBDII device attaches to there.

Nothing should connect to the Roadster's OBDII port (driver's side foot well). There's nothing there that we can use.

Also, what vehicle model do you have the OVMS configured for?
 
Further, you really shouldn't be aiming the OBDII task at CAN1, since CAN1 is where the car (VMS) is. That would be bad...

The way the obd2ecu task works is that it waits for a poll for data on CAN3 (how the connectors are currently wired) and then replies with whatever information the HUD requests. Stuff like vehicle speed, temps, etc. It gets the data for the response from the current metrics that the module already maintains.
 
  • Informative
Reactions: drewski
Um, how are you connecting the OVMS to the car? The obd2ecu task is designed to provide a basic OBDII bus on the OVMS's accessory port, normally on can3. So, OVMS connects with a short cable from its 9-pin port to the car's diagnostic port under the passenger side foot well. There's a separate short cable that goes from the OVMS 26 pin port to an OBDII connector, and your OBDII device attaches to there.

Yep - that's how I have it set up. The crash happens independent of what I have connected to the 26 pin port (nothing / short cable / short cable + accessory)

Nothing should connect to the Roadster's OBDII port (driver's side foot well). There's nothing there that we can use.

Correct - I don't think I have ever even touched that one

Also, what vehicle model do you have the OVMS configured for?

Tesla Roadster :)

Further, you really shouldn't be aiming the OBDII task at CAN1, since CAN1 is where the car (VMS) is. That would be bad...

Ah - that's good to know. I wish they mentioned that in the docs ...

The way the obd2ecu task works is that it waits for a poll for data on CAN3 (how the connectors are currently wired) and then replies with whatever information the HUD requests. Stuff like vehicle speed, temps, etc. It gets the data for the response from the current metrics that the module already maintains.

I understand that -- however as soon as I issue the command to start obd2ecu on can3 the VMS goes down.

I am thinking I have a hardware issue here ...
 
... and a quick update re my obd2ecu issue: I managed to cut open and resolder my OVMS-to-OBD2 cable so that the can bus pins map to can2 on the DIAG port (instead of can3) and it's working beautifully now.
Yay!

But, wow, bad cable! I bet Mark might be interested...

BTW, I've found that the 2515 chip can lock up and not see traffic from the OBDII device, depending on the timing of when the task is started, vs what the device is doing. I configured a short script to restart things in the proper order whenever the car is turned on:

OVMS# vfs cat /store/events/vehicle.on/myevent
power ext12v off
obdii ecu stop
obdii ecu start can3
power ext12v on

and the corresponding...

OVMS# vfs cat /store/events/vehicle.off/myevent
power ext12v off

 
  • Informative
Reactions: drewski
I assume you are using the standard OVT1 cable ($14.50 OVMS Data Cable for Early Teslas - official OVMS parts / Tesla Roadster v1.x/v2.x/v3.x & early Model S compatible at FastTech - Free Shipping), but am confused by your mention of an OVMS-to-OBD2 cable (which OVMS offers, but is intended for other car types).

The OVT1 cable is specific to Tesla Roadster (and other early Tesla cars before they changed the connector). It is connected as follows:

Code:
Pinout: OVT1
173851-2     DB9 -F       Signal
-------------      ---------       --------
1                      7                CAN0-H
2                      8                CAN2-H
3                      1                K-Line
4                      5                CAN1-H
6                      2                CAN0-L
7                      6                CAN2-L
9                      3                GND
10                    9                +12V
11                    4                CAN1-L
Cable: 30cm in length, 9 core
DB9-F: Moulded
173851-2: Heat-shrink tubing to protect end of cable
Label: "OVT1" in black-on-white lettering, shrink to cable

You can't just run OBDII on top of the existing car CAN buses, as the baud rate may be different (particularly the first CAN bus which runs at 1Mhz) and the arbitration IDs will probably conflict. The result would be broken CAN communications (usually between the VMS and other vehicle modules on that bus).

If you want to use an external HUD (using the obd2ecu code in OVMS), you will need a free CAN port to run the OBDII bus on. But that OVT1 cable does not have any (all three CAN buses are connected to the car). Simplest is to unplug/cut the DIAG side pins #2 and #7, then use CAN3 in the firmware. You might be able to re-wire to connect CAN3 to the car's own OBDII port, but we haven't tried that. Much safer to keep it separate.

Regards, Mark.
 
Mark -

Thank you for the detailed note. I'm afraid I wasn't clear in my original post and have caused some confusion.

Ultimately what I am trying to do is use the built in gauges function of my aftermarket radio head unit to display vehicle information provided by OVMS - I'll write this up separately once it's all done.

Therefore here's what I am doing:

(1) Roadster Diagnostic Port (Passenger footwell)
. |
(2) Roadster to ovms cable (like the one you linked, but I have an older version, ca 2018, from my prior roadster)
. |
(3) OVMS v3.1 (it says so on the PCB)
. |
(4) cable from OVMS DIAG port to an OBD type plug
. |
(5) iDatalink Maestro RR module (exposes can bus and other vehicle features to the radio - in my case just the can bus)
. |
(6) Radio (Pioneer DMH-WT7600NEX)

(1)-(3) work perfectly - OVMS is running, connected to WiFi and 3G, I can SSH in, see metrics, run commands, the mobile app works, etc

However, once i try to start the obdii ECU task on can3, both ovms and the entire VMS are shutting down (no door handles, numerous error messages on VDS, etc). Once I disconnect the ovms from the car the VMS comes back online. This happens even if I haven't connected (4). I have done a hard reset (holding S2 for 10 seconds), and redone the set up, to no avail. I'm running the latest firmware. Hence I believe I have a hardware issue in my ovms.

Now, as a work around, I have found that starting obdii on can2 works fine.

Therefore I modified the cable (4) to expose can2 rather than can3 to the OBD2 plug

With that I actually managed to successfully connect (4) through (6) and I can actually get vehicle data into my radio screen, including the customizable home screen.

So the take-aways for me are
- OVMS (and the developer doc) are terrific
- I actually got this set up working the way it would
- thank you all for helping me dig in deeper again!
 
  • Helpful
  • Informative
Reactions: drewski and markwj
However, once i try to start the obdii ECU task on can3, both ovms and the entire VMS are shutting down (no door handles, numerous error messages on VDS, etc). Once I disconnect the ovms from the car the VMS comes back online. This happens even if I haven't connected (4). I have done a hard reset (holding S2 for 10 seconds), and redone the set up, to no avail. I'm running the latest firmware. Hence I believe I have a hardware issue in my ovms.

Now, as a work around, I have found that starting obdii on can2 works fine.

Therefore I modified the cable (4) to expose can2 rather than can3 to the OBD2 plug

With that I actually managed to successfully connect (4) through (6) and I can actually get vehicle data into my radio screen, including the customizable home screen

Sounds like a really cool integration. Would love to see some screenshots of how it turns out (especially give the custom metrics capability of the ovms obd2ecu system).

Here are the Tesla Roadster CAN bus details:
  • Instrumentation: OVMS CAN1 (on OVT1): 1MHz, on DIAG pins 6/1. Contains VDS, TPMS, Instrumentation Display.
  • Powertrain: OVMS CAN2 (on OVT1): 500Kbps, on DIAG pins 7/2. Contains PEM, Switchpack, etc.
  • ESS: OVMS CAN3 (on OVT1): 125Kbps, on DIAG pins 11/4. Contains ESS and HVAC.
The problem you had is the cable you have between OVMS and the car wires all three CAN buses. Then when you start up the obd2ecu on CAN3 at 500kbps that conflicts with the vehicle's own ESS CAN bus at 125Kbps you are running this on top of. You mess up the vehicle comms between the VMS, HVAC, and ESS. It would make no difference if the HUD cable was plugged in, or not.

Switching to CAN2 solved the problem because that is the powertrain CAN bus also at 500Kbps. However, this is still possibly dangerous, because the message IDs on the bus may conflict. But probably ok.

Given the limitations, and work we are doing with OVMS, it is probably best to keep CAN1 and CAN3 for OVMS-car comms (as those are the two most useful CAN buses and I plan to release some functionality on CAN3 ESS bus to show battery brick voltages and temperatures). If you are concerned with possible ID conflict, you can disconnect CAN2 at the DIAG connector (pins #4 and #11) to make sure you don't conflict.

Regards, Mark.
 
  • Informative
Reactions: drewski
Mark -

thank you foot the detailed explanation - I think I’m starting to understand what’s going on here.

One thing has me confused:

If you are concerned with possible ID conflict, you can disconnect CAN2 at the DIAG connector (pins #4 and #11) to make sure you don't conflict.

How can I disconnect CAN2 at the DIAG connector? Isn’t that exactly how the OVMS ECU sends messages to my iDatalink?

it would make sense to me to disconnect it in the Car-to-OVMS connection (in the cable or the 9-pin connector) so that the OVMS ECU messages don’t go back into the car? But then would I not lose OVMS functionality as it pertains to the PEM/power train?

for now I haven’t seen any negative side effects of running on CAN2 btw.

I will definitely post a write up and screen shots once I get it all back together. A lot of stuff to do at work right now, and progress has been slow.
 
The DIAG connector is where OVMS plugs into the car side (the socket usually wrapped in foam, in the footwell of the car). One end of the short OVT1 cable is the 9pin D-type connector that plugs into OVMS. The other end is the DIAG connector. My suggestion is if you are concerned about conflict with the vehicle's CAN2 bus, then cut those two pins at that connector (on the OVT1 cable). That would isolate your OBDII hud from the car and avoid any interference.

Currently, OVMS on Tesla Roadster only uses CAN1. We do plan to start to use CAN3 reasonable soon (probably later this year) to talk to the ESS and get battery brick voltages + temperatures. HVAC is also on that bus, which is interesting... We don't have any plans to use CAN2 (we can't really see much on that bus useful to us).
 
Adding to what Mark said, it's really not a good idea to have a general purpose device sit on one of the car's internal CAN busses, even if they are both running at the same speed, since we don't have any control over what commands it might send. The OVMS should act as a firewall, not a pass-through.

If you have the radio now connected to CAN 2 on the 26 pin port of the OVMS, it would be a good idea to clip or otherwise disconnect the two wires that represent CAN 2 on the cable going to the car's Diag port. (Clip them on the OVMS cable, not the car!) Alternatively, go back to CAN 3 on the 26 pin port, clip CAN 3 headed to the car, and lose the ability to do the new ESS functionality that Mark described. (We're likely to recommend the CAN 3 approach, since it involves only cutting two wires and not creating a new OVMS to OBDII cable.)

All this said, I'm a little puzzled about the pedigree of your cable going between the car and the OVMS. The original cable used with the OVMSv3 box only has CAN 1 wired up, yet yours apparently has all three. If it only had CAN 1, as mine does, there would be no conflict in the default use of the OVMS's CAN3 to talk to your radio. I don't know what OVMSv1/2 used, but thought it was the same.
 
Thank you Mark and Greg - now I got it.

The confusion for me is that the 26 pin connector on the OVMS is labeled DIAG as well.

I'll stick with can2 and disconnect it on the car side cable (I might just de-pin the connector on the cable side and wrap the pins - that way it's reversible.

I bought my cables from fastech together with my OVMS back in 2018.

Item 3 below, P/N 1000400

Code:
Order #C060431017
6/4/2018
Ship to: 
Peter Hildebrandt

1. 9642829 OVMS v3.1 Kit w/ SIM5360 3G Modem Module (US Edition) 1
2. 9652027 OVMS V3 HUD / OBD II-F Cable 1 --> that's the one I modified to use can2
3. 1000400 OVMS Data Cable for Tesla Roadster 1.x/2.x 1 --> that's the one that appears to expose all 3 can buses


@gregd - i never responded to your suggestion about scripting the activation sequence. I like the idea in general, however in my case I have the iDatalink accessory powered through the radio harness (it has both a permanent and a switched 12V, like a radio head unit). I have another idea how to use the 12V output, but that's for another day. :)
 
@gregd - i never responded to your suggestion about scripting the activation sequence. I like the idea in general, however in my case I have the iDatalink accessory powered through the radio harness (it has both a permanent and a switched 12V, like a radio head unit). I have another idea how to use the 12V output, but that's for another day.
This could be interesting. Let us know how well the OVMS OBDII interface holds up. I had trouble with my simple HUD, but a different device (your radio) might be ok. If the radio starts not getting data from the OVMS (i.e. if your CAN 2 stops responding), it's a known problem with the 2515 chip / driver that we haven't been able to get to the bottom of. Knowing we have a use-case where the power cycling workaround doesn't apply might increase the priority of finding, or at least continuing to look for, a fix...
 
@Peter.h Any chance you can post some pictures/instructions how you got this fixed? I think I am running into similar problems where I use:
- OVMSv3 HUD to OBDII cable
connected to this HUD

I've managed to use the OVMS event scripting to power the thing on/off .. but from the moment I am switching the HUD from GPS mode (get your data there) to OBDII, I am getting lots of comms errors on the VDS.

Based on this thread, I am starting to understand the problem but not sure which cable or pins I need to start disabling...
 
The issue is that the CAN2 and CAN3 busses are plumbed to both ends of the OVMSv3 box. The original OVMS to Roadster cable only connected CAN1 to the car, and we used CAN3 to talk to the OBDII cable. Unfortunately, the newer OVMS to Roadster cable now connects the other two CAN busses to the car as well, so when you start driving CAN3 for the HUD, it is also fed to the car through the other cable. And being at the wrong bit rate, it's making a bit of a mess of the car's normal conversation on that bus.

The fix is to clip (or back out of the connector so it's reversible) the CAN3 pins on the Roadster end of the OVMS to Roadster cable. I'll let @markwj comment on the exact pins to do this; my cable doesn't have them.
 
@Peter.h Any chance you can post some pictures/instructions how you got this fixed? I think I am running into similar problems where I use:

Your cable connects/ exposes can3 from the extension port (the 26 pin connector) to the OBD2 connector. The issue is, as @gregd points out, that can3 is also connected on the other side, from the 9pin connector on the OVMS to the car. So you will need to disconnect can3 on the car side of the OVMS so that the HUD communication doesn't reach the car.

I am attaching the relevant pin connection diagram for the 9 pin connector (from the OVMS v3 Developer Guide, see also post #9 from @markwj above) Note that the numbering starts with 0 in this chart, while the OVMS commands start with one, so can3 will be labeled "can2" in these charts.

So you will need to grab the cable that connects the OVMS to the Roadster and either cut the wires on pins 6 and 8 on the 9-pin connector, or remove/cut pins 2 and 7 on the roadster-end of the cable (the big rectangular connector).

I ended up rewiring the cable from the OVMS to the HUD to use can2 so that can3 would be available for future ESS related functionality in OVMS - therefor I had to disconnect the pins labeled "can1" in the charts.

Let me know if you need a photo of the cable - I can pull it out and grab a photo if helpful.
 

Attachments

  • Screen Shot 2020-10-18 at 3.49.09 PM.png
    Screen Shot 2020-10-18 at 3.49.09 PM.png
    89.2 KB · Views: 106
Your cable connects/ exposes can3 from the extension port (the 26 pin connector) to the OBD2 connector. The issue is, as @gregd points out, that can3 is also connected on the other side, from the 9pin connector on the OVMS to the car. So you will need to disconnect can3 on the car side of the OVMS so that the HUD communication doesn't reach the car.

I am attaching the relevant pin connection diagram for the 9 pin connector (from the OVMS v3 Developer Guide, see also post #9 from @markwj above) Note that the numbering starts with 0 in this chart, while the OVMS commands start with one, so can3 will be labeled "can2" in these charts.

So you will need to grab the cable that connects the OVMS to the Roadster and either cut the wires on pins 6 and 8 on the 9-pin connector, or remove/cut pins 2 and 7 on the roadster-end of the cable (the big rectangular connector).

I ended up rewiring the cable from the OVMS to the HUD to use can2 so that can3 would be available for future ESS related functionality in OVMS - therefor I had to disconnect the pins labeled "can1" in the charts.

Let me know if you need a photo of the cable - I can pull it out and grab a photo if helpful.
And, to be clear, on the Roadster end, don't cut the pins on the car's connector! Tesla needs that for your service purposes.