<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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="">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="">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">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 wrap="" class="">_______________________________________________
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 class="">
  </div>

_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>