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.
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@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev