[Ovmsdev] OVMS v3.3 hardware

Tue Dec 14 00:28:17 HKT 2021

We subscribe to two NMEA sentences, which are sent once per second by 
the modem. I'm not aware of a command to control the update frequency, 
but once per second should be fine.

Example:

D (828673) gsm-nmea: Incoming GNS: 
$GNGNS,161731.0,5118.140633,N,00723.395401,E,AA,06,2.2,325.9,47.0,,*61
D (828673) gsm-nmea: Incoming RMC: 
$GPRMC,161731.0,A,5118.140633,N,00723.395401,E,0.0,,131221,,,A*43
D (829673) gsm-nmea: Incoming GNS: 
$GNGNS,161732.0,5118.140632,N,00723.395397,E,AA,06,2.2,325.9,47.0,,*6B
D (829673) gsm-nmea: Incoming RMC: 
$GPRMC,161732.0,A,5118.140632,N,00723.395397,E,0.0,,131221,,,A*49
D (830673) gsm-nmea: Incoming GNS: 
$GNGNS,161733.0,5118.140629,N,00723.395389,E,AA,06,2.2,325.9,47.0,,*6F
D (830673) gsm-nmea: Incoming RMC: 
$GPRMC,161733.0,A,5118.140629,N,00723.395389,E,0.0,,131221,,,A*4D

When just trying to fetch these examples from a fresh boot of my desk 
module, I also seem to have found a strange behaviour, the MUX driver 
lost the modem without any error being recorded:

I (42283) cellular: Set modem driver to 'SIM5360'
I (42283) cellular: State: Enter PoweredOn state
D (44323) cellular: mux-rx-line #0: +CPIN: READY
D (44323) cellular: mux-rx-line #0: OPL UPDATING
D (44323) cellular: mux-rx-line #0: PNN UPDATING
D (44923) cellular: mux-rx-line #0: SMS DONE
D (45503) cellular: mux-rx-line #0: CALL READY
D (45503) cellular: mux-rx-line #0: PB DONE
D (52273) cellular: tx-cmd: 
AT+CPIN?;+CREG=1;+CTZU=1;+CTZR=1;+CLIP=1;+CMGF=1;+CNMI=1,2,0,0,0;+CSDH=1;+CMEE=2;+CSQ;+AUTOCSQ=1,1;E0;S0=0
D (54273) cellular: tx-cmd: AT+CGMR;+ICCID
D (58273) cellular: tx-cmd: AT+CMUXSRVPORT=3,1
D (58283) cellular: mux-rx-line #0: START
D (58283) cellular: mux-rx-line #0: AT+CMUXSRVPORT=3,1
D (59273) cellular: tx-cmd: AT+CMUXSRVPORT=2,1
D (59283) cellular: mux-rx-line #0: AT+CMUXSRVPORT=2,1
D (60273) cellular: tx-cmd: AT+CMUXSRVPORT=1,1
D (60283) cellular: mux-rx-line #0: AT+CMUXSRVPORT=1,1
D (61273) cellular: tx-cmd: AT+CMUXSRVPORT=0,5
D (61283) cellular: mux-rx-line #0: AT+CMUXSRVPORT=0,5
D (61303) cellular: mux-rx-line #0: +CPIN: READY
D (61303) cellular: mux-rx-line #0: OPL UPDATING
D (61303) cellular: mux-rx-line #0: PNN UPDATING
D (61553) ovms-duktape: Duktape: Compacting DukTape memory done in 100 ms
D (61893) cellular: mux-rx-line #0: SMS DONE
D (62273) cellular: tx-cmd: AT+CMUX=0
D (62283) cellular: mux-rx-line #0: AT+CMUX=0
I (62283) cellular: State: Enter MuxStart state
D (62473) cellular: mux-rx-line #2: CALL READY
D (62473) cellular: mux-rx-line #3: CALL READY
D (62473) cellular: mux-rx-line #4: CALL READY
D (62473) cellular: mux-rx-line #2: PB DONE
D (62473) cellular: mux-rx-line #3: PB DONE
D (62473) cellular: mux-rx-line #4: PB DONE
D (63273) cellular: State transition MuxStart => NetWait
I (63273) cellular: State: Enter NetWait state
I (63273) gsm-nmea: Startup
D (63273) cellular: mux-tx #4: AT+CGPSNMEA=66;+CGPS=1,1
D (63283) cellular: mux-rx-line #4: AT+CGPSNMEA=66;+CGPS=1,1
D (65013) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53
D (65013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53
D (66013) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53
D (66013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53
D (67013) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53
D (67013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53
D (68003) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53
D (68013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53
D (69003) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53
D (69013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53
D (73273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?
D (83273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?
D (93273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?
D (103273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?
D (113273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?
D (121543) ovms-duktape: Duktape: Compacting DukTape memory done in 90 ms
D (123273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?
D (133273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?
D (143273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?
OVMS# cell stat deb
MODEM Status
   Model: SIM5360
   Network Registration: Unknown
     Provider:
     Signal: 0 dBm
     Mode:
   State: NetWait
     Ticker: 80
     User Data: 0
   UART:
     FIFO overflows: 0
     Buffer overflows: 0
     Parity errors: 0
     Frame errors: 0
     Driver Buffer overflows: 0
   Mux: Status up
     Open Channels: 4
     Framing Errors: 0
     RX frames: 23
     TX frames: 14
     Last RX frame: 75 sec(s) ago
   PPP: Not running
   GPS: Connected on channel: #1
      Status: enabled
      Time: enabled
D (153273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?
D (163273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?
D (173273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?

Regards,
Michael

Am 13.12.21 um 09:09 schrieb Mark Webb-Johnson:
> 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 at expeedo.de 
>> <mailto:dexter at 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 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
>>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
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/ab7b8282/attachment-0001.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/ab7b8282/attachment-0001.sig>