<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
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.<br>
<br>
Example:<br>
<br>
<font face="monospace">D (828673) gsm-nmea: Incoming GNS:
$GNGNS,161731.0,5118.140633,N,00723.395401,E,AA,06,2.2,325.9,47.0,,*61<br>
D (828673) gsm-nmea: Incoming RMC:
$GPRMC,161731.0,A,5118.140633,N,00723.395401,E,0.0,,131221,,,A*43<br>
D (829673) gsm-nmea: Incoming GNS:
$GNGNS,161732.0,5118.140632,N,00723.395397,E,AA,06,2.2,325.9,47.0,,*6B<br>
D (829673) gsm-nmea: Incoming RMC:
$GPRMC,161732.0,A,5118.140632,N,00723.395397,E,0.0,,131221,,,A*49<br>
D (830673) gsm-nmea: Incoming GNS:
$GNGNS,161733.0,5118.140629,N,00723.395389,E,AA,06,2.2,325.9,47.0,,*6F<br>
D (830673) gsm-nmea: Incoming RMC:
$GPRMC,161733.0,A,5118.140629,N,00723.395389,E,0.0,,131221,,,A*4D<br>
</font><br>
<br>
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:<br>
<br>
<font face="monospace">I (42283) cellular: Set modem driver to
'SIM5360'<br>
I (42283) cellular: State: Enter PoweredOn state<br>
D (44323) cellular: mux-rx-line #0: +CPIN: READY<br>
D (44323) cellular: mux-rx-line #0: OPL UPDATING<br>
D (44323) cellular: mux-rx-line #0: PNN UPDATING<br>
D (44923) cellular: mux-rx-line #0: SMS DONE<br>
D (45503) cellular: mux-rx-line #0: CALL READY<br>
D (45503) cellular: mux-rx-line #0: PB DONE<br>
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<br>
D (54273) cellular: tx-cmd: AT+CGMR;+ICCID<br>
D (58273) cellular: tx-cmd: AT+CMUXSRVPORT=3,1<br>
D (58283) cellular: mux-rx-line #0: START<br>
D (58283) cellular: mux-rx-line #0: AT+CMUXSRVPORT=3,1<br>
D (59273) cellular: tx-cmd: AT+CMUXSRVPORT=2,1<br>
D (59283) cellular: mux-rx-line #0: AT+CMUXSRVPORT=2,1<br>
D (60273) cellular: tx-cmd: AT+CMUXSRVPORT=1,1<br>
D (60283) cellular: mux-rx-line #0: AT+CMUXSRVPORT=1,1<br>
D (61273) cellular: tx-cmd: AT+CMUXSRVPORT=0,5<br>
D (61283) cellular: mux-rx-line #0: AT+CMUXSRVPORT=0,5<br>
D (61303) cellular: mux-rx-line #0: +CPIN: READY<br>
D (61303) cellular: mux-rx-line #0: OPL UPDATING<br>
D (61303) cellular: mux-rx-line #0: PNN UPDATING<br>
D (61553) ovms-duktape: Duktape: Compacting DukTape memory done in
100 ms<br>
D (61893) cellular: mux-rx-line #0: SMS DONE<br>
D (62273) cellular: tx-cmd: AT+CMUX=0<br>
D (62283) cellular: mux-rx-line #0: AT+CMUX=0<br>
I (62283) cellular: State: Enter MuxStart state<br>
D (62473) cellular: mux-rx-line #2: CALL READY<br>
D (62473) cellular: mux-rx-line #3: CALL READY<br>
D (62473) cellular: mux-rx-line #4: CALL READY<br>
D (62473) cellular: mux-rx-line #2: PB DONE<br>
D (62473) cellular: mux-rx-line #3: PB DONE<br>
D (62473) cellular: mux-rx-line #4: PB DONE<br>
D (63273) cellular: State transition MuxStart => NetWait<br>
I (63273) cellular: State: Enter NetWait state<br>
I (63273) gsm-nmea: Startup<br>
D (63273) cellular: mux-tx #4: AT+CGPSNMEA=66;+CGPS=1,1<br>
D (63283) cellular: mux-rx-line #4: AT+CGPSNMEA=66;+CGPS=1,1<br>
D (65013) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53<br>
D (65013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53<br>
D (66013) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53<br>
D (66013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53<br>
D (67013) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53<br>
D (67013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53<br>
D (68003) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53<br>
D (68013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53<br>
D (69003) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53<br>
D (69013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53<br>
D (73273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?<br>
D (83273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?<br>
D (93273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?<br>
D (103273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?<br>
D (113273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?<br>
D (121543) ovms-duktape: Duktape: Compacting DukTape memory done
in 90 ms<br>
D (123273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?<br>
D (133273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?<br>
D (143273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?<br>
OVMS# cell stat deb<br>
MODEM Status<br>
Model: SIM5360<br>
Network Registration: Unknown<br>
Provider: <br>
Signal: 0 dBm<br>
Mode: <br>
State: NetWait<br>
Ticker: 80<br>
User Data: 0<br>
UART:<br>
FIFO overflows: 0<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: 0<br>
RX frames: 23<br>
TX frames: 14<br>
Last RX frame: 75 sec(s) ago<br>
PPP: Not running<br>
GPS: Connected on channel: #1<br>
Status: enabled<br>
Time: enabled<br>
D (153273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?<br>
D (163273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?<br>
D (173273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?</font><br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 13.12.21 um 09:09 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:67479076-6515-463B-BA5A-0B9FDB523047@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
I don’t have GPS in any of my cars. I can try to enable on my
bench.
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">@Craig do you have GPS/GNSS enabled on yours?</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 13 Dec 2021, at 3:56 PM, Michael Balzer
<<a href="mailto:dexter@expeedo.de" class=""
moz-do-not-send="true">dexter@expeedo.de</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="content-isolator__container">
<div class="protected-part">
<div class="protected-title">Signed PGP part</div>
<div class="protected-content">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div class=""> To add another data point here: my
production module (running 3.3.001-8-gf98d941c)<br
class="">
<br class="">
<font class="" face="monospace">OVMS# boot<br
class="">
Last boot was 1093166 second(s) ago<br class="">
Time at boot: 2021-11-30 17:07:33 CET<br
class="">
<br class="">
OVMS# cell status deb<br class="">
MODEM Status<br class="">
Model: SIM5360<br class="">
Network Registration: RegisteredHome<br
class="">
Provider: congstar<br class="">
Signal: -85 dBm<br class="">
Mode: GSM,Online<br class="">
State: NetMode<br class="">
Ticker: 20096<br class="">
User Data: 0<br class="">
UART:<br class="">
FIFO overflows: 3277<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: 1713<br class="">
RX frames: 1181428<br class="">
TX frames: 21380<br class="">
Last RX frame: 1 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="">
</font><br class="">
<br class="">
Mark, maybe you can reproduce the effect by
enabling the modem GPS.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 13.12.21 um 08:19
schrieb Mark Webb-Johnson:<br class="">
</div>
<blockquote type="cite"
cite="mid:9B388731-8746-4930-AA9F-CDC26A4E90FD@webb-johnson.net"
class="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8" class="">
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="">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="">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="">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 class=""><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 class="">
</div>
</blockquote>
<br class="">
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</div>
</div>
</div>
<br class="">
<iframe class="content-isolator__isolated-content"
sandbox="allow-scripts" scrolling="auto"
style="border:none;display:block;overflow:auto;"
data-src="data:text/html;charset=UTF-8;base64,PGlmcmFtZS1jb250ZW50IGRhdGEtaWZyYW1lLWhlaWdodD0idHJ1ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+T3Ztc0RldiBtYWlsaW5nIGxpc3Q8QlI+T3Ztc0RldkBsaXN0cy5vcGVudmVoaWNsZXMuY29tPEJSPmh0dHA6Ly9saXN0cy5vcGVudmVoaWNsZXMuY29tL21haWxtYW4vbGlzdGluZm8vb3Ztc2RldjxCUj48L2lmcmFtZS1jb250ZW50Pg=="
width="200" height="10"></iframe></div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</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>