I don’t have GPS in any of my cars. I can try to enable on my bench.

Are we requesting GPS/GNSS updates from the modem too fast? I recollect that there is an AT command to set the frequency of updates.

@Craig do you have GPS/GNSS enabled on yours?

Regards, Mark.

On 13 Dec 2021, at 3:56 PM, Michael Balzer <dexter@expeedo.de> wrote:

Signed PGP part
To add another data point here: my production module (running 3.3.001-8-gf98d941c)

OVMS# boot
Last boot was 1093166 second(s) ago
Time at boot: 2021-11-30 17:07:33 CET

OVMS# cell status deb
MODEM Status
  Model: SIM5360
  Network Registration: RegisteredHome
    Provider: congstar
    Signal: -85 dBm
    Mode: GSM,Online
  State: NetMode
    Ticker: 20096
    User Data: 0
  UART:
    FIFO overflows: 3277
    Buffer overflows: 0
    Parity errors: 0
    Frame errors: 0
    Driver Buffer overflows: 0
  Mux: Status up
    Open Channels: 4
    Framing Errors: 1713
    RX frames: 1181428
    TX frames: 21380
    Last RX frame: 1 sec(s) ago
  PPP: Connected on channel: #2
  GPS: Connected on channel: #1
     Status: enabled
     Time: enabled


Mark, maybe you can reproduce the effect by enabling the modem GPS.

Regards,
Michael


Am 13.12.21 um 08:19 schrieb Mark Webb-Johnson:
Craig,

I can see some improvements:

  1. 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.

  2. 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.

    Perhaps the problem is in the async driver? Better to reset that as well?

  3. 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.

  4. I wonder why you are getting HW FIFO overflows? I am not seeing these.

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.

Regards, Mark.



On 12 Dec 2021, at 6:10 AM, Craig Leres <leres@xse.com> wrote:

I've made a tiny bit of progress with my sim7600a ppp issue.

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.

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.

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?

I was reviewing this thread and found this:

On 9/6/21 23:28, Michael Balzer wrote:
>
> I also added counters for these, you can query them with the "simcom
> status debug" command:
>
>> OVMS# sim stat deb
>> Network Registration: RegisteredHome
>> Provider: congstar
>> Signal: -97 dBm
>>
>> State: NetMode
>>   Ticker: 73099
>>   User Data: 0
>> ***  HW FIFO overflows: 21*
>>   Buffer overflows: 0
>>
>>   Mux
>>     Status: up
>>     Open Channels: 4
>> ***    Framing Errors: 24*
>>     Last RX frame: 1 sec(s) ago
>>     RX frames: 151452
>>     TX frames: 5472
>>
>> PPP: Connected on channel: #2
>>
>> GPS: Connected on channel: #1
>>      Status: enabled

Indeed I see one fifo overflow on my dev (which has lots ppp one time since boot):

   OVMS# cell status debug
   MODEM Status
     Model: SIM7600
     Network Registration: RegisteredRoaming
       Provider: AT&T Hologram
       Signal: -83 dBm
       Mode: LTE,Online
     State: NetMode
       Ticker: 1434
       User Data: 0
     UART:
       FIFO overflows: 1
       Buffer overflows: 0
       Parity errors: 0
       Frame errors: 0
       Driver Buffer overflows: 0
     Mux: Status up
       Open Channels: 4
       Framing Errors: 0
       RX frames: 1864
       TX frames: 78
       Last RX frame: 0 sec(s) ago
     PPP: Connected on channel: #2
     GPS: Connected on channel: #1
        Status: enabled
        Time: enabled

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.

On 9/6/21 18:35, Mark Webb-Johnson wrote:
>> Is it too soon to add the v3.3 and v1.3 pdfs to the source tree?)
>
> Yes, we haven’t finalised those, or gone through certification yet.
> We’ll release the v3.3 main board and modem layouts and schematics when
> that is complete (probably November/December timeframe).

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?)

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?

Craig





-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26