<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=""><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="">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 class=""></div></body></html>