[Ovmsdev] OVMS v3.3 hardware

Mon Dec 13 15:56:04 HKT 2021

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 at xse.com 
>> <mailto:leres at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20211213/296683e6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20211213/296683e6/attachment.sig>