<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    To add another data point here: my production module (running
    3.3.001-8-gf98d941c)<br>
    <br>
    <font face="monospace">OVMS# boot<br>
      Last boot was 1093166 second(s) ago<br>
      Time at boot: 2021-11-30 17:07:33 CET<br>
      <br>
      OVMS# cell status deb<br>
      MODEM Status<br>
        Model: SIM5360<br>
        Network Registration: RegisteredHome<br>
          Provider: congstar<br>
          Signal: -85 dBm<br>
          Mode: GSM,Online<br>
        State: NetMode<br>
          Ticker: 20096<br>
          User Data: 0<br>
        UART:<br>
          FIFO overflows: 3277<br>
          Buffer overflows: 0<br>
          Parity errors: 0<br>
          Frame errors: 0<br>
          Driver Buffer overflows: 0<br>
        Mux: Status up<br>
          Open Channels: 4<br>
          Framing Errors: 1713<br>
          RX frames: 1181428<br>
          TX frames: 21380<br>
          Last RX frame: 1 sec(s) ago<br>
        PPP: Connected on channel: #2<br>
        GPS: Connected on channel: #1<br>
           Status: enabled<br>
           Time: enabled<br>
    </font><br>
    <br>
    Mark, maybe you can reproduce the effect by enabling the modem GPS.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 13.12.21 um 08:19 schrieb Mark
      Webb-Johnson:<br>
    </div>
    <blockquote type="cite"
      cite="mid:9B388731-8746-4930-AA9F-CDC26A4E90FD@webb-johnson.net">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      Craig,
      <div class=""><br class="">
      </div>
      <div class="">I can see some improvements:</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <ol class="MailOutline">
          <li class="">If we get a HW FIFO overflow in MUX mode, there
            is little point in continuing. Probably simplest to reset
            the modem at that point.<br class="">
            <br class="">
          </li>
          <li class=""><font class="" color="#000000">At the moment, we
              pickup on various failures (like no MUX traffic, unable to
              make cellular connection, etc) and reset the modem. But I
              too have seen cases where the cellular connection can’t be
              made, that only a module reset seems to fix.<br class="">
              <br class="">
              Perhaps the problem is in the async driver? Better to
              reset that as well?<br class="">
              <br class="">
            </font></li>
          <li class=""><font class="" color="#000000">Hardware flow
              control would be nice, but sadly we simply don’t have the
              GPIOs for it. We only have two free unused, and they are
              desperately needed for expansion modules. The MUX protocol
              does have a software flow control mechanism, but I am not
              sure if that would help.<br class="">
              <br class="">
            </font></li>
          <li class=""><font class="" color="#000000">I wonder why
              you are getting HW FIFO overflows? I am not seeing these.</font></li>
        </ol>
      </div>
      <div class=""><br class="">
      </div>
      <div class="">Attached are draft 3.3 schematics. I have one change
        outstanding on these (I want to re-label CAN as CAN1..CAN3,
        rather than the existing CAN0..CAN2, to better match the
        firmware labelling), and then will publish.</div>
      <div class=""><br class="">
      </div>
      <div class="">Regards, Mark.</div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
        <div><br class="">
          <blockquote type="cite" class="">
            <div class="">On 12 Dec 2021, at 6:10 AM, Craig Leres <<a
                href="mailto:leres@xse.com" class=""
                moz-do-not-send="true">leres@xse.com</a>> wrote:</div>
            <br class="Apple-interchange-newline">
            <div class="">
              <div class="">I've made a tiny bit of progress with my
                sim7600a ppp issue.<br class="">
                <br class="">
                First I realized that I could now run the master branch.
                The first test I did with my dev/7600 actually stayed
                connected to ppp for more than 14 hours... I went
                looking for differences in my for-v3.3 and master builds
                and discovered my for-v3.3 tree was still using wolfssl.
                So I thought I had found the problem until 12 hours
                later when the dev unit lost ppp again.<br class="">
                <br class="">
                I also see that it's possible to get ppp back up without
                rebooting by powering cell down (power cell off),
                waiting for that to complete, and then powering back up.<br
                  class="">
                <br class="">
                I went looking for additional things to log. I have
                cellular, cellular-modem-auto, and
                cellular-modem-factory set to verbose and gsm-mux and
                gsm-ppp set to debug. What else would be helpful?<br
                  class="">
                <br class="">
                I was reviewing this thread and found this:<br class="">
                <br class="">
                On 9/6/21 23:28, Michael Balzer wrote:<br class="">
                ><br class="">
                > I also added counters for these, you can query them
                with the "simcom<br class="">
                > status debug" command:<br class="">
                ><br class="">
                >> OVMS# sim stat deb<br class="">
                >> Network Registration: RegisteredHome<br
                  class="">
                >> Provider: congstar<br class="">
                >> Signal: -97 dBm<br class="">
                >><br class="">
                >> State: NetMode<br class="">
                >>   Ticker: 73099<br class="">
                >>   User Data: 0<br class="">
                >> ***  HW FIFO overflows: 21*<br class="">
                >>   Buffer overflows: 0<br class="">
                >><br class="">
                >>   Mux<br class="">
                >>     Status: up<br class="">
                >>     Open Channels: 4<br class="">
                >> ***    Framing Errors: 24*<br class="">
                >>     Last RX frame: 1 sec(s) ago<br class="">
                >>     RX frames: 151452<br class="">
                >>     TX frames: 5472<br class="">
                >><br class="">
                >> PPP: Connected on channel: #2<br class="">
                >><br class="">
                >> GPS: Connected on channel: #1<br class="">
                >>      Status: enabled<br class="">
                <br class="">
                Indeed I see one fifo overflow on my dev (which has lots
                ppp one time since boot):<br class="">
                <br class="">
                   OVMS# cell status debug<br class="">
                   MODEM Status<br class="">
                     Model: SIM7600<br class="">
                     Network Registration: RegisteredRoaming<br class="">
                       Provider: AT&T Hologram<br class="">
                       Signal: -83 dBm<br class="">
                       Mode: LTE,Online<br class="">
                     State: NetMode<br class="">
                       Ticker: 1434<br class="">
                       User Data: 0<br class="">
                     UART:<br class="">
                       FIFO overflows: 1<br class="">
                       Buffer overflows: 0<br class="">
                       Parity errors: 0<br class="">
                       Frame errors: 0<br class="">
                       Driver Buffer overflows: 0<br class="">
                     Mux: Status up<br class="">
                       Open Channels: 4<br class="">
                       Framing Errors: 0<br class="">
                       RX frames: 1864<br class="">
                       TX frames: 78<br class="">
                       Last RX frame: 0 sec(s) ago<br class="">
                     PPP: Connected on channel: #2<br class="">
                     GPS: Connected on channel: #1<br class="">
                        Status: enabled<br class="">
                        Time: enabled<br class="">
                <br class="">
                I'm not sure if modem::modem() gets called when you
                power down/up the modem so I don't know if
                m_err_uart_fifo_ovf has been zero'd since boot.<br
                  class="">
                <br class="">
                On 9/6/21 18:35, Mark Webb-Johnson wrote:<br class="">
                >> Is it too soon to add the v3.3 and v1.3 pdfs to
                the source tree?)<br class="">
                ><br class="">
                > Yes, we haven’t finalised those, or gone through
                certification yet.<br class="">
                > We’ll release the v3.3 main board and modem layouts
                and schematics when<br class="">
                > that is complete (probably November/December
                timeframe).<br class="">
                <br class="">
                I was thinking if I had the v3.3 modem schematic I could
                upgrade my boards to have uart hardware flow control.
                (I'm guessing if I had this I would not expect to see
                fifo overflows?)<br class="">
                <br class="">
                Would it be useful for me to setup a way for you (Mark)
                to connect to my dev unit and interact with it while it
                is in the failed state?<br class="">
                <br class="">
                <span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre">    </span>Craig<br
                  class="">
                <br class="">
                <br class="">
                <br class="">
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
  </body>
</html>