<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Mark,<br>
<br>
Sure, the outward appearance in the car is worse than the actual
impact, but based on my own experience I'm still concerned about
Tesla's possible reaction. In my case they were specifically told
that there cannot be any relation between the OVMS and an 1144
alert, yet in my most recent communication with them about fixing
the fried fan connector pins they still held it up as an excuse for
not offering up any sort of warranty on their work. I suppose one
cannot prevent this sort of behavior, but keeping the busses
separate could be important if things "get serious". And, in the
case of the Roadster's CAN 2 & 3, those can have significantly
more serious implications on the car's operation. We don't know how
well Tesla protected the car's operation against random traffic. <br>
<br>
Thanks for the reference to the P10 HUD. I suppose that might set a
precedent, though a weak one. At best, it might set an expectation
that, as a class, vehicle accessories may need to be configured for
proper use, and that might include the adjustment of wiring.<br>
<br>
I'll take a look at the documentation and contribute improvements to
the obd2ecu section related to this. Is there a wiring diagram
handy for the Diag connector? I will need to reference the proper
wires (color?) / pins. Do you prefer a customer cuts the wires, or
removes the pins from the connector (if that's even possible without
a special tool)?<br>
<br>
Thanks,<br>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BBE75E3B-66B7-4E1F-9810-DCD9DBAE366E@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Greg,
<div class=""><br class="">
</div>
<div class="">The OP's alarmist title of ‘VMS crashing’ is not
accurate. What happens is the VDS shows a bunch of error
messages, which stop after the OVMS is unplugged or obd2ecu
turned off. Nothing damaged. Nothing crashed.</div>
<div class=""><br class="">
</div>
<div class="">Here is a comparable section from the common P10
HUD:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class=""><a
href="http://www.vjoychina.com/wp-content/uploads/2019/01/P10-OBD-Hud-User-Manual.docx"
class="" moz-do-not-send="true">http://www.vjoychina.com/wp-content/uploads/2019/01/P10-OBD-Hud-User-Manual.docx</a></div>
<div class=""><br class="">
</div>
<div class=""><b class="">10. Why it will cause the
car dashboard fault code bright?</b><br class="">
<br class="">
As Universal OBD device supports multiple communication modes,
and generally each car only supports one kind of
the communication protocol ,according to the protocol to pull
up the unneeded pins by the pliers.(when the vehicle turns on,
unplug and OBD cable and re-plug again,it will display the
protocol).</div>
<div class=""><br class="">
</div>
<div class="">(1) Communication protocol ISO15765 CAN Bus,keep
the 4/5/6/14/16 pins,and pull up the other pins,as the
below picture</div>
<div class=""><br class="">
</div>
<div class="">(2) Communication protocol ISO14230 KWP2000,keep
the 4/5/7/16 pins,and pull up the other pins,as the
below picture</div>
<div class=""><br class="">
</div>
<div class="">(3) Communication protocol ISO 9141-2,keep
the 4/5/7/15/16 pins,and pull up the other pins,as the
below picture</div>
</blockquote>
<div class="">
<div><br class="">
</div>
<div>Yes, they are saying the HUD may mess up the car’s
communications buses, and cause faults to appear on the
dashboard. Solution is to pull out pins from the cable. 😱</div>
<div><br class="">
</div>
<div>I’m definitely not saying it is good. Just that it is not
trivial to make this bulletproof. Especially with a limited
number of CAN buses. Setting vehicle type incorrectly will
cause the same sort of problem.</div>
<div><br class="">
</div>
<div>We can detect these issues in firmware, if we want to be
pedantic and slow down start up time. The solution would be to
put the bus in listen mode and listen for traffic for a while
(counting good frames vs errors) - only switch to active mode
if the comms are clean (so we are confident the baud rate is
correct). That is certainly possible, but quite some work to
get right.</div>
<div><br class="">
</div>
<div>The documentation for Tesla Roadster is in:</div>
<div><br class="">
</div>
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class="">
<div>components/vehicle_teslaroadster/docs/index.rst</div>
</div>
</blockquote>
<div class="">
<div><br class="">
</div>
<div>That is where I added the documentation for the recent TPMS
addition. I think we could add a section there for OBD2ECU,
and the OVT1 cable.</div>
<div><br class="">
</div>
<div>The speed parameter would be sensible to have, defaulting
to the current 500Kbps, as it gives us some flexibility.</div>
<div><br class="">
</div>
<div>Regards, Mark</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 5 Aug 2020, at 2:13 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="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> Hi Mark,<br
class="">
<br class="">
Of course. I'm under no illusion that the obd2ecu
feature would be a high-volume product. I'm just
concerned about how Tesla, in particular, or any
manufacturer in general, will react to a product that
interacts in a demonstrated negative way with the
vehicle's operation. We already have Tesla telling
their service centers that OVMS is potentially the cause
of my 1144 / 1146 alerts, for example. If they start
seeing this sort of behavior (VMS crashing), the fallout
could be severe, where they could refuse all service on
the vehicle. In my opinion, OVMS must provide a strict
firewall between the car and anything we attach to it,
and by feeding the other two CAN buses through from one
connector to the other, we've removed all protection.
The result was spectacularly not good.<br class="">
<br class="">
I guess "snip snip" will probably work, if it's well
documented. If the answer is documentation, how do we
get the word out? Two options; kill CAN 3 to the car
and lose the future ESS metrics, but leave the OBDII
pigtail as-is; probably the 90% solution. Or kill CAN2
to the car and make a custom OBDII pigtail. But I would
strongly urge anyone using the obd2ecu feature to fully
isolate the attached device from the car's buses, even
if they seem to be getting along.<br class="">
<br class="">
I'm Ok on the speed parameter. I wasn't seeing any
speed negotiation in my testing, but I also have a
fairly small sample of devices here. It will take me
some time to re-create the build environment here, as I
haven't been keeping it up to date. Right now I'm
trying to get my car back on the road (failed PEM Fan
connector). Parts for the next steps arrive today. <br
class="">
<br class="">
Greg<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br
class="">
</div>
<blockquote type="cite"
cite="mid:65F496DD-232F-4AF9-BF02-C83EE568A503@webb-johnson.net"
class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
Greg,
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">How
do we make this "Layman safe" out-of-the-box</div>
</blockquote>
<br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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).</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">Should
I deny allowing obd2ecu to be configured on
CAN1?</div>
</blockquote>
<br class="">
</div>
<div class="">I don’t see any advantage to crippling
that functionality. There may be cases where that is
the best approach.</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">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.</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">The reason I suggested adding the rate
parameter is it gives us some flexibility, and takes
nothing away (assuming it defaults to 500Kbps).</div>
<div class=""><br class="">
</div>
<div class="">This article explains this quite well: <a
href="https://copperhilltech.com/blog/how-can-bus-automatic-baudrate-detection-works-and-what-to-consider-when-connecting-to-a-network/"
class="" moz-do-not-send="true">https://copperhilltech.com/blog/how-can-bus-automatic-baudrate-detection-works-and-what-to-consider-when-connecting-to-a-network/</a></div>
<div class=""><br class="">
</div>
<div class="">See page #25 on this ELM327 spec for
their approach of auto-baud rate detection: <a
href="https://cdn.sparkfun.com/assets/learn_tutorials/8/3/ELM327DS.pdf"
class="" moz-do-not-send="true">https://cdn.sparkfun.com/assets/learn_tutorials/8/3/ELM327DS.pdf</a></div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> First,
why did starting obd2ecu on CAN3 cause the
observed behavior?</div>
</blockquote>
<div class=""><br class="">
</div>
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.</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">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?</div>
</blockquote>
<div class=""><br class="">
</div>
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.</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">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</div>
</blockquote>
<div class=""><br class="">
</div>
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.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 4 Aug 2020, at 10:43 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="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Thanks, Mark, for posting the update. <br
class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
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
class="">
<br class="">
Should I deny allowing obd2ecu to be
configured on CAN1? Are there any cars or
applications where this would be valid?<br
class="">
<br class="">
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
class="">
<br class="">
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
class="">
<br class="">
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 class="">
<br class="">
Greg<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Mark
Webb-Johnson wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:7B172510-6D65-4111-B9A5-4138C2233163@webb-johnson.net"
class="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8"
class="">
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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><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"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
</div>
_______________________________________________<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"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
</div>
_______________________________________________<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>
</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>