[Ovmsdev] OBD2ECU use with latest Roadster cable?

Tue Aug 4 11:21:08 HKT 2020

Greg,

> How do we make this "Layman safe" out-of-the-box

The issue is one off quantity. There simply aren’t enough users of the HUD system to make it economically feasible to have custom cables for everyone (and to cripple the 99.9% of users who don’t use the functionality by removing support for one of their CAN buses). The manufacturers I deal with in china have a MOQ of about 100 for custom hard-wired cables. We have sold about 20 HUD cables in the past year or two (leaving the project with 80 unused in stock). It would be worse if we had to make two or three different variants of this.

Sorry to sound negative, but given the limitations and quantities involved, I think the reality is that the HUD system is always going to have to be very custom (last least on cars with more than two CAN buses).

That said, the Tesla cars are the only ones at present that use CAN3, so the solution should be purely to document exactly what is required for those cars. Personally, I think it easiest to cut CAN3 from the OVT1/OVT2 cable, use the standard HUD cable, and live with the limitations. Snip Snip. If the HUD supports 125Kbps, the alternative is to set obd2ecu to that, but I really don’t like the idea of running OBDII traffic on buses not intended for that.

> Should I deny allowing obd2ecu to be configured on CAN1?

I don’t see any advantage to crippling that functionality. There may be cases where that is the best approach.

> The obd2ecu task is fixed at 500kbps because that's what all of the HUD-type devices seem to use.  Adding a rate parameter should be easy, but I don't see it as solving anything.

Standard OBDII devices should negotiate speed. I know the HUDs I have try 500Kbps and if that doesn’t work they try 250Kbps, etc. Same for OBDII dongles based on ELM327, etc.

The reason I suggested adding the rate parameter is it gives us some flexibility, and takes nothing away (assuming it defaults to 500Kbps).

This article explains this quite well: https://copperhilltech.com/blog/how-can-bus-automatic-baudrate-detection-works-and-what-to-consider-when-connecting-to-a-network/ <https://copperhilltech.com/blog/how-can-bus-automatic-baudrate-detection-works-and-what-to-consider-when-connecting-to-a-network/>

See page #25 on this ELM327 spec for their approach of auto-baud rate detection: https://cdn.sparkfun.com/assets/learn_tutorials/8/3/ELM327DS.pdf <https://cdn.sparkfun.com/assets/learn_tutorials/8/3/ELM327DS.pdf>

>  First, why did starting obd2ecu on CAN3 cause the observed behavior?

Because the CAN3 in the car is 125Kbps, and the obd2ecu task configured CAN3 to 500Kbps in active mode. That messed up the traffic on the car’s CAN bus.

> The obd2ecu task is silent unless and until it receives a valid polling frame from the device, which should be impossible given the speed mismatch.  How can changing the bit rate on one CAN device affect the rest of the bus, if that device is otherwise silent?

Not quite. The obd2ecu task initialises the bus in ACTIVE mode. That is not silent. The CAN hardware will, in that mode, actively participate in bus communications and acknowledge traffic. LISTEN mode would not be an issue (it would just see garbage can frames), but you can’t transmit in that mode.

> Second, the OP in the TMC thread stated that they were using a pre-OVT1 cable.  If so, CAN 2 & 3 shouldn't have been connected

Based on the symptoms listed, and solution he gave, his cable MUST have all three buses connected. Either the OVT1 label was not not visible, or this cable was prior to us adding those labels.

Regards, Mark.

> On 4 Aug 2020, at 10:43 AM, Greg D. <gregd2350 at gmail.com> wrote:
> 
> Thanks, Mark, for posting the update.  
> 
> However, the point is that someone buying a new OVMS and Roadster OVT1 cable cannot use the obd2ecu feature of the module without performing some sort of hardware modification, and this potentially to a molded / sealed cable.  While this isn't a mass-market device, we really should make the out-of-the-box experience one of not killing one's car.  
> 
> How do we make this "Layman safe" out-of-the-box, and configurable for all supported cars without the use of a soldering iron or wire snips?  Is there a table of what CAN busses are used for each of the supported vehicles?
> 
> For the Roadster, at least, it would seem that we need to change the OVMS to OBDII pigtail to use CAN2, as well as disconnecting CAN2 from the OVT1 cable.  CAN2 is the only one left with out planned functionality, right?  The new cables would need a label on the OBDII cable indicating clearly what it needs to be paired with and what CAN bus it be used for.  Alternatively,. would it be possible to add a jumper block somewhere, so that a safe pre-install configuration can be done?
> 
> Should I deny allowing obd2ecu to be configured on CAN1?  Are there any cars or applications where this would be valid?
> 
> The obd2ecu task is fixed at 500kbps because that's what all of the HUD-type devices seem to use.  Adding a rate parameter should be easy, but I don't see it as solving anything.  From the devices I tested, there is no "negotiation" on CAN bus rate; or much of anything else for that matter.  They just turn on and start talking.  The only flexibility that I observed was whether they use base or extended frame formats, and I support both dynamically.  Or, are they also sensitive (self-configuring) to the bus speed, and if so, how is that done?  I suppose matching the 125k speed on CAN3 might work, but I'd really (REALLY) not want to put some random 3rd party active polling device on my car's ESS bus.  The two worlds need to be firewalled from each other, and that's the job of OVMS in this case.
> 
> All this said, there are still two puzzles in my mind.  First, why did starting obd2ecu on CAN3 cause the observed behavior?  The obd2ecu task is silent unless and until it receives a valid polling frame from the device, which should be impossible given the speed mismatch.  How can changing the bit rate on one CAN device affect the rest of the bus, if that device is otherwise silent?
> 
> Second, the OP in the TMC thread stated that they were using a pre-OVT1 cable.  If so, CAN 2 & 3 shouldn't have been connected, so there should have not been any possible interaction with either bus in the car.  Something is not adding up here...  Or, did some prior version of the cable also connect to all three?
> 
> Greg
> 
> 
> Mark Webb-Johnson wrote:
>> Greg,
>> 
>> I updated the TMC thread as follows:
>> 
>> 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.
>> 
>> This is always going to be vehicle specific, and probably best addressed by adding Tesla Roadster specific documentation. It would be useful to be able to confiture the baud rate of the bus in the obd2ecu code (but we are limited by what baud rates the HUDs will support during their negotiation).
>> 
>> Regards, Mark.
>> 
>>> On 4 Aug 2020, at 1:29 AM, Greg D. <gregd2350 at gmail.com <mailto:gregd2350 at gmail.com>> wrote:
>>> 
>>> Hi Mark,
>>> 
>>> So, following the "OVMS issue: obdii on can3 crashes VMS" thread on TMC
>>> led me to an "oops!", I think...  Did I miss something?
>>> 
>>> With the updated OVMS cable to the Diag port on the Roadster, the report
>>> is that all 3 CAN busses are connected to the car.  If so, doesn't that
>>> make the obd2ecu process impossible to run, since there's no CAN bus
>>> available on the 26 pin port to connect a HUD to?  And, if one were to
>>> hook up a HUD to the 26 pin port, wouldn't its polls be sent on (at 500
>>> kb/s) through the OVMS wiring to the car, confusing the car?
>>> 
>>> Is the older (single CAN bus) cable still available?  That, I would
>>> think, would fix the problem.  I have the original cable, so haven't
>>> noticed anything wrong.  The OP on that thread also claimed the original
>>> cable, which doesn't make sense.
>>> 
>>> Where is the Oops?
>>> 
>>> Greg
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200804/d5905d5e/attachment.htm>