<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Thanks, Mark, for posting the update. <br>
<br>
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. <br>
<br>
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?<br>
<br>
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?<br>
<br>
Should I deny allowing obd2ecu to be configured on CAN1? Are there
any cars or applications where this would be valid?<br>
<br>
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.<br>
<br>
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?<br>
<br>
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?<br>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7B172510-6D65-4111-B9A5-4138C2233163@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Greg,
<div class=""><br class="">
</div>
<div class="">I updated the TMC thread as follows:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class=""><span style="color: rgb(2, 2, 2); font-family:
Roboto, sans-serif; font-variant-ligatures: normal; orphans:
2; widows: 2; background-color: rgb(254, 254, 254);"
class="">Here are the Tesla Roadster CAN bus details:</span><br
style="color: rgb(2, 2, 2); font-family: Roboto, sans-serif;
font-variant-ligatures: normal; orphans: 2; widows: 2;
background-color: rgb(254, 254, 254);" class="">
<ul style="margin: 1em 0px 1em 3em; padding: 0px; color:
rgb(2, 2, 2); font-family: Roboto, sans-serif;
font-variant-ligatures: normal; orphans: 2; widows: 2;
background-color: rgb(254, 254, 254);" class="">
<li style="margin: 0px; padding: 0px; list-style: outside
disc;" class="">Instrumentation: OVMS CAN1 (on OVT1):
1MHz, on DIAG pins 6/1. Contains VDS, TPMS,
Instrumentation Display.</li>
<li style="margin: 0px; padding: 0px; list-style: outside
disc;" class="">Powertrain: OVMS CAN2 (on OVT1): 500Kbps,
on DIAG pins 7/2. Contains PEM, Switchpack, etc.</li>
<li style="margin: 0px; padding: 0px; list-style: outside
disc;" class="">ESS: OVMS CAN3 (on OVT1): 125Kbps, on DIAG
pins 11/4. Contains ESS and HVAC.</li>
</ul>
<span style="color: rgb(2, 2, 2); font-family: Roboto,
sans-serif; font-variant-ligatures: normal; orphans: 2;
widows: 2; background-color: rgb(254, 254, 254);" class="">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.</span><br style="color: rgb(2, 2, 2);
font-family: Roboto, sans-serif; font-variant-ligatures:
normal; orphans: 2; widows: 2; background-color: rgb(254,
254, 254);" class="">
<br style="color: rgb(2, 2, 2); font-family: Roboto,
sans-serif; font-variant-ligatures: normal; orphans: 2;
widows: 2; background-color: rgb(254, 254, 254);" class="">
<span style="color: rgb(2, 2, 2); font-family: Roboto,
sans-serif; font-variant-ligatures: normal; orphans: 2;
widows: 2; background-color: rgb(254, 254, 254);" class="">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.</span><br style="color: rgb(2, 2, 2);
font-family: Roboto, sans-serif; font-variant-ligatures:
normal; orphans: 2; widows: 2; background-color: rgb(254,
254, 254);" class="">
<br style="color: rgb(2, 2, 2); font-family: Roboto,
sans-serif; font-variant-ligatures: normal; orphans: 2;
widows: 2; background-color: rgb(254, 254, 254);" class="">
<span style="color: rgb(2, 2, 2); font-family: Roboto,
sans-serif; font-variant-ligatures: normal; orphans: 2;
widows: 2; background-color: rgb(254, 254, 254);" class="">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.</span></div>
</blockquote>
<div class="">
<div><br class="">
</div>
<div>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).</div>
<div><br class="">
</div>
<div>Regards, Mark.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 4 Aug 2020, at 1:29 AM, Greg D. <<a
href="mailto:gregd2350@gmail.com" class=""
moz-do-not-send="true">gregd2350@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hi Mark,<br class="">
<br class="">
So, following the "OVMS issue: obdii on can3 crashes
VMS" thread on TMC<br class="">
led me to an "oops!", I think... Did I miss something?<br
class="">
<br class="">
With the updated OVMS cable to the Diag port on the
Roadster, the report<br class="">
is that all 3 CAN busses are connected to the car. If
so, doesn't that<br class="">
make the obd2ecu process impossible to run, since
there's no CAN bus<br class="">
available on the 26 pin port to connect a HUD to? And,
if one were to<br class="">
hook up a HUD to the 26 pin port, wouldn't its polls be
sent on (at 500<br class="">
kb/s) through the OVMS wiring to the car, confusing the
car?<br class="">
<br class="">
Is the older (single CAN bus) cable still available?
That, I would<br class="">
think, would fix the problem. I have the original
cable, so haven't<br class="">
noticed anything wrong. The OP on that thread also
claimed the original<br class="">
cable, which doesn't make sense.<br class="">
<br class="">
Where is the Oops?<br class="">
<br class="">
Greg<br class="">
<br class="">
_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com" class=""
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</body>
</html>