<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Ha, I thought 100k was a typo for 1000, sorry...  Yeah, high speed
    overflow shouldn't be an issue.  On the other hand, low speed means
    that the time to receive a frame increases 10x, so that opens up a
    larger window if the chip doesn't like being talked to when actively
    receiving a frame.  Perhaps there is some interaction between the
    two sides of the chip?  For example, are there any registers that
    pertain to both busses?  I only use CAN3, with nothing connected to
    CAN2.<br>
    <br>
    Greg<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Geir Øyvind Vælidalo wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0BD0279E-952D-46D0-BDAF-21A24250CEC6@validalo.net">Thanks
      Greg. This can-bus is only 100kbit and uses less than 10% of the
      available capacity. It is a low speed, low traffic bus. And
      currently I don’t do any transmitting on it. 
      <div class=""><br class="">
      </div>
      <div class="">I don’t see why it shouldn’t work for me, then.</div>
      <div class=""><br class="">
      </div>
      <div class="">Geir<br class="">
        <div><br class="">
          <blockquote type="cite" class="">
            <div class="">30. des. 2017 kl. 19:07 skrev Greg D. <<a
                href="mailto:gregd2350@gmail.com" class=""
                moz-do-not-send="true">gregd2350@gmail.com</a>>:</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=""> For what
                it's worth, I've been using CAN3 for a long time with no
                lockups, running the OBDII ECU code.  What is different,
                perhaps, is that all the interactions are at 500k speed
                (vs 1000), and generally alternate one frame receive,
                followed by one frame transmit.  So, overflow should
                never occur unless the OBD2ECU code stops, at which
                point I probably didn't care.  Standard vs extended has
                not been a factor, in case that's a question.<br
                  class="">
                <br class="">
                The only issue we had was that if you try to transmit
                several frames back-to-back, the third and subsequent
                frame sent were all duplicates of the second frame. 
                That was fixed by adding a delay in the code, hoping
                that it would be sufficient for the prior frame to
                actually get sent.  Seems to work, though those frames
                are typically only sent at startup (request of VIN or
                ECU Name), not hammered on.<br class="">
                <br class="">
                Greg</div>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>