SIM7600 Registration Denied
I’ve been fighting a problem for the past few months with registration getting denied on T-Mobile in USA using Hologram and our new 4G SIM7600G modem. Without cellular connectivity at home, it hasn’t been easy to recreate this, but I found a solution: Finally, with a good high gain antenna on my external wall facing the nearest cellular tower a couple of km away, I can get cellular (and even GPS with the little black puck) connectivity. So back to the two issues we are having: The FPLMN blacklist in the modem lists a bunch of cellular networks we are blocked from connecting to (including the ones we need). There have been reports that the connection to hologram works and is maintained, but the OVMS never connects to the v2 server. To address #1, I have extended the “cellular cmd” command to try to capture the output from the modem. There is no simple way of knowing when the command has completed, so for the moment I just look at data returned from the modem on the command channel, and stop when it hasn’t changed for a second or so. That now works like this: OVMS# cellular cmd AT+CRSM=176,28539,0,0,12 +CRSM: 144,0,"FFFFFFFFFFFFFFFFFFFFFFFF" OK OVMS# cellular cmd ATI Manufacturer: SIMCOM INCORPORATED Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 SVN: 01 IMEI: (redacted) +GCAP: +CGSM OK If required, we can send a relatively simple command to clear the FPLMN blacklist. It seems to work well, but I still need to test it wider (especially over v2 protocol commands, where I think we might have a recursion problem). So on to issue #2 that has been much harder to find. Finally, working with Hologram, I discovered that the problem seems to be in our handling of CREG network registration messages. I found a module with this problem, and manually issuing commands I found: AT+CREG? Registration Denied AT+CGREG? Registration Denied AT+CEREG? Registered Roaming It seems that the E-UTRANS (some 4G LTE carriers) won’t show the registration status correctly in AT+CREG. I guess they are refusing GSM (3G) connections from us (aka ‘Registration Denied’) while allowing 4G LTE. But as we only use the AT+CREG status to know whether we are connected to the network, the result is we can’t detect the E-UTRANS LTE connection and think registration has been denied. Connected to Hologram, but no data (or v2 server) connection. I did some research, and can’t find a definitive answer to how best to do this (especially as we have both 3G and 4G options, still support 2G, and a lot seems to depend on the individual cellular carrier options). So I implemented it as best I could. I re-ordered the registration statuses to be in lowest priority order, then created m_netreg_d[3] to store the registration status for each of the three types. Finally, I changed it so that m_netreg reflects the highest registration status. That way if CREG says RegistrationDenied, and CEREG says RegisteredRoaming, I treat it as RegisteredRoaming. This seems to work (on my test bench at least), and I now plan to deploy for wider testing. Code is committed and built as 3.3.002-45-g42546636 on the main firmware site. I would gratefully appreciate feedback on this. Regards, Mark.
On 8/25/22 23:34, Mark Webb-Johnson wrote:
I’ve been fighting a problem for the past few months with registration getting denied on T-Mobile in USA using Hologram and our new 4G SIM7600G modem. Without cellular connectivity at home, it hasn’t been easy to recreate this, but I found a solution:
I've been seeing intermittent netreg errors lately; I've booted this version on a couple of my modules... Craig
Thanks. I think anyone in USA using Hologram on T-Mobile would benefit from this. I just worry I break something else. Regards, Mark.
On 26 Aug 2022, at 2:46 PM, Craig Leres <leres@xse.com> wrote:
On 8/25/22 23:34, Mark Webb-Johnson wrote:
I’ve been fighting a problem for the past few months with registration getting denied on T-Mobile in USA using Hologram and our new 4G SIM7600G modem. Without cellular connectivity at home, it hasn’t been easy to recreate this, but I found a solution:
I've been seeing intermittent netreg errors lately; I've booted this version on a couple of my modules...
Craig
From testing on my three modules here in Germany, looks good: Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (151128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (151158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-93,-1141,-864,14 D (151168) cellular: mux-rx-line #3: +CREG: 1,5 D (151168) cellular: mux-rx-line #3: +CGREG: 1,5 D (151168) cellular: mux-rx-line #3: +CEREG: 1,5 D (151168) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:13:51+08" D (151168) cellular: mux-rx-line #3: +CSQ: 13,99 D (151168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (143784) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (143804) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-66,0,41-41 D (143814) cellular: mux-rx-line #3: +CREG: 1,5 D (143814) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:24:20+08" D (143814) cellular: mux-rx-line #3: +CSQ: 23,99 D (143814) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",0 Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (9625359) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (9625389) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268999,268,EUTRAN-BAND8,3749,2,2,-112,-1042,-791,15 D (9625399) cellular: mux-rx-line #3: +CREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CGREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CEREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CCLK: "22/08/26,12:40:14+08" D (9625399) cellular: mux-rx-line #3: +CSQ: 15,99 D (9625399) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7 Regards, Michael Am 26.08.22 um 08:53 schrieb Mark Webb-Johnson:
Thanks.
I think anyone in USA using Hologram on T-Mobile would benefit from this. I just worry I break something else.
Regards, Mark.
On 26 Aug 2022, at 2:46 PM, Craig Leres <leres@xse.com> wrote:
On 8/25/22 23:34, Mark Webb-Johnson wrote:
I’ve been fighting a problem for the past few months with registration getting denied on T-Mobile in USA using Hologram and our new 4G SIM7600G modem. Without cellular connectivity at home, it hasn’t been easy to recreate this, but I found a solution: I've been seeing intermittent netreg errors lately; I've booted this version on a couple of my modules...
Craig
OvmsDev mailing list OvmsDev@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
I’ve made some further revisions. Now in latest edge -49 release. Grateful for feedback on this, please. Particularly with SIM5360 (which should be unaffected, but …). Regards, Mark.
On 26 Aug 2022, at 10:17 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part From testing on my three modules here in Germany, looks good:
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (151128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (151158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-93,-1141,-864,14 D (151168) cellular: mux-rx-line #3: +CREG: 1,5 D (151168) cellular: mux-rx-line #3: +CGREG: 1,5 D (151168) cellular: mux-rx-line #3: +CEREG: 1,5 D (151168) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:13:51+08" D (151168) cellular: mux-rx-line #3: +CSQ: 13,99 D (151168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7
Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (143784) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (143804) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-66,0,41-41 D (143814) cellular: mux-rx-line #3: +CREG: 1,5 D (143814) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:24:20+08" D (143814) cellular: mux-rx-line #3: +CSQ: 23,99 D (143814) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",0
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (9625359) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (9625389) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268999,268,EUTRAN-BAND8,3749,2,2,-112,-1042,-791,15 D (9625399) cellular: mux-rx-line #3: +CREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CGREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CEREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CCLK: "22/08/26,12:40:14+08" D (9625399) cellular: mux-rx-line #3: +CSQ: 15,99 D (9625399) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7
Regards, Michael
Am 26.08.22 um 08:53 schrieb Mark Webb-Johnson:
Thanks.
I think anyone in USA using Hologram on T-Mobile would benefit from this. I just worry I break something else.
Regards, Mark.
On 26 Aug 2022, at 2:46 PM, Craig Leres <leres@xse.com> wrote:
On 8/25/22 23:34, Mark Webb-Johnson wrote:
I’ve been fighting a problem for the past few months with registration getting denied on T-Mobile in USA using Hologram and our new 4G SIM7600G modem. Without cellular connectivity at home, it hasn’t been easy to recreate this, but I found a solution: I've been seeing intermittent netreg errors lately; I've booted this version on a couple of my modules...
Craig
OvmsDev mailing list OvmsDev@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
Looks good: Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (80128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (80158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,12829697,303,EUTRAN-BAND20,6300,3,3,-93,-969,-701,17 D (80168) cellular: mux-rx-line #3: +CREG: 1,5 D (80168) cellular: mux-rx-line #3: +CGREG: 1,5 D (80168) cellular: mux-rx-line #3: +CEREG: 1,5 D (80168) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:15:03+08" D (80168) cellular: mux-rx-line #3: +CSQ: 21,99 D (80168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (74307) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (74327) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-69,0,38-38 D (74337) cellular: mux-rx-line #3: +CREG: 1,5 D (74337) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:19:47+08" D (74337) cellular: mux-rx-line #3: +CSQ: 22,99 D (74337) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",0 Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (324279) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (324309) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268996,36,EUTRAN-BAND3,1444,3,3,-147,-1213,-889,8 D (324319) cellular: mux-rx-line #3: +CREG: 1,1 D (324319) cellular: mux-rx-line #3: +CGREG: 1,1 D (324319) cellular: mux-rx-line #3: +CEREG: 1,1 D (324319) cellular: mux-rx-line #3: +CCLK: "22/08/31,12:22:05+08" D (324319) cellular: mux-rx-line #3: +CSQ: 11,99 D (324319) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7 Regards, Michael Am 31.08.22 um 10:41 schrieb Mark Webb-Johnson:
I’ve made some further revisions. Now in latest edge -49 release.
Grateful for feedback on this, please. Particularly with SIM5360 (which should be unaffected, but …).
Regards, Mark.
On 26 Aug 2022, at 10:17 PM, Michael Balzer<dexter@expeedo.de> wrote:
Signed PGP part From testing on my three modules here in Germany, looks good:
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (151128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (151158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-93,-1141,-864,14 D (151168) cellular: mux-rx-line #3: +CREG: 1,5 D (151168) cellular: mux-rx-line #3: +CGREG: 1,5 D (151168) cellular: mux-rx-line #3: +CEREG: 1,5 D (151168) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:13:51+08" D (151168) cellular: mux-rx-line #3: +CSQ: 13,99 D (151168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7
Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (143784) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (143804) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-66,0,41-41 D (143814) cellular: mux-rx-line #3: +CREG: 1,5 D (143814) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:24:20+08" D (143814) cellular: mux-rx-line #3: +CSQ: 23,99 D (143814) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",0
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (9625359) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (9625389) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268999,268,EUTRAN-BAND8,3749,2,2,-112,-1042,-791,15 D (9625399) cellular: mux-rx-line #3: +CREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CGREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CEREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CCLK: "22/08/26,12:40:14+08" D (9625399) cellular: mux-rx-line #3: +CSQ: 15,99 D (9625399) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7
Regards, Michael
Am 26.08.22 um 08:53 schrieb Mark Webb-Johnson:
Thanks.
I think anyone in USA using Hologram on T-Mobile would benefit from this. I just worry I break something else.
Regards, Mark.
On 26 Aug 2022, at 2:46 PM, Craig Leres<leres@xse.com> wrote:
On 8/25/22 23:34, Mark Webb-Johnson wrote:
I’ve been fighting a problem for the past few months with registration getting denied on T-Mobile in USA using Hologram and our new 4G SIM7600G modem. Without cellular connectivity at home, it hasn’t been easy to recreate this, but I found a solution: I've been seeing intermittent netreg errors lately; I've booted this version on a couple of my modules...
Craig
OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
Sounds good. I think this is important enough to make a formal release so I will arrange that. I have made a 3.3.003, and released to EAP on api.openvehicles.com. We can target a main release for next week. Regards, Mark. P.S. I have a bunch of unrelated enhancements to CAN logging to commit, but those can wait.
On 31 Aug 2022, at 10:27 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part Looks good:
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (80128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (80158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,12829697,303,EUTRAN-BAND20,6300,3,3,-93,-969,-701,17 D (80168) cellular: mux-rx-line #3: +CREG: 1,5 D (80168) cellular: mux-rx-line #3: +CGREG: 1,5 D (80168) cellular: mux-rx-line #3: +CEREG: 1,5 D (80168) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:15:03+08" D (80168) cellular: mux-rx-line #3: +CSQ: 21,99 D (80168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7
Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (74307) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (74327) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-69,0,38-38 D (74337) cellular: mux-rx-line #3: +CREG: 1,5 D (74337) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:19:47+08" D (74337) cellular: mux-rx-line #3: +CSQ: 22,99 D (74337) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",0
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (324279) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (324309) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268996,36,EUTRAN-BAND3,1444,3,3,-147,-1213,-889,8 D (324319) cellular: mux-rx-line #3: +CREG: 1,1 D (324319) cellular: mux-rx-line #3: +CGREG: 1,1 D (324319) cellular: mux-rx-line #3: +CEREG: 1,1 D (324319) cellular: mux-rx-line #3: +CCLK: "22/08/31,12:22:05+08" D (324319) cellular: mux-rx-line #3: +CSQ: 11,99 D (324319) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7
Regards, Michael
Am 31.08.22 um 10:41 schrieb Mark Webb-Johnson:
I’ve made some further revisions. Now in latest edge -49 release.
Grateful for feedback on this, please. Particularly with SIM5360 (which should be unaffected, but …).
Regards, Mark.
On 26 Aug 2022, at 10:17 PM, Michael Balzer<dexter@expeedo.de> wrote:
Signed PGP part From testing on my three modules here in Germany, looks good:
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (151128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (151158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-93,-1141,-864,14 D (151168) cellular: mux-rx-line #3: +CREG: 1,5 D (151168) cellular: mux-rx-line #3: +CGREG: 1,5 D (151168) cellular: mux-rx-line #3: +CEREG: 1,5 D (151168) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:13:51+08" D (151168) cellular: mux-rx-line #3: +CSQ: 13,99 D (151168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7
Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (143784) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (143804) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-66,0,41-41 D (143814) cellular: mux-rx-line #3: +CREG: 1,5 D (143814) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:24:20+08" D (143814) cellular: mux-rx-line #3: +CSQ: 23,99 D (143814) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",0
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (9625359) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (9625389) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268999,268,EUTRAN-BAND8,3749,2,2,-112,-1042,-791,15 D (9625399) cellular: mux-rx-line #3: +CREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CGREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CEREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CCLK: "22/08/26,12:40:14+08" D (9625399) cellular: mux-rx-line #3: +CSQ: 15,99 D (9625399) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7
Regards, Michael
Am 26.08.22 um 08:53 schrieb Mark Webb-Johnson:
Thanks.
I think anyone in USA using Hologram on T-Mobile would benefit from this. I just worry I break something else.
Regards, Mark.
On 26 Aug 2022, at 2:46 PM, Craig Leres<leres@xse.com> wrote:
On 8/25/22 23:34, Mark Webb-Johnson wrote:
I’ve been fighting a problem for the past few months with registration getting denied on T-Mobile in USA using Hologram and our new 4G SIM7600G modem. Without cellular connectivity at home, it hasn’t been easy to recreate this, but I found a solution: I've been seeing intermittent netreg errors lately; I've booted this version on a couple of my modules...
Craig
OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
EAP release also done on ovms.dexters-web.de. Regards, Michael Am 01.09.22 um 02:53 schrieb Mark Webb-Johnson:
Sounds good. I think this is important enough to make a formal release so I will arrange that.
I have made a 3.3.003, and released to EAP on api.openvehicles.com <http://api.openvehicles.com>. We can target a main release for next week.
Regards, Mark.
P.S. I have a bunch of unrelated enhancements to CAN logging to commit, but those can wait.
On 31 Aug 2022, at 10:27 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part Looks good:
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (80128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (80158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,12829697,303,EUTRAN-BAND20,6300,3,3,-93,-969,-701,17 D (80168) cellular: mux-rx-line #3: +CREG: 1,5 D (80168) cellular: mux-rx-line #3: +CGREG: 1,5 D (80168) cellular: mux-rx-line #3: +CEREG: 1,5 D (80168) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:15:03+08" D (80168) cellular: mux-rx-line #3: +CSQ: 21,99 D (80168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de> Hologram",7
Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (74307) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (74327) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-69,0,38-38 D (74337) cellular: mux-rx-line #3: +CREG: 1,5 D (74337) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:19:47+08" D (74337) cellular: mux-rx-line #3: +CSQ: 22,99 D (74337) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de> Hologram",0
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (324279) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (324309) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268996,36,EUTRAN-BAND3,1444,3,3,-147,-1213,-889,8 D (324319) cellular: mux-rx-line #3: +CREG: 1,1 D (324319) cellular: mux-rx-line #3: +CGREG: 1,1 D (324319) cellular: mux-rx-line #3: +CEREG: 1,1 D (324319) cellular: mux-rx-line #3: +CCLK: "22/08/31,12:22:05+08" D (324319) cellular: mux-rx-line #3: +CSQ: 11,99 D (324319) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7
Regards, Michael
Am 31.08.22 um 10:41 schrieb Mark Webb-Johnson:
I’ve made some further revisions. Now in latest edge -49 release.
Grateful for feedback on this, please. Particularly with SIM5360 (which should be unaffected, but …).
Regards, Mark.
On 26 Aug 2022, at 10:17 PM, Michael Balzer<dexter@expeedo.de> wrote:
Signed PGP part From testing on my three modules here in Germany, looks good:
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (151128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (151158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-93,-1141,-864,14 D (151168) cellular: mux-rx-line #3: +CREG: 1,5 D (151168) cellular: mux-rx-line #3: +CGREG: 1,5 D (151168) cellular: mux-rx-line #3: +CEREG: 1,5 D (151168) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:13:51+08" D (151168) cellular: mux-rx-line #3: +CSQ: 13,99 D (151168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de> Hologram",7
Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (143784) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (143804) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-66,0,41-41 D (143814) cellular: mux-rx-line #3: +CREG: 1,5 D (143814) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:24:20+08" D (143814) cellular: mux-rx-line #3: +CSQ: 23,99 D (143814) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de> Hologram",0
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (9625359) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (9625389) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268999,268,EUTRAN-BAND8,3749,2,2,-112,-1042,-791,15 D (9625399) cellular: mux-rx-line #3: +CREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CGREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CEREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CCLK: "22/08/26,12:40:14+08" D (9625399) cellular: mux-rx-line #3: +CSQ: 15,99 D (9625399) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7
Regards, Michael
Am 26.08.22 um 08:53 schrieb Mark Webb-Johnson:
Thanks.
I think anyone in USA using Hologram on T-Mobile would benefit from this. I just worry I break something else.
Regards, Mark.
On 26 Aug 2022, at 2:46 PM, Craig Leres<leres@xse.com> wrote:
On 8/25/22 23:34, Mark Webb-Johnson wrote: > I’ve been fighting a problem for the past few months with > registration getting denied on T-Mobile in USA using Hologram > and our new 4G SIM7600G modem. Without cellular connectivity at > home, it hasn’t been easy to recreate this, but I found a solution: I've been seeing intermittent netreg errors lately; I've booted this version on a couple of my modules...
Craig
OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
I'm seeing an issue with the current build, but not sure if that's new & related to the latest changes or just coincidentally has become more severe somehow: On a cold boot, modem communication is mostly fine, nearly no UART frame errors, and messages received by the modem are fine. After the first warm reboot, initial modem messages are garbled, and lots of UART frame errors occur right from the beginning of modem communication. This looks like some part of the serial communication now doesn't get fully reset on a reboot. Log attached. Regards, Michael Am 03.09.22 um 11:37 schrieb Michael Balzer:
EAP release also done on ovms.dexters-web.de.
Regards, Michael
Am 01.09.22 um 02:53 schrieb Mark Webb-Johnson:
Sounds good. I think this is important enough to make a formal release so I will arrange that.
I have made a 3.3.003, and released to EAP on api.openvehicles.com <http://api.openvehicles.com>. We can target a main release for next week.
Regards, Mark.
P.S. I have a bunch of unrelated enhancements to CAN logging to commit, but those can wait.
On 31 Aug 2022, at 10:27 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part Looks good:
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (80128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (80158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,12829697,303,EUTRAN-BAND20,6300,3,3,-93,-969,-701,17 D (80168) cellular: mux-rx-line #3: +CREG: 1,5 D (80168) cellular: mux-rx-line #3: +CGREG: 1,5 D (80168) cellular: mux-rx-line #3: +CEREG: 1,5 D (80168) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:15:03+08" D (80168) cellular: mux-rx-line #3: +CSQ: 21,99 D (80168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de> Hologram",7
Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (74307) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (74327) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-69,0,38-38 D (74337) cellular: mux-rx-line #3: +CREG: 1,5 D (74337) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:19:47+08" D (74337) cellular: mux-rx-line #3: +CSQ: 22,99 D (74337) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de> Hologram",0
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (324279) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (324309) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268996,36,EUTRAN-BAND3,1444,3,3,-147,-1213,-889,8 D (324319) cellular: mux-rx-line #3: +CREG: 1,1 D (324319) cellular: mux-rx-line #3: +CGREG: 1,1 D (324319) cellular: mux-rx-line #3: +CEREG: 1,1 D (324319) cellular: mux-rx-line #3: +CCLK: "22/08/31,12:22:05+08" D (324319) cellular: mux-rx-line #3: +CSQ: 11,99 D (324319) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7
Regards, Michael
Am 31.08.22 um 10:41 schrieb Mark Webb-Johnson:
I’ve made some further revisions. Now in latest edge -49 release.
Grateful for feedback on this, please. Particularly with SIM5360 (which should be unaffected, but …).
Regards, Mark.
On 26 Aug 2022, at 10:17 PM, Michael Balzer<dexter@expeedo.de> wrote:
Signed PGP part From testing on my three modules here in Germany, looks good:
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (151128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (151158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-93,-1141,-864,14 D (151168) cellular: mux-rx-line #3: +CREG: 1,5 D (151168) cellular: mux-rx-line #3: +CGREG: 1,5 D (151168) cellular: mux-rx-line #3: +CEREG: 1,5 D (151168) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:13:51+08" D (151168) cellular: mux-rx-line #3: +CSQ: 13,99 D (151168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de> Hologram",7
Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (143784) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (143804) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-66,0,41-41 D (143814) cellular: mux-rx-line #3: +CREG: 1,5 D (143814) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:24:20+08" D (143814) cellular: mux-rx-line #3: +CSQ: 23,99 D (143814) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de> Hologram",0
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (9625359) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (9625389) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268999,268,EUTRAN-BAND8,3749,2,2,-112,-1042,-791,15 D (9625399) cellular: mux-rx-line #3: +CREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CGREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CEREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CCLK: "22/08/26,12:40:14+08" D (9625399) cellular: mux-rx-line #3: +CSQ: 15,99 D (9625399) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7
Regards, Michael
Am 26.08.22 um 08:53 schrieb Mark Webb-Johnson:
Thanks.
I think anyone in USA using Hologram on T-Mobile would benefit from this. I just worry I break something else.
Regards, Mark.
> On 26 Aug 2022, at 2:46 PM, Craig Leres<leres@xse.com> wrote: > > > On 8/25/22 23:34, Mark Webb-Johnson wrote: >> I’ve been fighting a problem for the past few months with >> registration getting denied on T-Mobile in USA using Hologram >> and our new 4G SIM7600G modem. Without cellular connectivity at >> home, it hasn’t been easy to recreate this, but I found a solution: > I've been seeing intermittent netreg errors lately; I've booted > this version on a couple of my modules... > > Craig _______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
Michael, I reviewed: $ git diff 2b25287fbef5fa968236cb8e556ea11da7c8f579 components/ovms_cellular components/simcom But can’t see anything really related to frame errors, other than the two extra CGREG and CEREG output lines once every thirty seconds. Maybe an existing issue re-occurring? Do you think this should block our release of 3.3.003 to ‘main’ release? Regards, Mark.
On 4 Sep 2022, at 4:17 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part I'm seeing an issue with the current build, but not sure if that's new & related to the latest changes or just coincidentally has become more severe somehow:
On a cold boot, modem communication is mostly fine, nearly no UART frame errors, and messages received by the modem are fine.
After the first warm reboot, initial modem messages are garbled, and lots of UART frame errors occur right from the beginning of modem communication.
This looks like some part of the serial communication now doesn't get fully reset on a reboot. Log attached.
Regards, Michael
Am 03.09.22 um 11:37 schrieb Michael Balzer:
EAP release also done on ovms.dexters-web.de.
Regards, Michael
Am 01.09.22 um 02:53 schrieb Mark Webb-Johnson:
Sounds good. I think this is important enough to make a formal release so I will arrange that.
I have made a 3.3.003, and released to EAP on api.openvehicles.com <http://api.openvehicles.com/>. We can target a main release for next week.
Regards, Mark.
P.S. I have a bunch of unrelated enhancements to CAN logging to commit, but those can wait.
On 31 Aug 2022, at 10:27 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Signed PGP part Looks good:
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (80128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (80158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,12829697,303,EUTRAN-BAND20,6300,3,3,-93,-969,-701,17 D (80168) cellular: mux-rx-line #3: +CREG: 1,5 D (80168) cellular: mux-rx-line #3: +CGREG: 1,5 D (80168) cellular: mux-rx-line #3: +CEREG: 1,5 D (80168) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:15:03+08" D (80168) cellular: mux-rx-line #3: +CSQ: 21,99 D (80168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de/> Hologram",7
Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (74307) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (74327) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-69,0,38-38 D (74337) cellular: mux-rx-line #3: +CREG: 1,5 D (74337) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:19:47+08" D (74337) cellular: mux-rx-line #3: +CSQ: 22,99 D (74337) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de/> Hologram",0
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (324279) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (324309) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268996,36,EUTRAN-BAND3,1444,3,3,-147,-1213,-889,8 D (324319) cellular: mux-rx-line #3: +CREG: 1,1 D (324319) cellular: mux-rx-line #3: +CGREG: 1,1 D (324319) cellular: mux-rx-line #3: +CEREG: 1,1 D (324319) cellular: mux-rx-line #3: +CCLK: "22/08/31,12:22:05+08" D (324319) cellular: mux-rx-line #3: +CSQ: 11,99 D (324319) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7
Regards, Michael
Am 31.08.22 um 10:41 schrieb Mark Webb-Johnson:
I’ve made some further revisions. Now in latest edge -49 release.
Grateful for feedback on this, please. Particularly with SIM5360 (which should be unaffected, but …).
Regards, Mark.
On 26 Aug 2022, at 10:17 PM, Michael Balzer<dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Signed PGP part From testing on my three modules here in Germany, looks good:
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (151128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (151158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-93,-1141,-864,14 D (151168) cellular: mux-rx-line #3: +CREG: 1,5 D (151168) cellular: mux-rx-line #3: +CGREG: 1,5 D (151168) cellular: mux-rx-line #3: +CEREG: 1,5 D (151168) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:13:51+08" D (151168) cellular: mux-rx-line #3: +CSQ: 13,99 D (151168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de/> Hologram",7
Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (143784) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (143804) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-66,0,41-41 D (143814) cellular: mux-rx-line #3: +CREG: 1,5 D (143814) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:24:20+08" D (143814) cellular: mux-rx-line #3: +CSQ: 23,99 D (143814) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de/> Hologram",0
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (9625359) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (9625389) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268999,268,EUTRAN-BAND8,3749,2,2,-112,-1042,-791,15 D (9625399) cellular: mux-rx-line #3: +CREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CGREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CEREG: 1,1 D (9625399) cellular: mux-rx-line #3: +CCLK: "22/08/26,12:40:14+08" D (9625399) cellular: mux-rx-line #3: +CSQ: 15,99 D (9625399) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7
Regards, Michael
Am 26.08.22 um 08:53 schrieb Mark Webb-Johnson: > Thanks. > > I think anyone in USA using Hologram on T-Mobile would benefit from this. I just worry I break something else. > > Regards, Mark. > >> On 26 Aug 2022, at 2:46 PM, Craig Leres<leres@xse.com <mailto:leres@xse.com>> wrote: >> >> >> On 8/25/22 23:34, Mark Webb-Johnson wrote: >>> I’ve been fighting a problem for the past few months with registration getting denied on T-Mobile in USA using Hologram and our new 4G SIM7600G modem. Without cellular connectivity at home, it hasn’t been easy to recreate this, but I found a solution: >> I've been seeing intermittent netreg errors lately; I've booted this version on a couple of my modules... >> >> Craig > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 <220904-UART-frame-errors.txt>
Mark, (am I the only one experiencing this?) I've had multiple times of temporarily frozen modem communication over the last days on my car module. That's new, so I think we should try to fix that before releasing. On my bench module there's a clear correlation between the extended status query and the frame errors. It's also not related to the NMEA messages, I've checked that, they come at another second. Log excerpts below. With frame errors responses also occasionally get corrupted, e.g. D (204251) cellular: mux-rx-line #3: Hologram",7 I think the extended status responses now very often cause an overflow on the RX buffer when coming in together. Solution could be to split the queries and distribute over 2-3 seconds. I don't know if that will also fix the strange cold/warm boot difference with this, but maybe that's simply because the modem is faster with getting back to the network after a reboot, so the status responses become large quickly. Regards, Michael D (204211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (204251) gsm-mux: Frame error: EOF mismatch (CHAN=55, ADDR=df, CTRL=ff, FCS=35, LEN=133) V (204251) gsm-mux: Frame dump: f9 df ff ff bf bf dd ff f9 0d ff af 0d 0a 2b 43 | ..............+C V (204251) gsm-mux: Frame dump: 50 53 49 3a 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c | PSI: LTE,Online, V (204251) gsm-mux: Frame dump: 32 36 32 2d 30 32 2c 30 78 42 30 46 35 2c 31 33 | 262-02,0xB0F5,13 V (204251) gsm-mux: Frame dump: 31 37 39 34 31 32 2c 34 34 38 2c 45 55 54 52 41 | 179412,448,EUTRA V (204251) gsm-mux: Frame dump: 4e 2d 42 41 4e 44 31 2c 31 30 30 2c 34 2c 34 2c | N-BAND1,100,4,4, V (204251) gsm-mux: Frame dump: 2d 39 32 2c 2d 31 31 35 32 2c 2d 38 37 35 2c 31 | -92,-1152,-875,1 V (204251) gsm-mux: Frame dump: 34 0d 0a 34 f9 f9 0d ff ed 0d 0a 2b 43 52 45 47 | 4..4.......+CREG V (204251) gsm-mux: Frame dump: 3a 20 31 2c 35 0d 0a 0d 0a 2b 43 47 52 45 47 3a | : 1,5....+CGREG: V (204251) gsm-mux: Frame dump: 20 31 2c 35 0d | 1,5. V (204251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (204251) cellular: mux-rx-line #3: Hologram",7 V (208231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (208241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (208251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (208251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (208271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) … V (233271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (233271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (234211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234231) gsm-mux: Frame error: EOF mismatch (CHAN=63, ADDR=ff, CTRL=ea, FCS=2c, LEN=53) V (234231) gsm-mux: Frame dump: f9 ff ea 5f ff b7 ff fd ff b9 df fd bf f9 ff fd | ..._............ V (234231) gsm-mux: Frame dump: fb ff f9 f9 a9 f9 0d ff af 0d 0a 2b 43 50 53 49 | ...........+CPSI V (234231) gsm-mux: Frame dump: 3a 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c 32 36 32 | : LTE,Online,262 V (234231) gsm-mux: Frame dump: 2d 30 32 2c 30 | -02,0 V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=a7, LEN=124) D (234241) cellular: mux-rx-line #3: +CREG: 1,5 D (234241) cellular: mux-rx-line #3: +CGREG: 1,5 D (234241) cellular: mux-rx-line #3: +CEREG: 1,5 D (234241) cellular: mux-rx-line #3: +CCLK: "22/09/09,12:52:41+08" D (234241) cellular: mux-rx-line #3: +CSQ: 13,99 V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (234251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 V (238231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (238241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) … V (293251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (293251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (293271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (293271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (294211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (294211) cellular: UART frame error W (294211) cellular: UART frame error W (294211) cellular: UART frame error W (294241) gsm-mux: Frame error: EOF mismatch (CHAN=59, ADDR=ef, CTRL=db, FCS=2b, LEN=117) V (294241) gsm-mux: Frame dump: f9 ef db df ef df f7 cb f9 ff ff db 7f fd ff ff | ................ V (294241) gsm-mux: Frame dump: f9 0d ff af 0d 0a 2b 43 50 53 49 3a 20 4c 54 45 | ......+CPSI: LTE V (294241) gsm-mux: Frame dump: 2c 4f 6e 6c 69 6e 65 2c 32 36 32 2d 30 32 2c 30 | ,Online,262-02,0 V (294241) gsm-mux: Frame dump: 78 42 30 46 35 2c 31 33 31 37 39 34 31 32 2c 34 | xB0F5,13179412,4 V (294241) gsm-mux: Frame dump: 34 38 2c 45 55 54 52 41 4e 2d 42 41 4e 44 31 2c | 48,EUTRAN-BAND1, V (294241) gsm-mux: Frame dump: 31 30 30 2c 34 2c 34 2c 2d 39 36 2c 2d 31 31 35 | 100,4,4,-96,-115 V (294241) gsm-mux: Frame dump: 35 2c 2d 38 37 33 2c 31 34 0d 0a 34 f9 f9 0d ff | 5,-873,14..4.... V (294241) gsm-mux: Frame dump: ed 0d 0a 2b 43 | ...+C V (294251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (294251) cellular: mux-rx-line #3: Hologram",7 V (298231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (298241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (298241) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (298251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (298261) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (298271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) … V (323251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (323261) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (323271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (323271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (324211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (324231) gsm-mux: Frame error: EOF mismatch (CHAN=29, ADDR=77, CTRL=fb, FCS=45, LEN=125) V (324231) gsm-mux: Frame dump: f9 77 fb ef 5f ff bb ed fb bb db ff b7 fb cf ff | .w.._........... V (324231) gsm-mux: Frame dump: bf d9 ff bb f9 0d ff b1 0d 0a 2b 43 50 53 49 3a | ..........+CPSI: V (324231) gsm-mux: Frame dump: 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c 32 36 32 2d | LTE,Online,262- V (324231) gsm-mux: Frame dump: 30 32 2c 30 78 42 30 46 35 2c 31 33 31 37 39 34 | 02,0xB0F5,131794 V (324231) gsm-mux: Frame dump: 31 32 2c 34 34 38 2c 45 55 54 52 41 4e 2d 42 41 | 12,448,EUTRAN-BA V (324241) gsm-mux: Frame dump: 4e 44 31 2c 31 30 30 2c 34 2c 34 2c 2d 31 30 39 | ND1,100,4,4,-109 V (324241) gsm-mux: Frame dump: 2c 2d 31 31 36 36 2c 2d 38 37 34 2c 31 31 0d 0a | ,-1166,-874,11.. V (324241) gsm-mux: Frame dump: c2 f9 f9 0d ff ed 0d 0a 2b 43 52 45 47 | ........+CREG V (324241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (324241) cellular: mux-rx-line #3: Hologram",7 V (328231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (328241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (328251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) … V (353251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (353251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (353271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (353271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (354211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (354211) cellular: UART frame error W (354211) cellular: UART frame error W (354211) cellular: UART frame error W (354211) cellular: UART frame error V (354231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=34, LEN=93) D (354231) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-122,-1184,-874,9 V (354241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=a7, LEN=124) D (354241) cellular: mux-rx-line #3: +CREG: 1,5 D (354241) cellular: mux-rx-line #3: +CGREG: 1,5 D (354241) cellular: mux-rx-line #3: +CEREG: 1,5 D (354241) cellular: mux-rx-line #3: +CCLK: "22/09/09,12:54:41+08" D (354251) cellular: mux-rx-line #3: +CSQ: 13,99 V (354251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (354251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 V (358231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (358241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (358251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) Am 08.09.22 um 07:15 schrieb Mark Webb-Johnson:
Michael,
I reviewed:
$ git diff 2b25287fbef5fa968236cb8e556ea11da7c8f579 components/ovms_cellular components/simcom
But can’t see anything really related to frame errors, other than the two extra CGREG and CEREG output lines once every thirty seconds.
Maybe an existing issue re-occurring?
Do you think this should block our release of 3.3.003 to ‘main’ release?
Regards, Mark.
On 4 Sep 2022, at 4:17 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part I'm seeing an issue with the current build, but not sure if that's new & related to the latest changes or just coincidentally has become more severe somehow:
On a cold boot, modem communication is mostly fine, nearly no UART frame errors, and messages received by the modem are fine.
After the first warm reboot, initial modem messages are garbled, and lots of UART frame errors occur right from the beginning of modem communication.
This looks like some part of the serial communication now doesn't get fully reset on a reboot. Log attached.
Regards, Michael
Am 03.09.22 um 11:37 schrieb Michael Balzer:
EAP release also done on ovms.dexters-web.de <http://ovms.dexters-web.de>.
Regards, Michael
Am 01.09.22 um 02:53 schrieb Mark Webb-Johnson:
Sounds good. I think this is important enough to make a formal release so I will arrange that.
I have made a 3.3.003, and released to EAP on api.openvehicles.com <http://api.openvehicles.com/>. We can target a main release for next week.
Regards, Mark.
P.S. I have a bunch of unrelated enhancements to CAN logging to commit, but those can wait.
On 31 Aug 2022, at 10:27 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part Looks good:
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (80128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (80158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,12829697,303,EUTRAN-BAND20,6300,3,3,-93,-969,-701,17 D (80168) cellular: mux-rx-line #3: +CREG: 1,5 D (80168) cellular: mux-rx-line #3: +CGREG: 1,5 D (80168) cellular: mux-rx-line #3: +CEREG: 1,5 D (80168) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:15:03+08" D (80168) cellular: mux-rx-line #3: +CSQ: 21,99 D (80168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de/> Hologram",7
Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (74307) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (74327) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-69,0,38-38 D (74337) cellular: mux-rx-line #3: +CREG: 1,5 D (74337) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:19:47+08" D (74337) cellular: mux-rx-line #3: +CSQ: 22,99 D (74337) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de/> Hologram",0
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (324279) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (324309) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268996,36,EUTRAN-BAND3,1444,3,3,-147,-1213,-889,8 D (324319) cellular: mux-rx-line #3: +CREG: 1,1 D (324319) cellular: mux-rx-line #3: +CGREG: 1,1 D (324319) cellular: mux-rx-line #3: +CEREG: 1,1 D (324319) cellular: mux-rx-line #3: +CCLK: "22/08/31,12:22:05+08" D (324319) cellular: mux-rx-line #3: +CSQ: 11,99 D (324319) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7
Regards, Michael
Am 31.08.22 um 10:41 schrieb Mark Webb-Johnson:
I’ve made some further revisions. Now in latest edge -49 release.
Grateful for feedback on this, please. Particularly with SIM5360 (which should be unaffected, but …).
Regards, Mark.
> On 26 Aug 2022, at 10:17 PM, Michael Balzer<dexter@expeedo.de> > wrote: > > Signed PGP part > From testing on my three modules here in Germany, looks good: > > Model: SIMCOM_SIM7600G > Revision: SIM7600M21-A_V2.0 > D (151128) cellular: mux-tx #3: > AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? > D (151158) cellular: mux-rx-line #3: +CPSI: > LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-93,-1141,-864,14 > D (151168) cellular: mux-rx-line #3: +CREG: 1,5 > D (151168) cellular: mux-rx-line #3: +CGREG: 1,5 > D (151168) cellular: mux-rx-line #3: +CEREG: 1,5 > D (151168) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:13:51+08" > D (151168) cellular: mux-rx-line #3: +CSQ: 13,99 > D (151168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de > <http://vodafone.de/> Hologram",7 > > Model: SIMCOM_SIM5360E > Revision: SIM5360E_V3.5 > D (143784) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? > D (143804) cellular: mux-rx-line #3: +CPSI: > GSM,Online,262-02,0x011f,14822,4 EGSM 900,-66,0,41-41 > D (143814) cellular: mux-rx-line #3: +CREG: 1,5 > D (143814) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:24:20+08" > D (143814) cellular: mux-rx-line #3: +CSQ: 23,99 > D (143814) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de > <http://vodafone.de/> Hologram",0 > > Model: SIMCOM_SIM7600G > Revision: SIM7600M21-A_V2.0.1 > D (9625359) cellular: mux-tx #3: > AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? > D (9625389) cellular: mux-rx-line #3: +CPSI: > LTE,Online,262-01,0x34B9,29268999,268,EUTRAN-BAND8,3749,2,2,-112,-1042,-791,15 > D (9625399) cellular: mux-rx-line #3: +CREG: 1,1 > D (9625399) cellular: mux-rx-line #3: +CGREG: 1,1 > D (9625399) cellular: mux-rx-line #3: +CEREG: 1,1 > D (9625399) cellular: mux-rx-line #3: +CCLK: "22/08/26,12:40:14+08" > D (9625399) cellular: mux-rx-line #3: +CSQ: 15,99 > D (9625399) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7 > > > Regards, > Michael > > > Am 26.08.22 um 08:53 schrieb Mark Webb-Johnson: >> Thanks. >> >> I think anyone in USA using Hologram on T-Mobile would benefit >> from this. I just worry I break something else. >> >> Regards, Mark. >> >>> On 26 Aug 2022, at 2:46 PM, Craig Leres<leres@xse.com> wrote: >>> >>> >>> On 8/25/22 23:34, Mark Webb-Johnson wrote: >>>> I’ve been fighting a problem for the past few months with >>>> registration getting denied on T-Mobile in USA using Hologram >>>> and our new 4G SIM7600G modem. Without cellular connectivity >>>> at home, it hasn’t been easy to recreate this, but I found a >>>> solution: >>> I've been seeing intermittent netreg errors lately; I've >>> booted this version on a couple of my modules... >>> >>> Craig >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@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 > > >
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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 <220904-UART-frame-errors.txt>
_______________________________________________ OvmsDev mailing list OvmsDev@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
A related issue -- I remember wanting to ask this before: why do we receive all NMEA sentences three times / on three MUX channels? Apparently they come in on channels 1, 3 and 4 -- stumbled across this again because this now leads to these also being added to a cellular command response: OVMS# cell cmd AT+CMUX? +CMUX: 0,0,5,118,0,0,600 OK $GPRMC,114516.00,A,xxx.139223,N,xxx.391678,E,0.0,,090922,0.9,W,A*07 $GNGNS,114516.00,xxx.139223,N,xxx.391678,E,AAN,11,1.0,324.4,47.0,,,V*68 V (3388221) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) D (3388231) gsm-nmea: Incoming RMC: $GPRMC,114516.00,A,xxx.139223,N,xxx.391678,E,0.0,,090922,0.9,W,A*07 V (3388231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (3388231) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (3388241) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) D (3388241) gsm-nmea: Incoming GNS: $GNGNS,114516.00,xxx.139223,N,xxx.391678,E,AAN,11,1.0,324.4,47.0,,,V*68 V (3388251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (3388261) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) V (3393221) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) D (3393231) gsm-nmea: Incoming RMC: $GPRMC,114521.00,A,xxx.139223,N,xxx.391676,E,0.0,,090922,0.9,W,A*0D V (3393231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (3393231) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (3393241) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) D (3393241) gsm-nmea: Incoming GNS: $GNGNS,114521.00,xxx.139223,N,xxx.391676,E,AAN,11,1.0,324.4,47.0,,,V*62 V (3393251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (3393261) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) This also produces a lot of unnecessary stress on the ESP's RX buffer, doesn't it? Channel 1 is the dedicated NMEA channel, 3 is POLL and 4 is CMD. I don't see why channels 3 & 4 are used for these by the modem, but I also cannot find any command meant to configure this. Any idea on this? Regards, Michael Am 09.09.22 um 13:14 schrieb Michael Balzer:
Mark,
(am I the only one experiencing this?)
I've had multiple times of temporarily frozen modem communication over the last days on my car module. That's new, so I think we should try to fix that before releasing.
On my bench module there's a clear correlation between the extended status query and the frame errors. It's also not related to the NMEA messages, I've checked that, they come at another second.
Log excerpts below.
With frame errors responses also occasionally get corrupted, e.g. D (204251) cellular: mux-rx-line #3: Hologram",7
I think the extended status responses now very often cause an overflow on the RX buffer when coming in together. Solution could be to split the queries and distribute over 2-3 seconds.
I don't know if that will also fix the strange cold/warm boot difference with this, but maybe that's simply because the modem is faster with getting back to the network after a reboot, so the status responses become large quickly.
Regards, Michael
D (204211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (204251) gsm-mux: Frame error: EOF mismatch (CHAN=55, ADDR=df, CTRL=ff, FCS=35, LEN=133) V (204251) gsm-mux: Frame dump: f9 df ff ff bf bf dd ff f9 0d ff af 0d 0a 2b 43 | ..............+C V (204251) gsm-mux: Frame dump: 50 53 49 3a 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c | PSI: LTE,Online, V (204251) gsm-mux: Frame dump: 32 36 32 2d 30 32 2c 30 78 42 30 46 35 2c 31 33 | 262-02,0xB0F5,13 V (204251) gsm-mux: Frame dump: 31 37 39 34 31 32 2c 34 34 38 2c 45 55 54 52 41 | 179412,448,EUTRA V (204251) gsm-mux: Frame dump: 4e 2d 42 41 4e 44 31 2c 31 30 30 2c 34 2c 34 2c | N-BAND1,100,4,4, V (204251) gsm-mux: Frame dump: 2d 39 32 2c 2d 31 31 35 32 2c 2d 38 37 35 2c 31 | -92,-1152,-875,1 V (204251) gsm-mux: Frame dump: 34 0d 0a 34 f9 f9 0d ff ed 0d 0a 2b 43 52 45 47 | 4..4.......+CREG V (204251) gsm-mux: Frame dump: 3a 20 31 2c 35 0d 0a 0d 0a 2b 43 47 52 45 47 3a | : 1,5....+CGREG: V (204251) gsm-mux: Frame dump: 20 31 2c 35 0d | 1,5. V (204251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (204251) cellular: mux-rx-line #3: Hologram",7 V (208231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (208241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (208251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (208251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (208271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82)
…
V (233271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (233271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (234211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234231) gsm-mux: Frame error: EOF mismatch (CHAN=63, ADDR=ff, CTRL=ea, FCS=2c, LEN=53) V (234231) gsm-mux: Frame dump: f9 ff ea 5f ff b7 ff fd ff b9 df fd bf f9 ff fd | ..._............ V (234231) gsm-mux: Frame dump: fb ff f9 f9 a9 f9 0d ff af 0d 0a 2b 43 50 53 49 | ...........+CPSI V (234231) gsm-mux: Frame dump: 3a 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c 32 36 32 | : LTE,Online,262 V (234231) gsm-mux: Frame dump: 2d 30 32 2c 30 | -02,0 V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=a7, LEN=124) D (234241) cellular: mux-rx-line #3: +CREG: 1,5 D (234241) cellular: mux-rx-line #3: +CGREG: 1,5 D (234241) cellular: mux-rx-line #3: +CEREG: 1,5 D (234241) cellular: mux-rx-line #3: +CCLK: "22/09/09,12:52:41+08" D (234241) cellular: mux-rx-line #3: +CSQ: 13,99 V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (234251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 V (238231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (238241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78)
…
V (293251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (293251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (293271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (293271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (294211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (294211) cellular: UART frame error W (294211) cellular: UART frame error W (294211) cellular: UART frame error W (294241) gsm-mux: Frame error: EOF mismatch (CHAN=59, ADDR=ef, CTRL=db, FCS=2b, LEN=117) V (294241) gsm-mux: Frame dump: f9 ef db df ef df f7 cb f9 ff ff db 7f fd ff ff | ................ V (294241) gsm-mux: Frame dump: f9 0d ff af 0d 0a 2b 43 50 53 49 3a 20 4c 54 45 | ......+CPSI: LTE V (294241) gsm-mux: Frame dump: 2c 4f 6e 6c 69 6e 65 2c 32 36 32 2d 30 32 2c 30 | ,Online,262-02,0 V (294241) gsm-mux: Frame dump: 78 42 30 46 35 2c 31 33 31 37 39 34 31 32 2c 34 | xB0F5,13179412,4 V (294241) gsm-mux: Frame dump: 34 38 2c 45 55 54 52 41 4e 2d 42 41 4e 44 31 2c | 48,EUTRAN-BAND1, V (294241) gsm-mux: Frame dump: 31 30 30 2c 34 2c 34 2c 2d 39 36 2c 2d 31 31 35 | 100,4,4,-96,-115 V (294241) gsm-mux: Frame dump: 35 2c 2d 38 37 33 2c 31 34 0d 0a 34 f9 f9 0d ff | 5,-873,14..4.... V (294241) gsm-mux: Frame dump: ed 0d 0a 2b 43 | ...+C V (294251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (294251) cellular: mux-rx-line #3: Hologram",7 V (298231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (298241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (298241) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (298251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (298261) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (298271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
…
V (323251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (323261) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (323271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (323271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (324211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (324231) gsm-mux: Frame error: EOF mismatch (CHAN=29, ADDR=77, CTRL=fb, FCS=45, LEN=125) V (324231) gsm-mux: Frame dump: f9 77 fb ef 5f ff bb ed fb bb db ff b7 fb cf ff | .w.._........... V (324231) gsm-mux: Frame dump: bf d9 ff bb f9 0d ff b1 0d 0a 2b 43 50 53 49 3a | ..........+CPSI: V (324231) gsm-mux: Frame dump: 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c 32 36 32 2d | LTE,Online,262- V (324231) gsm-mux: Frame dump: 30 32 2c 30 78 42 30 46 35 2c 31 33 31 37 39 34 | 02,0xB0F5,131794 V (324231) gsm-mux: Frame dump: 31 32 2c 34 34 38 2c 45 55 54 52 41 4e 2d 42 41 | 12,448,EUTRAN-BA V (324241) gsm-mux: Frame dump: 4e 44 31 2c 31 30 30 2c 34 2c 34 2c 2d 31 30 39 | ND1,100,4,4,-109 V (324241) gsm-mux: Frame dump: 2c 2d 31 31 36 36 2c 2d 38 37 34 2c 31 31 0d 0a | ,-1166,-874,11.. V (324241) gsm-mux: Frame dump: c2 f9 f9 0d ff ed 0d 0a 2b 43 52 45 47 | ........+CREG V (324241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (324241) cellular: mux-rx-line #3: Hologram",7 V (328231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (328241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (328251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
…
V (353251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (353251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (353271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (353271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (354211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (354211) cellular: UART frame error W (354211) cellular: UART frame error W (354211) cellular: UART frame error W (354211) cellular: UART frame error V (354231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=34, LEN=93) D (354231) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-122,-1184,-874,9 V (354241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=a7, LEN=124) D (354241) cellular: mux-rx-line #3: +CREG: 1,5 D (354241) cellular: mux-rx-line #3: +CGREG: 1,5 D (354241) cellular: mux-rx-line #3: +CEREG: 1,5 D (354241) cellular: mux-rx-line #3: +CCLK: "22/09/09,12:54:41+08" D (354251) cellular: mux-rx-line #3: +CSQ: 13,99 V (354251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (354251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 V (358231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (358241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (358251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
Am 08.09.22 um 07:15 schrieb Mark Webb-Johnson:
Michael,
I reviewed:
$ git diff 2b25287fbef5fa968236cb8e556ea11da7c8f579 components/ovms_cellular components/simcom
But can’t see anything really related to frame errors, other than the two extra CGREG and CEREG output lines once every thirty seconds.
Maybe an existing issue re-occurring?
Do you think this should block our release of 3.3.003 to ‘main’ release?
Regards, Mark.
On 4 Sep 2022, at 4:17 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part I'm seeing an issue with the current build, but not sure if that's new & related to the latest changes or just coincidentally has become more severe somehow:
On a cold boot, modem communication is mostly fine, nearly no UART frame errors, and messages received by the modem are fine.
After the first warm reboot, initial modem messages are garbled, and lots of UART frame errors occur right from the beginning of modem communication.
This looks like some part of the serial communication now doesn't get fully reset on a reboot. Log attached.
Regards, Michael
Am 03.09.22 um 11:37 schrieb Michael Balzer:
EAP release also done on ovms.dexters-web.de <http://ovms.dexters-web.de>.
Regards, Michael
Am 01.09.22 um 02:53 schrieb Mark Webb-Johnson:
Sounds good. I think this is important enough to make a formal release so I will arrange that.
I have made a 3.3.003, and released to EAP on api.openvehicles.com <http://api.openvehicles.com/>. We can target a main release for next week.
Regards, Mark.
P.S. I have a bunch of unrelated enhancements to CAN logging to commit, but those can wait.
On 31 Aug 2022, at 10:27 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part Looks good:
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0 D (80128) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (80158) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,12829697,303,EUTRAN-BAND20,6300,3,3,-93,-969,-701,17 D (80168) cellular: mux-rx-line #3: +CREG: 1,5 D (80168) cellular: mux-rx-line #3: +CGREG: 1,5 D (80168) cellular: mux-rx-line #3: +CEREG: 1,5 D (80168) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:15:03+08" D (80168) cellular: mux-rx-line #3: +CSQ: 21,99 D (80168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de/> Hologram",7
Model: SIMCOM_SIM5360E Revision: SIM5360E_V3.5 D (74307) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (74327) cellular: mux-rx-line #3: +CPSI: GSM,Online,262-02,0x011f,14822,4 EGSM 900,-69,0,38-38 D (74337) cellular: mux-rx-line #3: +CREG: 1,5 D (74337) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:19:47+08" D (74337) cellular: mux-rx-line #3: +CSQ: 22,99 D (74337) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de <http://vodafone.de/> Hologram",0
Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 D (324279) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? D (324309) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-01,0x34B9,29268996,36,EUTRAN-BAND3,1444,3,3,-147,-1213,-889,8 D (324319) cellular: mux-rx-line #3: +CREG: 1,1 D (324319) cellular: mux-rx-line #3: +CGREG: 1,1 D (324319) cellular: mux-rx-line #3: +CEREG: 1,1 D (324319) cellular: mux-rx-line #3: +CCLK: "22/08/31,12:22:05+08" D (324319) cellular: mux-rx-line #3: +CSQ: 11,99 D (324319) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7
Regards, Michael
Am 31.08.22 um 10:41 schrieb Mark Webb-Johnson: > I’ve made some further revisions. Now in latest edge -49 release. > > Grateful for feedback on this, please. Particularly with SIM5360 > (which should be unaffected, but …). > > Regards, Mark. > >> On 26 Aug 2022, at 10:17 PM, Michael Balzer<dexter@expeedo.de> >> wrote: >> >> Signed PGP part >> From testing on my three modules here in Germany, looks good: >> >> Model: SIMCOM_SIM7600G >> Revision: SIM7600M21-A_V2.0 >> D (151128) cellular: mux-tx #3: >> AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >> D (151158) cellular: mux-rx-line #3: +CPSI: >> LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-93,-1141,-864,14 >> D (151168) cellular: mux-rx-line #3: +CREG: 1,5 >> D (151168) cellular: mux-rx-line #3: +CGREG: 1,5 >> D (151168) cellular: mux-rx-line #3: +CEREG: 1,5 >> D (151168) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:13:51+08" >> D (151168) cellular: mux-rx-line #3: +CSQ: 13,99 >> D (151168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de >> <http://vodafone.de/> Hologram",7 >> >> Model: SIMCOM_SIM5360E >> Revision: SIM5360E_V3.5 >> D (143784) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >> D (143804) cellular: mux-rx-line #3: +CPSI: >> GSM,Online,262-02,0x011f,14822,4 EGSM 900,-66,0,41-41 >> D (143814) cellular: mux-rx-line #3: +CREG: 1,5 >> D (143814) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:24:20+08" >> D (143814) cellular: mux-rx-line #3: +CSQ: 23,99 >> D (143814) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de >> <http://vodafone.de/> Hologram",0 >> >> Model: SIMCOM_SIM7600G >> Revision: SIM7600M21-A_V2.0.1 >> D (9625359) cellular: mux-tx #3: >> AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >> D (9625389) cellular: mux-rx-line #3: +CPSI: >> LTE,Online,262-01,0x34B9,29268999,268,EUTRAN-BAND8,3749,2,2,-112,-1042,-791,15 >> D (9625399) cellular: mux-rx-line #3: +CREG: 1,1 >> D (9625399) cellular: mux-rx-line #3: +CGREG: 1,1 >> D (9625399) cellular: mux-rx-line #3: +CEREG: 1,1 >> D (9625399) cellular: mux-rx-line #3: +CCLK: "22/08/26,12:40:14+08" >> D (9625399) cellular: mux-rx-line #3: +CSQ: 15,99 >> D (9625399) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7 >> >> >> Regards, >> Michael >> >> >> Am 26.08.22 um 08:53 schrieb Mark Webb-Johnson: >>> Thanks. >>> >>> I think anyone in USA using Hologram on T-Mobile would benefit >>> from this. I just worry I break something else. >>> >>> Regards, Mark. >>> >>>> On 26 Aug 2022, at 2:46 PM, Craig Leres<leres@xse.com> wrote: >>>> >>>> >>>> On 8/25/22 23:34, Mark Webb-Johnson wrote: >>>>> I’ve been fighting a problem for the past few months with >>>>> registration getting denied on T-Mobile in USA using >>>>> Hologram and our new 4G SIM7600G modem. Without cellular >>>>> connectivity at home, it hasn’t been easy to recreate this, >>>>> but I found a solution: >>>> I've been seeing intermittent netreg errors lately; I've >>>> booted this version on a couple of my modules... >>>> >>>> Craig >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@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 >> >> >> > > _______________________________________________ > OvmsDev mailing list > OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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 <220904-UART-frame-errors.txt>
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
Regarding the UART frame errors: 1. disabling GPS doesn't change anything 2. splitting the status poll into two queries doesn't change anything 3. issuing a UART HW FIFO reset (https://github.com/espressif/esp-idf/commit/5404252e803f5489a72119a3ad41b580...) doesn't change anything 4. explicitly setting the mode to standard UART doesn't change anything 5. performing a deep sleep instead of a standard reboot doesn't change anything 6. brute force writing a cycle of all 1's and all 0's twice to the full UART1 register range before driver init doesn't change anything Apparently, the ESP32 UART has some kind of hardware flaw leading to an ESP32 reset actually not doing a full UART reset. * https://www.esp32.com/viewtopic.php?t=4701 * https://github.com/espressif/esp-idf/commit/5404252e803f5489a72119a3ad41b580... * https://github.com/espressif/esp-idf/commit/f482e9e54ce83e249e46f5ee082f6ffb... * …some were lucky with this patch: https://esp32.com/viewtopic.php?f=2&t=4725 …we are not.
//Due to hardware issue, we can not use fifo_rst to reset uart fifo. //See description about UART_TXFIFO_RST and UART_RXFIFO_RST in <<esp32_technical_reference_manual>> v2.6 or later.
There is apparently no method to perform a full UART HW reset, at least I haven't found one. It seems this is an issue we cannot fix (in software). But I now don't think this is a new issue, and this also affects modules quite differently, no idea depending on what circumstances: on the current run, my car module has lots of FIFO overflows & quite some MUX framing errors, but not a single UART frame error. IOW, I don't think we should let that block the release. Regards, Michael Am 09.09.22 um 14:23 schrieb Michael Balzer:
A related issue -- I remember wanting to ask this before: why do we receive all NMEA sentences three times / on three MUX channels?
Apparently they come in on channels 1, 3 and 4 -- stumbled across this again because this now leads to these also being added to a cellular command response:
OVMS# cell cmd AT+CMUX? +CMUX: 0,0,5,118,0,0,600 OK $GPRMC,114516.00,A,xxx.139223,N,xxx.391678,E,0.0,,090922,0.9,W,A*07 $GNGNS,114516.00,xxx.139223,N,xxx.391678,E,AAN,11,1.0,324.4,47.0,,,V*68
V (3388221) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) D (3388231) gsm-nmea: Incoming RMC: $GPRMC,114516.00,A,xxx.139223,N,xxx.391678,E,0.0,,090922,0.9,W,A*07 V (3388231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (3388231) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
V (3388241) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) D (3388241) gsm-nmea: Incoming GNS: $GNGNS,114516.00,xxx.139223,N,xxx.391678,E,AAN,11,1.0,324.4,47.0,,,V*68 V (3388251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (3388261) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
V (3393221) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) D (3393231) gsm-nmea: Incoming RMC: $GPRMC,114521.00,A,xxx.139223,N,xxx.391676,E,0.0,,090922,0.9,W,A*0D V (3393231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (3393231) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
V (3393241) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) D (3393241) gsm-nmea: Incoming GNS: $GNGNS,114521.00,xxx.139223,N,xxx.391676,E,AAN,11,1.0,324.4,47.0,,,V*62 V (3393251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (3393261) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
This also produces a lot of unnecessary stress on the ESP's RX buffer, doesn't it?
Channel 1 is the dedicated NMEA channel, 3 is POLL and 4 is CMD. I don't see why channels 3 & 4 are used for these by the modem, but I also cannot find any command meant to configure this.
Any idea on this?
Regards, Michael
Am 09.09.22 um 13:14 schrieb Michael Balzer:
Mark,
(am I the only one experiencing this?)
I've had multiple times of temporarily frozen modem communication over the last days on my car module. That's new, so I think we should try to fix that before releasing.
On my bench module there's a clear correlation between the extended status query and the frame errors. It's also not related to the NMEA messages, I've checked that, they come at another second.
Log excerpts below.
With frame errors responses also occasionally get corrupted, e.g. D (204251) cellular: mux-rx-line #3: Hologram",7
I think the extended status responses now very often cause an overflow on the RX buffer when coming in together. Solution could be to split the queries and distribute over 2-3 seconds.
I don't know if that will also fix the strange cold/warm boot difference with this, but maybe that's simply because the modem is faster with getting back to the network after a reboot, so the status responses become large quickly.
Regards, Michael
D (204211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (204251) gsm-mux: Frame error: EOF mismatch (CHAN=55, ADDR=df, CTRL=ff, FCS=35, LEN=133) V (204251) gsm-mux: Frame dump: f9 df ff ff bf bf dd ff f9 0d ff af 0d 0a 2b 43 | ..............+C V (204251) gsm-mux: Frame dump: 50 53 49 3a 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c | PSI: LTE,Online, V (204251) gsm-mux: Frame dump: 32 36 32 2d 30 32 2c 30 78 42 30 46 35 2c 31 33 | 262-02,0xB0F5,13 V (204251) gsm-mux: Frame dump: 31 37 39 34 31 32 2c 34 34 38 2c 45 55 54 52 41 | 179412,448,EUTRA V (204251) gsm-mux: Frame dump: 4e 2d 42 41 4e 44 31 2c 31 30 30 2c 34 2c 34 2c | N-BAND1,100,4,4, V (204251) gsm-mux: Frame dump: 2d 39 32 2c 2d 31 31 35 32 2c 2d 38 37 35 2c 31 | -92,-1152,-875,1 V (204251) gsm-mux: Frame dump: 34 0d 0a 34 f9 f9 0d ff ed 0d 0a 2b 43 52 45 47 | 4..4.......+CREG V (204251) gsm-mux: Frame dump: 3a 20 31 2c 35 0d 0a 0d 0a 2b 43 47 52 45 47 3a | : 1,5....+CGREG: V (204251) gsm-mux: Frame dump: 20 31 2c 35 0d | 1,5. V (204251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (204251) cellular: mux-rx-line #3: Hologram",7 V (208231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (208241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (208251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (208251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (208271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82)
…
V (233271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (233271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (234211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234231) gsm-mux: Frame error: EOF mismatch (CHAN=63, ADDR=ff, CTRL=ea, FCS=2c, LEN=53) V (234231) gsm-mux: Frame dump: f9 ff ea 5f ff b7 ff fd ff b9 df fd bf f9 ff fd | ..._............ V (234231) gsm-mux: Frame dump: fb ff f9 f9 a9 f9 0d ff af 0d 0a 2b 43 50 53 49 | ...........+CPSI V (234231) gsm-mux: Frame dump: 3a 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c 32 36 32 | : LTE,Online,262 V (234231) gsm-mux: Frame dump: 2d 30 32 2c 30 | -02,0 V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=a7, LEN=124) D (234241) cellular: mux-rx-line #3: +CREG: 1,5 D (234241) cellular: mux-rx-line #3: +CGREG: 1,5 D (234241) cellular: mux-rx-line #3: +CEREG: 1,5 D (234241) cellular: mux-rx-line #3: +CCLK: "22/09/09,12:52:41+08" D (234241) cellular: mux-rx-line #3: +CSQ: 13,99 V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (234251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 V (238231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (238241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78)
…
V (293251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (293251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (293271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (293271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (294211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (294211) cellular: UART frame error W (294211) cellular: UART frame error W (294211) cellular: UART frame error W (294241) gsm-mux: Frame error: EOF mismatch (CHAN=59, ADDR=ef, CTRL=db, FCS=2b, LEN=117) V (294241) gsm-mux: Frame dump: f9 ef db df ef df f7 cb f9 ff ff db 7f fd ff ff | ................ V (294241) gsm-mux: Frame dump: f9 0d ff af 0d 0a 2b 43 50 53 49 3a 20 4c 54 45 | ......+CPSI: LTE V (294241) gsm-mux: Frame dump: 2c 4f 6e 6c 69 6e 65 2c 32 36 32 2d 30 32 2c 30 | ,Online,262-02,0 V (294241) gsm-mux: Frame dump: 78 42 30 46 35 2c 31 33 31 37 39 34 31 32 2c 34 | xB0F5,13179412,4 V (294241) gsm-mux: Frame dump: 34 38 2c 45 55 54 52 41 4e 2d 42 41 4e 44 31 2c | 48,EUTRAN-BAND1, V (294241) gsm-mux: Frame dump: 31 30 30 2c 34 2c 34 2c 2d 39 36 2c 2d 31 31 35 | 100,4,4,-96,-115 V (294241) gsm-mux: Frame dump: 35 2c 2d 38 37 33 2c 31 34 0d 0a 34 f9 f9 0d ff | 5,-873,14..4.... V (294241) gsm-mux: Frame dump: ed 0d 0a 2b 43 | ...+C V (294251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (294251) cellular: mux-rx-line #3: Hologram",7 V (298231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (298241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (298241) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (298251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (298261) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (298271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
…
V (323251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (323261) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (323271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (323271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (324211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (324231) gsm-mux: Frame error: EOF mismatch (CHAN=29, ADDR=77, CTRL=fb, FCS=45, LEN=125) V (324231) gsm-mux: Frame dump: f9 77 fb ef 5f ff bb ed fb bb db ff b7 fb cf ff | .w.._........... V (324231) gsm-mux: Frame dump: bf d9 ff bb f9 0d ff b1 0d 0a 2b 43 50 53 49 3a | ..........+CPSI: V (324231) gsm-mux: Frame dump: 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c 32 36 32 2d | LTE,Online,262- V (324231) gsm-mux: Frame dump: 30 32 2c 30 78 42 30 46 35 2c 31 33 31 37 39 34 | 02,0xB0F5,131794 V (324231) gsm-mux: Frame dump: 31 32 2c 34 34 38 2c 45 55 54 52 41 4e 2d 42 41 | 12,448,EUTRAN-BA V (324241) gsm-mux: Frame dump: 4e 44 31 2c 31 30 30 2c 34 2c 34 2c 2d 31 30 39 | ND1,100,4,4,-109 V (324241) gsm-mux: Frame dump: 2c 2d 31 31 36 36 2c 2d 38 37 34 2c 31 31 0d 0a | ,-1166,-874,11.. V (324241) gsm-mux: Frame dump: c2 f9 f9 0d ff ed 0d 0a 2b 43 52 45 47 | ........+CREG V (324241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (324241) cellular: mux-rx-line #3: Hologram",7 V (328231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (328241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (328251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
…
V (353251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (353251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (353271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (353271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (354211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (354211) cellular: UART frame error W (354211) cellular: UART frame error W (354211) cellular: UART frame error W (354211) cellular: UART frame error V (354231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=34, LEN=93) D (354231) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-122,-1184,-874,9 V (354241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=a7, LEN=124) D (354241) cellular: mux-rx-line #3: +CREG: 1,5 D (354241) cellular: mux-rx-line #3: +CGREG: 1,5 D (354241) cellular: mux-rx-line #3: +CEREG: 1,5 D (354241) cellular: mux-rx-line #3: +CCLK: "22/09/09,12:54:41+08" D (354251) cellular: mux-rx-line #3: +CSQ: 13,99 V (354251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (354251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 V (358231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (358241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (358251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
Am 08.09.22 um 07:15 schrieb Mark Webb-Johnson:
Michael,
I reviewed:
$ git diff 2b25287fbef5fa968236cb8e556ea11da7c8f579 components/ovms_cellular components/simcom
But can’t see anything really related to frame errors, other than the two extra CGREG and CEREG output lines once every thirty seconds.
Maybe an existing issue re-occurring?
Do you think this should block our release of 3.3.003 to ‘main’ release?
Regards, Mark.
On 4 Sep 2022, at 4:17 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part I'm seeing an issue with the current build, but not sure if that's new & related to the latest changes or just coincidentally has become more severe somehow:
On a cold boot, modem communication is mostly fine, nearly no UART frame errors, and messages received by the modem are fine.
After the first warm reboot, initial modem messages are garbled, and lots of UART frame errors occur right from the beginning of modem communication.
This looks like some part of the serial communication now doesn't get fully reset on a reboot. Log attached.
Regards, Michael
Am 03.09.22 um 11:37 schrieb Michael Balzer:
EAP release also done on ovms.dexters-web.de <http://ovms.dexters-web.de>.
Regards, Michael
Am 01.09.22 um 02:53 schrieb Mark Webb-Johnson:
Sounds good. I think this is important enough to make a formal release so I will arrange that.
I have made a 3.3.003, and released to EAP on api.openvehicles.com <http://api.openvehicles.com/>. We can target a main release for next week.
Regards, Mark.
P.S. I have a bunch of unrelated enhancements to CAN logging to commit, but those can wait.
> On 31 Aug 2022, at 10:27 PM, Michael Balzer <dexter@expeedo.de> > wrote: > > Signed PGP part > Looks good: > > Model: SIMCOM_SIM7600G > Revision: SIM7600M21-A_V2.0 > D (80128) cellular: mux-tx #3: > AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? > D (80158) cellular: mux-rx-line #3: +CPSI: > LTE,Online,262-02,0xB0F5,12829697,303,EUTRAN-BAND20,6300,3,3,-93,-969,-701,17 > D (80168) cellular: mux-rx-line #3: +CREG: 1,5 > D (80168) cellular: mux-rx-line #3: +CGREG: 1,5 > D (80168) cellular: mux-rx-line #3: +CEREG: 1,5 > D (80168) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:15:03+08" > D (80168) cellular: mux-rx-line #3: +CSQ: 21,99 > D (80168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de > <http://vodafone.de/> Hologram",7 > > Model: SIMCOM_SIM5360E > Revision: SIM5360E_V3.5 > D (74307) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? > D (74327) cellular: mux-rx-line #3: +CPSI: > GSM,Online,262-02,0x011f,14822,4 EGSM 900,-69,0,38-38 > D (74337) cellular: mux-rx-line #3: +CREG: 1,5 > D (74337) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:19:47+08" > D (74337) cellular: mux-rx-line #3: +CSQ: 22,99 > D (74337) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de > <http://vodafone.de/> Hologram",0 > > Model: SIMCOM_SIM7600G > Revision: SIM7600M21-A_V2.0.1 > D (324279) cellular: mux-tx #3: > AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? > D (324309) cellular: mux-rx-line #3: +CPSI: > LTE,Online,262-01,0x34B9,29268996,36,EUTRAN-BAND3,1444,3,3,-147,-1213,-889,8 > D (324319) cellular: mux-rx-line #3: +CREG: 1,1 > D (324319) cellular: mux-rx-line #3: +CGREG: 1,1 > D (324319) cellular: mux-rx-line #3: +CEREG: 1,1 > D (324319) cellular: mux-rx-line #3: +CCLK: "22/08/31,12:22:05+08" > D (324319) cellular: mux-rx-line #3: +CSQ: 11,99 > D (324319) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7 > > > Regards, > Michael > > > Am 31.08.22 um 10:41 schrieb Mark Webb-Johnson: >> I’ve made some further revisions. Now in latest edge -49 release. >> >> Grateful for feedback on this, please. Particularly with >> SIM5360 (which should be unaffected, but …). >> >> Regards, Mark. >> >>> On 26 Aug 2022, at 10:17 PM, Michael Balzer<dexter@expeedo.de> >>> wrote: >>> >>> Signed PGP part >>> From testing on my three modules here in Germany, looks good: >>> >>> Model: SIMCOM_SIM7600G >>> Revision: SIM7600M21-A_V2.0 >>> D (151128) cellular: mux-tx #3: >>> AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >>> D (151158) cellular: mux-rx-line #3: +CPSI: >>> LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-93,-1141,-864,14 >>> D (151168) cellular: mux-rx-line #3: +CREG: 1,5 >>> D (151168) cellular: mux-rx-line #3: +CGREG: 1,5 >>> D (151168) cellular: mux-rx-line #3: +CEREG: 1,5 >>> D (151168) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:13:51+08" >>> D (151168) cellular: mux-rx-line #3: +CSQ: 13,99 >>> D (151168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de >>> <http://vodafone.de/> Hologram",7 >>> >>> Model: SIMCOM_SIM5360E >>> Revision: SIM5360E_V3.5 >>> D (143784) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >>> D (143804) cellular: mux-rx-line #3: +CPSI: >>> GSM,Online,262-02,0x011f,14822,4 EGSM 900,-66,0,41-41 >>> D (143814) cellular: mux-rx-line #3: +CREG: 1,5 >>> D (143814) cellular: mux-rx-line #3: +CCLK: "22/08/26,09:24:20+08" >>> D (143814) cellular: mux-rx-line #3: +CSQ: 23,99 >>> D (143814) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de >>> <http://vodafone.de/> Hologram",0 >>> >>> Model: SIMCOM_SIM7600G >>> Revision: SIM7600M21-A_V2.0.1 >>> D (9625359) cellular: mux-tx #3: >>> AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >>> D (9625389) cellular: mux-rx-line #3: +CPSI: >>> LTE,Online,262-01,0x34B9,29268999,268,EUTRAN-BAND8,3749,2,2,-112,-1042,-791,15 >>> D (9625399) cellular: mux-rx-line #3: +CREG: 1,1 >>> D (9625399) cellular: mux-rx-line #3: +CGREG: 1,1 >>> D (9625399) cellular: mux-rx-line #3: +CEREG: 1,1 >>> D (9625399) cellular: mux-rx-line #3: +CCLK: >>> "22/08/26,12:40:14+08" >>> D (9625399) cellular: mux-rx-line #3: +CSQ: 15,99 >>> D (9625399) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7 >>> >>> >>> Regards, >>> Michael >>> >>> >>> Am 26.08.22 um 08:53 schrieb Mark Webb-Johnson: >>>> Thanks. >>>> >>>> I think anyone in USA using Hologram on T-Mobile would >>>> benefit from this. I just worry I break something else. >>>> >>>> Regards, Mark. >>>> >>>>> On 26 Aug 2022, at 2:46 PM, Craig Leres<leres@xse.com> wrote: >>>>> >>>>> >>>>> On 8/25/22 23:34, Mark Webb-Johnson wrote: >>>>>> I’ve been fighting a problem for the past few months with >>>>>> registration getting denied on T-Mobile in USA using >>>>>> Hologram and our new 4G SIM7600G modem. Without cellular >>>>>> connectivity at home, it hasn’t been easy to recreate this, >>>>>> but I found a solution: >>>>> I've been seeing intermittent netreg errors lately; I've >>>>> booted this version on a couple of my modules... >>>>> >>>>> Craig >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@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 >>> >>> >>> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@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 > >
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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 <220904-UART-frame-errors.txt>
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
Am 24.09.22 um 01:21 schrieb Craig Leres:
More recently I started having issues with network registration and gnss reception; at least every few days both cars will transition from RegisteredRoaming to Searching and then back to RegisteredRoaming. They also transition from 12 satellites in view to no satellites in view and back to 12 satellites in view. For the cellular connection I might buy that a local cell tower is out of service and/or maybe my signal strength is too low. But for the gnss I can't see why this would happen, especially given that I have a satellite antenna in the garage, under the same tar-and-gravel roof as the cars, that I used for ntp synchronization (a u-blox ZED-F9T based receiver tracking four constellations...) and it never misses a beat.
Not sure if I have two different issues here or if one is related to the "SIM7600 Registration Denied" thread.
Those are typical symptoms when the UART communication gets messed up. I had the impression splitting the status poll wouldn't help, but I only tested this on my heavily affected development module. Maybe you'd like to give it a try on your module, patch attached. Please report -- if that helps, maybe we should add that before releasing to "main". Regards, Michael Am 09.09.22 um 21:00 schrieb Michael Balzer:
Regarding the UART frame errors:
1. disabling GPS doesn't change anything 2. splitting the status poll into two queries doesn't change anything 3. issuing a UART HW FIFO reset (https://github.com/espressif/esp-idf/commit/5404252e803f5489a72119a3ad41b580...) doesn't change anything 4. explicitly setting the mode to standard UART doesn't change anything 5. performing a deep sleep instead of a standard reboot doesn't change anything 6. brute force writing a cycle of all 1's and all 0's twice to the full UART1 register range before driver init doesn't change anything
Apparently, the ESP32 UART has some kind of hardware flaw leading to an ESP32 reset actually not doing a full UART reset.
* https://www.esp32.com/viewtopic.php?t=4701 * https://github.com/espressif/esp-idf/commit/5404252e803f5489a72119a3ad41b580... * https://github.com/espressif/esp-idf/commit/f482e9e54ce83e249e46f5ee082f6ffb... * …some were lucky with this patch: https://esp32.com/viewtopic.php?f=2&t=4725 …we are not.
//Due to hardware issue, we can not use fifo_rst to reset uart fifo. //See description about UART_TXFIFO_RST and UART_RXFIFO_RST in <<esp32_technical_reference_manual>> v2.6 or later.
There is apparently no method to perform a full UART HW reset, at least I haven't found one. It seems this is an issue we cannot fix (in software).
But I now don't think this is a new issue, and this also affects modules quite differently, no idea depending on what circumstances: on the current run, my car module has lots of FIFO overflows & quite some MUX framing errors, but not a single UART frame error.
IOW, I don't think we should let that block the release.
Regards, Michael
Am 09.09.22 um 14:23 schrieb Michael Balzer:
A related issue -- I remember wanting to ask this before: why do we receive all NMEA sentences three times / on three MUX channels?
Apparently they come in on channels 1, 3 and 4 -- stumbled across this again because this now leads to these also being added to a cellular command response:
OVMS# cell cmd AT+CMUX? +CMUX: 0,0,5,118,0,0,600 OK $GPRMC,114516.00,A,xxx.139223,N,xxx.391678,E,0.0,,090922,0.9,W,A*07 $GNGNS,114516.00,xxx.139223,N,xxx.391678,E,AAN,11,1.0,324.4,47.0,,,V*68
V (3388221) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) D (3388231) gsm-nmea: Incoming RMC: $GPRMC,114516.00,A,xxx.139223,N,xxx.391678,E,0.0,,090922,0.9,W,A*07 V (3388231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (3388231) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
V (3388241) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) D (3388241) gsm-nmea: Incoming GNS: $GNGNS,114516.00,xxx.139223,N,xxx.391678,E,AAN,11,1.0,324.4,47.0,,,V*68 V (3388251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (3388261) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
V (3393221) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) D (3393231) gsm-nmea: Incoming RMC: $GPRMC,114521.00,A,xxx.139223,N,xxx.391676,E,0.0,,090922,0.9,W,A*0D V (3393231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (3393231) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
V (3393241) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) D (3393241) gsm-nmea: Incoming GNS: $GNGNS,114521.00,xxx.139223,N,xxx.391676,E,AAN,11,1.0,324.4,47.0,,,V*62 V (3393251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (3393261) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
This also produces a lot of unnecessary stress on the ESP's RX buffer, doesn't it?
Channel 1 is the dedicated NMEA channel, 3 is POLL and 4 is CMD. I don't see why channels 3 & 4 are used for these by the modem, but I also cannot find any command meant to configure this.
Any idea on this?
Regards, Michael
Am 09.09.22 um 13:14 schrieb Michael Balzer:
Mark,
(am I the only one experiencing this?)
I've had multiple times of temporarily frozen modem communication over the last days on my car module. That's new, so I think we should try to fix that before releasing.
On my bench module there's a clear correlation between the extended status query and the frame errors. It's also not related to the NMEA messages, I've checked that, they come at another second.
Log excerpts below.
With frame errors responses also occasionally get corrupted, e.g. D (204251) cellular: mux-rx-line #3: Hologram",7
I think the extended status responses now very often cause an overflow on the RX buffer when coming in together. Solution could be to split the queries and distribute over 2-3 seconds.
I don't know if that will also fix the strange cold/warm boot difference with this, but maybe that's simply because the modem is faster with getting back to the network after a reboot, so the status responses become large quickly.
Regards, Michael
D (204211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (204251) gsm-mux: Frame error: EOF mismatch (CHAN=55, ADDR=df, CTRL=ff, FCS=35, LEN=133) V (204251) gsm-mux: Frame dump: f9 df ff ff bf bf dd ff f9 0d ff af 0d 0a 2b 43 | ..............+C V (204251) gsm-mux: Frame dump: 50 53 49 3a 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c | PSI: LTE,Online, V (204251) gsm-mux: Frame dump: 32 36 32 2d 30 32 2c 30 78 42 30 46 35 2c 31 33 | 262-02,0xB0F5,13 V (204251) gsm-mux: Frame dump: 31 37 39 34 31 32 2c 34 34 38 2c 45 55 54 52 41 | 179412,448,EUTRA V (204251) gsm-mux: Frame dump: 4e 2d 42 41 4e 44 31 2c 31 30 30 2c 34 2c 34 2c | N-BAND1,100,4,4, V (204251) gsm-mux: Frame dump: 2d 39 32 2c 2d 31 31 35 32 2c 2d 38 37 35 2c 31 | -92,-1152,-875,1 V (204251) gsm-mux: Frame dump: 34 0d 0a 34 f9 f9 0d ff ed 0d 0a 2b 43 52 45 47 | 4..4.......+CREG V (204251) gsm-mux: Frame dump: 3a 20 31 2c 35 0d 0a 0d 0a 2b 43 47 52 45 47 3a | : 1,5....+CGREG: V (204251) gsm-mux: Frame dump: 20 31 2c 35 0d | 1,5. V (204251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (204251) cellular: mux-rx-line #3: Hologram",7 V (208231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (208241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (208251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (208251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (208271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82)
…
V (233271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (233271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (234211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234231) gsm-mux: Frame error: EOF mismatch (CHAN=63, ADDR=ff, CTRL=ea, FCS=2c, LEN=53) V (234231) gsm-mux: Frame dump: f9 ff ea 5f ff b7 ff fd ff b9 df fd bf f9 ff fd | ..._............ V (234231) gsm-mux: Frame dump: fb ff f9 f9 a9 f9 0d ff af 0d 0a 2b 43 50 53 49 | ...........+CPSI V (234231) gsm-mux: Frame dump: 3a 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c 32 36 32 | : LTE,Online,262 V (234231) gsm-mux: Frame dump: 2d 30 32 2c 30 | -02,0 V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=a7, LEN=124) D (234241) cellular: mux-rx-line #3: +CREG: 1,5 D (234241) cellular: mux-rx-line #3: +CGREG: 1,5 D (234241) cellular: mux-rx-line #3: +CEREG: 1,5 D (234241) cellular: mux-rx-line #3: +CCLK: "22/09/09,12:52:41+08" D (234241) cellular: mux-rx-line #3: +CSQ: 13,99 V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (234251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 V (238231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (238241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78)
…
V (293251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (293251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (293271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (293271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (294211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (294211) cellular: UART frame error W (294211) cellular: UART frame error W (294211) cellular: UART frame error W (294241) gsm-mux: Frame error: EOF mismatch (CHAN=59, ADDR=ef, CTRL=db, FCS=2b, LEN=117) V (294241) gsm-mux: Frame dump: f9 ef db df ef df f7 cb f9 ff ff db 7f fd ff ff | ................ V (294241) gsm-mux: Frame dump: f9 0d ff af 0d 0a 2b 43 50 53 49 3a 20 4c 54 45 | ......+CPSI: LTE V (294241) gsm-mux: Frame dump: 2c 4f 6e 6c 69 6e 65 2c 32 36 32 2d 30 32 2c 30 | ,Online,262-02,0 V (294241) gsm-mux: Frame dump: 78 42 30 46 35 2c 31 33 31 37 39 34 31 32 2c 34 | xB0F5,13179412,4 V (294241) gsm-mux: Frame dump: 34 38 2c 45 55 54 52 41 4e 2d 42 41 4e 44 31 2c | 48,EUTRAN-BAND1, V (294241) gsm-mux: Frame dump: 31 30 30 2c 34 2c 34 2c 2d 39 36 2c 2d 31 31 35 | 100,4,4,-96,-115 V (294241) gsm-mux: Frame dump: 35 2c 2d 38 37 33 2c 31 34 0d 0a 34 f9 f9 0d ff | 5,-873,14..4.... V (294241) gsm-mux: Frame dump: ed 0d 0a 2b 43 | ...+C V (294251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (294251) cellular: mux-rx-line #3: Hologram",7 V (298231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (298241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (298241) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (298251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (298261) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (298271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
…
V (323251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (323261) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (323271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (323271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (324211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (324231) gsm-mux: Frame error: EOF mismatch (CHAN=29, ADDR=77, CTRL=fb, FCS=45, LEN=125) V (324231) gsm-mux: Frame dump: f9 77 fb ef 5f ff bb ed fb bb db ff b7 fb cf ff | .w.._........... V (324231) gsm-mux: Frame dump: bf d9 ff bb f9 0d ff b1 0d 0a 2b 43 50 53 49 3a | ..........+CPSI: V (324231) gsm-mux: Frame dump: 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c 32 36 32 2d | LTE,Online,262- V (324231) gsm-mux: Frame dump: 30 32 2c 30 78 42 30 46 35 2c 31 33 31 37 39 34 | 02,0xB0F5,131794 V (324231) gsm-mux: Frame dump: 31 32 2c 34 34 38 2c 45 55 54 52 41 4e 2d 42 41 | 12,448,EUTRAN-BA V (324241) gsm-mux: Frame dump: 4e 44 31 2c 31 30 30 2c 34 2c 34 2c 2d 31 30 39 | ND1,100,4,4,-109 V (324241) gsm-mux: Frame dump: 2c 2d 31 31 36 36 2c 2d 38 37 34 2c 31 31 0d 0a | ,-1166,-874,11.. V (324241) gsm-mux: Frame dump: c2 f9 f9 0d ff ed 0d 0a 2b 43 52 45 47 | ........+CREG V (324241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (324241) cellular: mux-rx-line #3: Hologram",7 V (328231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (328241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (328251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
…
V (353251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (353251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (353271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (353271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (354211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (354211) cellular: UART frame error W (354211) cellular: UART frame error W (354211) cellular: UART frame error W (354211) cellular: UART frame error V (354231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=34, LEN=93) D (354231) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-122,-1184,-874,9 V (354241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=a7, LEN=124) D (354241) cellular: mux-rx-line #3: +CREG: 1,5 D (354241) cellular: mux-rx-line #3: +CGREG: 1,5 D (354241) cellular: mux-rx-line #3: +CEREG: 1,5 D (354241) cellular: mux-rx-line #3: +CCLK: "22/09/09,12:54:41+08" D (354251) cellular: mux-rx-line #3: +CSQ: 13,99 V (354251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (354251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 V (358231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (358241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (358251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
Am 08.09.22 um 07:15 schrieb Mark Webb-Johnson:
Michael,
I reviewed:
$ git diff 2b25287fbef5fa968236cb8e556ea11da7c8f579 components/ovms_cellular components/simcom
But can’t see anything really related to frame errors, other than the two extra CGREG and CEREG output lines once every thirty seconds.
Maybe an existing issue re-occurring?
Do you think this should block our release of 3.3.003 to ‘main’ release?
Regards, Mark.
On 4 Sep 2022, at 4:17 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part I'm seeing an issue with the current build, but not sure if that's new & related to the latest changes or just coincidentally has become more severe somehow:
On a cold boot, modem communication is mostly fine, nearly no UART frame errors, and messages received by the modem are fine.
After the first warm reboot, initial modem messages are garbled, and lots of UART frame errors occur right from the beginning of modem communication.
This looks like some part of the serial communication now doesn't get fully reset on a reboot. Log attached.
Regards, Michael
Am 03.09.22 um 11:37 schrieb Michael Balzer:
EAP release also done on ovms.dexters-web.de <http://ovms.dexters-web.de>.
Regards, Michael
Am 01.09.22 um 02:53 schrieb Mark Webb-Johnson: > Sounds good. I think this is important enough to make a formal > release so I will arrange that. > > I have made a 3.3.003, and released to EAP on > api.openvehicles.com <http://api.openvehicles.com/>. We can > target a main release for next week. > > Regards, Mark. > > P.S. I have a bunch of unrelated enhancements to CAN logging to > commit, but those can wait. > >> On 31 Aug 2022, at 10:27 PM, Michael Balzer <dexter@expeedo.de> >> wrote: >> >> Signed PGP part >> Looks good: >> >> Model: SIMCOM_SIM7600G >> Revision: SIM7600M21-A_V2.0 >> D (80128) cellular: mux-tx #3: >> AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >> D (80158) cellular: mux-rx-line #3: +CPSI: >> LTE,Online,262-02,0xB0F5,12829697,303,EUTRAN-BAND20,6300,3,3,-93,-969,-701,17 >> D (80168) cellular: mux-rx-line #3: +CREG: 1,5 >> D (80168) cellular: mux-rx-line #3: +CGREG: 1,5 >> D (80168) cellular: mux-rx-line #3: +CEREG: 1,5 >> D (80168) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:15:03+08" >> D (80168) cellular: mux-rx-line #3: +CSQ: 21,99 >> D (80168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de >> <http://vodafone.de/> Hologram",7 >> >> Model: SIMCOM_SIM5360E >> Revision: SIM5360E_V3.5 >> D (74307) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >> D (74327) cellular: mux-rx-line #3: +CPSI: >> GSM,Online,262-02,0x011f,14822,4 EGSM 900,-69,0,38-38 >> D (74337) cellular: mux-rx-line #3: +CREG: 1,5 >> D (74337) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:19:47+08" >> D (74337) cellular: mux-rx-line #3: +CSQ: 22,99 >> D (74337) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de >> <http://vodafone.de/> Hologram",0 >> >> Model: SIMCOM_SIM7600G >> Revision: SIM7600M21-A_V2.0.1 >> D (324279) cellular: mux-tx #3: >> AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >> D (324309) cellular: mux-rx-line #3: +CPSI: >> LTE,Online,262-01,0x34B9,29268996,36,EUTRAN-BAND3,1444,3,3,-147,-1213,-889,8 >> D (324319) cellular: mux-rx-line #3: +CREG: 1,1 >> D (324319) cellular: mux-rx-line #3: +CGREG: 1,1 >> D (324319) cellular: mux-rx-line #3: +CEREG: 1,1 >> D (324319) cellular: mux-rx-line #3: +CCLK: "22/08/31,12:22:05+08" >> D (324319) cellular: mux-rx-line #3: +CSQ: 11,99 >> D (324319) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7 >> >> >> Regards, >> Michael >> >> >> Am 31.08.22 um 10:41 schrieb Mark Webb-Johnson: >>> I’ve made some further revisions. Now in latest edge -49 release. >>> >>> Grateful for feedback on this, please. Particularly with >>> SIM5360 (which should be unaffected, but …). >>> >>> Regards, Mark. >>> >>>> On 26 Aug 2022, at 10:17 PM, Michael >>>> Balzer<dexter@expeedo.de> wrote: >>>> >>>> Signed PGP part >>>> From testing on my three modules here in Germany, looks good: >>>> >>>> Model: SIMCOM_SIM7600G >>>> Revision: SIM7600M21-A_V2.0 >>>> D (151128) cellular: mux-tx #3: >>>> AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >>>> D (151158) cellular: mux-rx-line #3: +CPSI: >>>> LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-93,-1141,-864,14 >>>> D (151168) cellular: mux-rx-line #3: +CREG: 1,5 >>>> D (151168) cellular: mux-rx-line #3: +CGREG: 1,5 >>>> D (151168) cellular: mux-rx-line #3: +CEREG: 1,5 >>>> D (151168) cellular: mux-rx-line #3: +CCLK: >>>> "22/08/26,09:13:51+08" >>>> D (151168) cellular: mux-rx-line #3: +CSQ: 13,99 >>>> D (151168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de >>>> <http://vodafone.de/> Hologram",7 >>>> >>>> Model: SIMCOM_SIM5360E >>>> Revision: SIM5360E_V3.5 >>>> D (143784) cellular: mux-tx #3: >>>> AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >>>> D (143804) cellular: mux-rx-line #3: +CPSI: >>>> GSM,Online,262-02,0x011f,14822,4 EGSM 900,-66,0,41-41 >>>> D (143814) cellular: mux-rx-line #3: +CREG: 1,5 >>>> D (143814) cellular: mux-rx-line #3: +CCLK: >>>> "22/08/26,09:24:20+08" >>>> D (143814) cellular: mux-rx-line #3: +CSQ: 23,99 >>>> D (143814) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de >>>> <http://vodafone.de/> Hologram",0 >>>> >>>> Model: SIMCOM_SIM7600G >>>> Revision: SIM7600M21-A_V2.0.1 >>>> D (9625359) cellular: mux-tx #3: >>>> AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >>>> D (9625389) cellular: mux-rx-line #3: +CPSI: >>>> LTE,Online,262-01,0x34B9,29268999,268,EUTRAN-BAND8,3749,2,2,-112,-1042,-791,15 >>>> D (9625399) cellular: mux-rx-line #3: +CREG: 1,1 >>>> D (9625399) cellular: mux-rx-line #3: +CGREG: 1,1 >>>> D (9625399) cellular: mux-rx-line #3: +CEREG: 1,1 >>>> D (9625399) cellular: mux-rx-line #3: +CCLK: >>>> "22/08/26,12:40:14+08" >>>> D (9625399) cellular: mux-rx-line #3: +CSQ: 15,99 >>>> D (9625399) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7 >>>> >>>> >>>> Regards, >>>> Michael >>>> >>>> >>>> Am 26.08.22 um 08:53 schrieb Mark Webb-Johnson: >>>>> Thanks. >>>>> >>>>> I think anyone in USA using Hologram on T-Mobile would >>>>> benefit from this. I just worry I break something else. >>>>> >>>>> Regards, Mark. >>>>> >>>>>> On 26 Aug 2022, at 2:46 PM, Craig Leres<leres@xse.com> wrote: >>>>>> >>>>>> >>>>>> On 8/25/22 23:34, Mark Webb-Johnson wrote: >>>>>>> I’ve been fighting a problem for the past few months with >>>>>>> registration getting denied on T-Mobile in USA using >>>>>>> Hologram and our new 4G SIM7600G modem. Without cellular >>>>>>> connectivity at home, it hasn’t been easy to recreate >>>>>>> this, but I found a solution: >>>>>> I've been seeing intermittent netreg errors lately; I've >>>>>> booted this version on a couple of my modules... >>>>>> >>>>>> Craig >>>>> _______________________________________________ >>>>> OvmsDev mailing list >>>>> OvmsDev@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 >>>> >>>> >>>> >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@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 >> >> > > > _______________________________________________ > OvmsDev mailing list > OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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 <220904-UART-frame-errors.txt>
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
Craig, does my patch help in your case? There's another report on lost GSM communication with the latest edge release: https://www.openvehicles.com/comment/8871#comment-8871
I've been on the "edge" release for about a month now while we've been debugging the cellular issues (it's offline again now, though I know it has a perfectly clear cell signal and is in-session with the carrier, with 0 data - indicative of a firmware issue again).
Regards, Michael Am 24.09.22 um 08:42 schrieb Michael Balzer:
Am 24.09.22 um 01:21 schrieb Craig Leres:
More recently I started having issues with network registration and gnss reception; at least every few days both cars will transition from RegisteredRoaming to Searching and then back to RegisteredRoaming. They also transition from 12 satellites in view to no satellites in view and back to 12 satellites in view. For the cellular connection I might buy that a local cell tower is out of service and/or maybe my signal strength is too low. But for the gnss I can't see why this would happen, especially given that I have a satellite antenna in the garage, under the same tar-and-gravel roof as the cars, that I used for ntp synchronization (a u-blox ZED-F9T based receiver tracking four constellations...) and it never misses a beat.
Not sure if I have two different issues here or if one is related to the "SIM7600 Registration Denied" thread.
Those are typical symptoms when the UART communication gets messed up.
I had the impression splitting the status poll wouldn't help, but I only tested this on my heavily affected development module.
Maybe you'd like to give it a try on your module, patch attached. Please report -- if that helps, maybe we should add that before releasing to "main".
Regards, Michael
Am 09.09.22 um 21:00 schrieb Michael Balzer:
Regarding the UART frame errors:
1. disabling GPS doesn't change anything 2. splitting the status poll into two queries doesn't change anything 3. issuing a UART HW FIFO reset (https://github.com/espressif/esp-idf/commit/5404252e803f5489a72119a3ad41b580...) doesn't change anything 4. explicitly setting the mode to standard UART doesn't change anything 5. performing a deep sleep instead of a standard reboot doesn't change anything 6. brute force writing a cycle of all 1's and all 0's twice to the full UART1 register range before driver init doesn't change anything
Apparently, the ESP32 UART has some kind of hardware flaw leading to an ESP32 reset actually not doing a full UART reset.
* https://www.esp32.com/viewtopic.php?t=4701 * https://github.com/espressif/esp-idf/commit/5404252e803f5489a72119a3ad41b580... * https://github.com/espressif/esp-idf/commit/f482e9e54ce83e249e46f5ee082f6ffb... * …some were lucky with this patch: https://esp32.com/viewtopic.php?f=2&t=4725 …we are not.
//Due to hardware issue, we can not use fifo_rst to reset uart fifo. //See description about UART_TXFIFO_RST and UART_RXFIFO_RST in <<esp32_technical_reference_manual>> v2.6 or later.
There is apparently no method to perform a full UART HW reset, at least I haven't found one. It seems this is an issue we cannot fix (in software).
But I now don't think this is a new issue, and this also affects modules quite differently, no idea depending on what circumstances: on the current run, my car module has lots of FIFO overflows & quite some MUX framing errors, but not a single UART frame error.
IOW, I don't think we should let that block the release.
Regards, Michael
Am 09.09.22 um 14:23 schrieb Michael Balzer:
A related issue -- I remember wanting to ask this before: why do we receive all NMEA sentences three times / on three MUX channels?
Apparently they come in on channels 1, 3 and 4 -- stumbled across this again because this now leads to these also being added to a cellular command response:
OVMS# cell cmd AT+CMUX? +CMUX: 0,0,5,118,0,0,600 OK $GPRMC,114516.00,A,xxx.139223,N,xxx.391678,E,0.0,,090922,0.9,W,A*07 $GNGNS,114516.00,xxx.139223,N,xxx.391678,E,AAN,11,1.0,324.4,47.0,,,V*68
V (3388221) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) D (3388231) gsm-nmea: Incoming RMC: $GPRMC,114516.00,A,xxx.139223,N,xxx.391678,E,0.0,,090922,0.9,W,A*07 V (3388231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (3388231) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
V (3388241) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) D (3388241) gsm-nmea: Incoming GNS: $GNGNS,114516.00,xxx.139223,N,xxx.391678,E,AAN,11,1.0,324.4,47.0,,,V*68 V (3388251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (3388261) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
V (3393221) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) D (3393231) gsm-nmea: Incoming RMC: $GPRMC,114521.00,A,xxx.139223,N,xxx.391676,E,0.0,,090922,0.9,W,A*0D V (3393231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (3393231) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
V (3393241) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) D (3393241) gsm-nmea: Incoming GNS: $GNGNS,114521.00,xxx.139223,N,xxx.391676,E,AAN,11,1.0,324.4,47.0,,,V*62 V (3393251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (3393261) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
This also produces a lot of unnecessary stress on the ESP's RX buffer, doesn't it?
Channel 1 is the dedicated NMEA channel, 3 is POLL and 4 is CMD. I don't see why channels 3 & 4 are used for these by the modem, but I also cannot find any command meant to configure this.
Any idea on this?
Regards, Michael
Am 09.09.22 um 13:14 schrieb Michael Balzer:
Mark,
(am I the only one experiencing this?)
I've had multiple times of temporarily frozen modem communication over the last days on my car module. That's new, so I think we should try to fix that before releasing.
On my bench module there's a clear correlation between the extended status query and the frame errors. It's also not related to the NMEA messages, I've checked that, they come at another second.
Log excerpts below.
With frame errors responses also occasionally get corrupted, e.g. D (204251) cellular: mux-rx-line #3: Hologram",7
I think the extended status responses now very often cause an overflow on the RX buffer when coming in together. Solution could be to split the queries and distribute over 2-3 seconds.
I don't know if that will also fix the strange cold/warm boot difference with this, but maybe that's simply because the modem is faster with getting back to the network after a reboot, so the status responses become large quickly.
Regards, Michael
D (204211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (204251) gsm-mux: Frame error: EOF mismatch (CHAN=55, ADDR=df, CTRL=ff, FCS=35, LEN=133) V (204251) gsm-mux: Frame dump: f9 df ff ff bf bf dd ff f9 0d ff af 0d 0a 2b 43 | ..............+C V (204251) gsm-mux: Frame dump: 50 53 49 3a 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c | PSI: LTE,Online, V (204251) gsm-mux: Frame dump: 32 36 32 2d 30 32 2c 30 78 42 30 46 35 2c 31 33 | 262-02,0xB0F5,13 V (204251) gsm-mux: Frame dump: 31 37 39 34 31 32 2c 34 34 38 2c 45 55 54 52 41 | 179412,448,EUTRA V (204251) gsm-mux: Frame dump: 4e 2d 42 41 4e 44 31 2c 31 30 30 2c 34 2c 34 2c | N-BAND1,100,4,4, V (204251) gsm-mux: Frame dump: 2d 39 32 2c 2d 31 31 35 32 2c 2d 38 37 35 2c 31 | -92,-1152,-875,1 V (204251) gsm-mux: Frame dump: 34 0d 0a 34 f9 f9 0d ff ed 0d 0a 2b 43 52 45 47 | 4..4.......+CREG V (204251) gsm-mux: Frame dump: 3a 20 31 2c 35 0d 0a 0d 0a 2b 43 47 52 45 47 3a | : 1,5....+CGREG: V (204251) gsm-mux: Frame dump: 20 31 2c 35 0d | 1,5. V (204251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (204251) cellular: mux-rx-line #3: Hologram",7 V (208231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (208241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (208251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (208251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (208271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82)
…
V (233271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (233271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (234211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234231) gsm-mux: Frame error: EOF mismatch (CHAN=63, ADDR=ff, CTRL=ea, FCS=2c, LEN=53) V (234231) gsm-mux: Frame dump: f9 ff ea 5f ff b7 ff fd ff b9 df fd bf f9 ff fd | ..._............ V (234231) gsm-mux: Frame dump: fb ff f9 f9 a9 f9 0d ff af 0d 0a 2b 43 50 53 49 | ...........+CPSI V (234231) gsm-mux: Frame dump: 3a 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c 32 36 32 | : LTE,Online,262 V (234231) gsm-mux: Frame dump: 2d 30 32 2c 30 | -02,0 V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=a7, LEN=124) D (234241) cellular: mux-rx-line #3: +CREG: 1,5 D (234241) cellular: mux-rx-line #3: +CGREG: 1,5 D (234241) cellular: mux-rx-line #3: +CEREG: 1,5 D (234241) cellular: mux-rx-line #3: +CCLK: "22/09/09,12:52:41+08" D (234241) cellular: mux-rx-line #3: +CSQ: 13,99 V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (234251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 V (238231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (238241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78)
…
V (293251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (293251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (293271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (293271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (294211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (294211) cellular: UART frame error W (294211) cellular: UART frame error W (294211) cellular: UART frame error W (294241) gsm-mux: Frame error: EOF mismatch (CHAN=59, ADDR=ef, CTRL=db, FCS=2b, LEN=117) V (294241) gsm-mux: Frame dump: f9 ef db df ef df f7 cb f9 ff ff db 7f fd ff ff | ................ V (294241) gsm-mux: Frame dump: f9 0d ff af 0d 0a 2b 43 50 53 49 3a 20 4c 54 45 | ......+CPSI: LTE V (294241) gsm-mux: Frame dump: 2c 4f 6e 6c 69 6e 65 2c 32 36 32 2d 30 32 2c 30 | ,Online,262-02,0 V (294241) gsm-mux: Frame dump: 78 42 30 46 35 2c 31 33 31 37 39 34 31 32 2c 34 | xB0F5,13179412,4 V (294241) gsm-mux: Frame dump: 34 38 2c 45 55 54 52 41 4e 2d 42 41 4e 44 31 2c | 48,EUTRAN-BAND1, V (294241) gsm-mux: Frame dump: 31 30 30 2c 34 2c 34 2c 2d 39 36 2c 2d 31 31 35 | 100,4,4,-96,-115 V (294241) gsm-mux: Frame dump: 35 2c 2d 38 37 33 2c 31 34 0d 0a 34 f9 f9 0d ff | 5,-873,14..4.... V (294241) gsm-mux: Frame dump: ed 0d 0a 2b 43 | ...+C V (294251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (294251) cellular: mux-rx-line #3: Hologram",7 V (298231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (298241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (298241) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (298251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (298261) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (298271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
…
V (323251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (323261) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (323271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (323271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (324211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (324231) gsm-mux: Frame error: EOF mismatch (CHAN=29, ADDR=77, CTRL=fb, FCS=45, LEN=125) V (324231) gsm-mux: Frame dump: f9 77 fb ef 5f ff bb ed fb bb db ff b7 fb cf ff | .w.._........... V (324231) gsm-mux: Frame dump: bf d9 ff bb f9 0d ff b1 0d 0a 2b 43 50 53 49 3a | ..........+CPSI: V (324231) gsm-mux: Frame dump: 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c 32 36 32 2d | LTE,Online,262- V (324231) gsm-mux: Frame dump: 30 32 2c 30 78 42 30 46 35 2c 31 33 31 37 39 34 | 02,0xB0F5,131794 V (324231) gsm-mux: Frame dump: 31 32 2c 34 34 38 2c 45 55 54 52 41 4e 2d 42 41 | 12,448,EUTRAN-BA V (324241) gsm-mux: Frame dump: 4e 44 31 2c 31 30 30 2c 34 2c 34 2c 2d 31 30 39 | ND1,100,4,4,-109 V (324241) gsm-mux: Frame dump: 2c 2d 31 31 36 36 2c 2d 38 37 34 2c 31 31 0d 0a | ,-1166,-874,11.. V (324241) gsm-mux: Frame dump: c2 f9 f9 0d ff ed 0d 0a 2b 43 52 45 47 | ........+CREG V (324241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (324241) cellular: mux-rx-line #3: Hologram",7 V (328231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (328241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (328251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
…
V (353251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (353251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (353271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (353271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (354211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (354211) cellular: UART frame error W (354211) cellular: UART frame error W (354211) cellular: UART frame error W (354211) cellular: UART frame error V (354231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=34, LEN=93) D (354231) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-122,-1184,-874,9 V (354241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=a7, LEN=124) D (354241) cellular: mux-rx-line #3: +CREG: 1,5 D (354241) cellular: mux-rx-line #3: +CGREG: 1,5 D (354241) cellular: mux-rx-line #3: +CEREG: 1,5 D (354241) cellular: mux-rx-line #3: +CCLK: "22/09/09,12:54:41+08" D (354251) cellular: mux-rx-line #3: +CSQ: 13,99 V (354251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (354251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 V (358231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (358241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (358251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
Am 08.09.22 um 07:15 schrieb Mark Webb-Johnson:
Michael,
I reviewed:
$ git diff 2b25287fbef5fa968236cb8e556ea11da7c8f579 components/ovms_cellular components/simcom
But can’t see anything really related to frame errors, other than the two extra CGREG and CEREG output lines once every thirty seconds.
Maybe an existing issue re-occurring?
Do you think this should block our release of 3.3.003 to ‘main’ release?
Regards, Mark.
On 4 Sep 2022, at 4:17 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part I'm seeing an issue with the current build, but not sure if that's new & related to the latest changes or just coincidentally has become more severe somehow:
On a cold boot, modem communication is mostly fine, nearly no UART frame errors, and messages received by the modem are fine.
After the first warm reboot, initial modem messages are garbled, and lots of UART frame errors occur right from the beginning of modem communication.
This looks like some part of the serial communication now doesn't get fully reset on a reboot. Log attached.
Regards, Michael
Am 03.09.22 um 11:37 schrieb Michael Balzer: > EAP release also done on ovms.dexters-web.de > <http://ovms.dexters-web.de>. > > Regards, > Michael > > > Am 01.09.22 um 02:53 schrieb Mark Webb-Johnson: >> Sounds good. I think this is important enough to make a formal >> release so I will arrange that. >> >> I have made a 3.3.003, and released to EAP on >> api.openvehicles.com <http://api.openvehicles.com/>. We can >> target a main release for next week. >> >> Regards, Mark. >> >> P.S. I have a bunch of unrelated enhancements to CAN logging to >> commit, but those can wait. >> >>> On 31 Aug 2022, at 10:27 PM, Michael Balzer >>> <dexter@expeedo.de> wrote: >>> >>> Signed PGP part >>> Looks good: >>> >>> Model: SIMCOM_SIM7600G >>> Revision: SIM7600M21-A_V2.0 >>> D (80128) cellular: mux-tx #3: >>> AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >>> D (80158) cellular: mux-rx-line #3: +CPSI: >>> LTE,Online,262-02,0xB0F5,12829697,303,EUTRAN-BAND20,6300,3,3,-93,-969,-701,17 >>> D (80168) cellular: mux-rx-line #3: +CREG: 1,5 >>> D (80168) cellular: mux-rx-line #3: +CGREG: 1,5 >>> D (80168) cellular: mux-rx-line #3: +CEREG: 1,5 >>> D (80168) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:15:03+08" >>> D (80168) cellular: mux-rx-line #3: +CSQ: 21,99 >>> D (80168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de >>> <http://vodafone.de/> Hologram",7 >>> >>> Model: SIMCOM_SIM5360E >>> Revision: SIM5360E_V3.5 >>> D (74307) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >>> D (74327) cellular: mux-rx-line #3: +CPSI: >>> GSM,Online,262-02,0x011f,14822,4 EGSM 900,-69,0,38-38 >>> D (74337) cellular: mux-rx-line #3: +CREG: 1,5 >>> D (74337) cellular: mux-rx-line #3: +CCLK: "22/08/31,11:19:47+08" >>> D (74337) cellular: mux-rx-line #3: +CSQ: 22,99 >>> D (74337) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de >>> <http://vodafone.de/> Hologram",0 >>> >>> Model: SIMCOM_SIM7600G >>> Revision: SIM7600M21-A_V2.0.1 >>> D (324279) cellular: mux-tx #3: >>> AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >>> D (324309) cellular: mux-rx-line #3: +CPSI: >>> LTE,Online,262-01,0x34B9,29268996,36,EUTRAN-BAND3,1444,3,3,-147,-1213,-889,8 >>> D (324319) cellular: mux-rx-line #3: +CREG: 1,1 >>> D (324319) cellular: mux-rx-line #3: +CGREG: 1,1 >>> D (324319) cellular: mux-rx-line #3: +CEREG: 1,1 >>> D (324319) cellular: mux-rx-line #3: +CCLK: "22/08/31,12:22:05+08" >>> D (324319) cellular: mux-rx-line #3: +CSQ: 11,99 >>> D (324319) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7 >>> >>> >>> Regards, >>> Michael >>> >>> >>> Am 31.08.22 um 10:41 schrieb Mark Webb-Johnson: >>>> I’ve made some further revisions. Now in latest edge -49 release. >>>> >>>> Grateful for feedback on this, please. Particularly with >>>> SIM5360 (which should be unaffected, but …). >>>> >>>> Regards, Mark. >>>> >>>>> On 26 Aug 2022, at 10:17 PM, Michael >>>>> Balzer<dexter@expeedo.de> wrote: >>>>> >>>>> Signed PGP part >>>>> From testing on my three modules here in Germany, looks good: >>>>> >>>>> Model: SIMCOM_SIM7600G >>>>> Revision: SIM7600M21-A_V2.0 >>>>> D (151128) cellular: mux-tx #3: >>>>> AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >>>>> D (151158) cellular: mux-rx-line #3: +CPSI: >>>>> LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-93,-1141,-864,14 >>>>> D (151168) cellular: mux-rx-line #3: +CREG: 1,5 >>>>> D (151168) cellular: mux-rx-line #3: +CGREG: 1,5 >>>>> D (151168) cellular: mux-rx-line #3: +CEREG: 1,5 >>>>> D (151168) cellular: mux-rx-line #3: +CCLK: >>>>> "22/08/26,09:13:51+08" >>>>> D (151168) cellular: mux-rx-line #3: +CSQ: 13,99 >>>>> D (151168) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de >>>>> <http://vodafone.de/> Hologram",7 >>>>> >>>>> Model: SIMCOM_SIM5360E >>>>> Revision: SIM5360E_V3.5 >>>>> D (143784) cellular: mux-tx #3: >>>>> AT+CREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >>>>> D (143804) cellular: mux-rx-line #3: +CPSI: >>>>> GSM,Online,262-02,0x011f,14822,4 EGSM 900,-66,0,41-41 >>>>> D (143814) cellular: mux-rx-line #3: +CREG: 1,5 >>>>> D (143814) cellular: mux-rx-line #3: +CCLK: >>>>> "22/08/26,09:24:20+08" >>>>> D (143814) cellular: mux-rx-line #3: +CSQ: 23,99 >>>>> D (143814) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de >>>>> <http://vodafone.de/> Hologram",0 >>>>> >>>>> Model: SIMCOM_SIM7600G >>>>> Revision: SIM7600M21-A_V2.0.1 >>>>> D (9625359) cellular: mux-tx #3: >>>>> AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? >>>>> D (9625389) cellular: mux-rx-line #3: +CPSI: >>>>> LTE,Online,262-01,0x34B9,29268999,268,EUTRAN-BAND8,3749,2,2,-112,-1042,-791,15 >>>>> D (9625399) cellular: mux-rx-line #3: +CREG: 1,1 >>>>> D (9625399) cellular: mux-rx-line #3: +CGREG: 1,1 >>>>> D (9625399) cellular: mux-rx-line #3: +CEREG: 1,1 >>>>> D (9625399) cellular: mux-rx-line #3: +CCLK: >>>>> "22/08/26,12:40:14+08" >>>>> D (9625399) cellular: mux-rx-line #3: +CSQ: 15,99 >>>>> D (9625399) cellular: mux-rx-line #3: +COPS: 0,0," congstar",7 >>>>> >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> >>>>> Am 26.08.22 um 08:53 schrieb Mark Webb-Johnson: >>>>>> Thanks. >>>>>> >>>>>> I think anyone in USA using Hologram on T-Mobile would >>>>>> benefit from this. I just worry I break something else. >>>>>> >>>>>> Regards, Mark. >>>>>> >>>>>>> On 26 Aug 2022, at 2:46 PM, Craig Leres<leres@xse.com> wrote: >>>>>>> >>>>>>> >>>>>>> On 8/25/22 23:34, Mark Webb-Johnson wrote: >>>>>>>> I’ve been fighting a problem for the past few months with >>>>>>>> registration getting denied on T-Mobile in USA using >>>>>>>> Hologram and our new 4G SIM7600G modem. Without cellular >>>>>>>> connectivity at home, it hasn’t been easy to recreate >>>>>>>> this, but I found a solution: >>>>>>> I've been seeing intermittent netreg errors lately; I've >>>>>>> booted this version on a couple of my modules... >>>>>>> >>>>>>> Craig >>>>>> _______________________________________________ >>>>>> OvmsDev mailing list >>>>>> OvmsDev@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 >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@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 >>> >>> >> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@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 > > _______________________________________________ > OvmsDev mailing list > OvmsDev@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 <220904-UART-frame-errors.txt>
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
On 9/27/22 00:43, Michael Balzer wrote:
Craig, does my patch help in your case?
"Yes," he said cautiously. I booted with your patch almost 3 days ago and have had zero netreg issues since then. But I have had a bunch of "no satellites in view." But when this happens it usually happens with both cars around the same time (and the issue clears up at the same time as well). This makes me suspect some difference in the SIM7600 GNSS hardware vs. the signal my cars see in my garage. Or maybe a modem firmware issue since I wouldn't expect *all* satelltes to go away at the same time. I moved my dev module out to the garage on Sunday (using a spare C6 Corvette onstar antenna brick for cell and GNSS) but I didn't get it instrumented until a few hours ago so I don't have history for it yet. But I'm expecting it to track whatever problems the other two modules have.
There's another report on lost GSM communication with the latest edge release: https://www.openvehicles.com/comment/8871#comment-8871
To me that thread covers two out of three of my issues; canbus and GSM. I took a look at the logs for one module and it looks like there is some correlation between satcount=0 and not being able to connect to the v2 and v3 servers; this happened at 4:54 and 5:36 PDT today, I'll attach logs for today. The repeated "mongoose: mg_ssl_if_mbed_err ... SSL error: -1" errors caught my eye. Oh and I notice now that when satcount=0, gpshdop=500 (I didn't know it could go so high!) Craig
So FYI, I've got an Optus (Australia) Sim successfully working with upstream 3.3.003-5-gb70e4e3a plus my ioniq 5 mods (so nothing Sim related). //. On Wed, 28 Sept 2022 at 05:09, Craig Leres <leres@xse.com> wrote:
On 9/27/22 00:43, Michael Balzer wrote:
Craig, does my patch help in your case?
"Yes," he said cautiously. I booted with your patch almost 3 days ago and have had zero netreg issues since then. But I have had a bunch of "no satellites in view." But when this happens it usually happens with both cars around the same time (and the issue clears up at the same time as well). This makes me suspect some difference in the SIM7600 GNSS hardware vs. the signal my cars see in my garage. Or maybe a modem firmware issue since I wouldn't expect *all* satelltes to go away at the same time. I moved my dev module out to the garage on Sunday (using a spare C6 Corvette onstar antenna brick for cell and GNSS) but I didn't get it instrumented until a few hours ago so I don't have history for it yet. But I'm expecting it to track whatever problems the other two modules have.
There's another report on lost GSM communication with the latest edge release: https://www.openvehicles.com/comment/8871#comment-8871
To me that thread covers two out of three of my issues; canbus and GSM.
I took a look at the logs for one module and it looks like there is some correlation between satcount=0 and not being able to connect to the v2 and v3 servers; this happened at 4:54 and 5:36 PDT today, I'll attach logs for today. The repeated "mongoose: mg_ssl_if_mbed_err ... SSL error: -1" errors caught my eye.
Oh and I notice now that when satcount=0, gpshdop=500 (I didn't know it could go so high!)
Craig
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On 9/27/22 14:08, Craig Leres wrote:
I moved my dev module out to the garage on Sunday (using a spare C6 Corvette onstar antenna brick for cell and GNSS) but I didn't get it instrumented until a few hours ago so I don't have history for it yet. But I'm expecting it to track whatever problems the other two modules have.
This happened this morning (all three modules saw satcount=0 around 9am PDT). Craig
So that has some external cause. Possibly some EM interference from a poorly shielded device nearby that runs at that time. 9am -- breakfast time? Microwave ovens have a history of that kind of issues… https://www.emf-portal.org/en/emf-source/603 Regards, Michael Am 29.09.22 um 00:10 schrieb Craig Leres:
On 9/27/22 14:08, Craig Leres wrote:
I moved my dev module out to the garage on Sunday (using a spare C6 Corvette onstar antenna brick for cell and GNSS) but I didn't get it instrumented until a few hours ago so I don't have history for it yet. But I'm expecting it to track whatever problems the other two modules have.
This happened this morning (all three modules saw satcount=0 around 9am PDT).
Craig
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 9/27/22 14:08, Craig Leres wrote:
"Yes," he said cautiously. I booted with your patch almost 3 days ago and have had zero netreg issues since then.
Ok, my "dev" module has seen a couple netreg failures over the last few days. All three of my modules are using sim7600 modems with hologram.io sims. Meanwhile the two modules in cars have been clean since booting your patch. Craig
Everyone, I've pushed a generalized version of the patch extended towards SIM5360, as this can as well have been the cause of irregular issues on the SIM5360. While the SIM5360 has a smaller footprint on the status poll responses, they still add up to ~150 bytes. Additionally, the SIM5360 does not allow to change the NMEA update frequency, it always sends all subscribed sentences once per second. Please test & report any issues or improvements you see. Regards, Michael Am 02.10.22 um 04:16 schrieb Craig Leres:
On 9/27/22 14:08, Craig Leres wrote:
"Yes," he said cautiously. I booted with your patch almost 3 days ago and have had zero netreg issues since then.
Ok, my "dev" module has seen a couple netreg failures over the last few days. All three of my modules are using sim7600 modems with hologram.io sims. Meanwhile the two modules in cars have been clean since booting your patch.
Craig
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I've modified one of the IDF examples to talk to our modem and do regular restarts and found this: The test application shows no frame errors, regardless of the number of resets if performs. But: if I first flash the OVMS, do a "module reset", then flash & run the test application, all without power interruption, the test application suddenly also shows the frame errors & corrupted characters: I (13868) TX_TASK: Wrote 39 bytes W (13868) uart_events: uart frame error W (13868) uart_events: uart frame error W (13868) uart_events: uart frame error I (13868) uart_events: [UART DATA]: 3: «í I also found out it doesn't matter if I do the reset in software or by pushing S1. The effect remains until the next cold boot. So it seems something we do (some hardware configuration) has a side effect that persists over resets and begins interfering with the UART after the first reset. I thought maybe we have some bug in our UART driver setup, and fixed some issues I found, but that didn't help. My next suspect was the SD card, but excluding that didn't change anything. Espressif are aware of the UART not resetting properly, there are multiple open issue tickets, but there has been no progress for about two years on this. But the effect only showing after a full OVMS boot means there might be a workaround. Attached is the test application, in case anyone wants to experiment with this. Regards, Michael PS: as a side benefit from my investigation, I also found out how to get the SIMCOM 7600 to only send NMEA sentences on one MUX channel (→ commit 8f49ecab01617414c89b1e3ffa70c79e0115fe95). Am 09.09.22 um 21:00 schrieb Michael Balzer:
Regarding the UART frame errors:
1. disabling GPS doesn't change anything 2. splitting the status poll into two queries doesn't change anything 3. issuing a UART HW FIFO reset (https://github.com/espressif/esp-idf/commit/5404252e803f5489a72119a3ad41b580...) doesn't change anything 4. explicitly setting the mode to standard UART doesn't change anything 5. performing a deep sleep instead of a standard reboot doesn't change anything 6. brute force writing a cycle of all 1's and all 0's twice to the full UART1 register range before driver init doesn't change anything
Apparently, the ESP32 UART has some kind of hardware flaw leading to an ESP32 reset actually not doing a full UART reset.
* https://www.esp32.com/viewtopic.php?t=4701 * https://github.com/espressif/esp-idf/commit/5404252e803f5489a72119a3ad41b580... * https://github.com/espressif/esp-idf/commit/f482e9e54ce83e249e46f5ee082f6ffb... * …some were lucky with this patch: https://esp32.com/viewtopic.php?f=2&t=4725 …we are not.
//Due to hardware issue, we can not use fifo_rst to reset uart fifo. //See description about UART_TXFIFO_RST and UART_RXFIFO_RST in <<esp32_technical_reference_manual>> v2.6 or later.
There is apparently no method to perform a full UART HW reset, at least I haven't found one. It seems this is an issue we cannot fix (in software).
But I now don't think this is a new issue, and this also affects modules quite differently, no idea depending on what circumstances: on the current run, my car module has lots of FIFO overflows & quite some MUX framing errors, but not a single UART frame error.
IOW, I don't think we should let that block the release.
Regards, Michael
Am 09.09.22 um 14:23 schrieb Michael Balzer:
A related issue -- I remember wanting to ask this before: why do we receive all NMEA sentences three times / on three MUX channels?
Apparently they come in on channels 1, 3 and 4 -- stumbled across this again because this now leads to these also being added to a cellular command response:
OVMS# cell cmd AT+CMUX? +CMUX: 0,0,5,118,0,0,600 OK $GPRMC,114516.00,A,xxx.139223,N,xxx.391678,E,0.0,,090922,0.9,W,A*07 $GNGNS,114516.00,xxx.139223,N,xxx.391678,E,AAN,11,1.0,324.4,47.0,,,V*68
V (3388221) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) D (3388231) gsm-nmea: Incoming RMC: $GPRMC,114516.00,A,xxx.139223,N,xxx.391678,E,0.0,,090922,0.9,W,A*07 V (3388231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (3388231) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
V (3388241) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) D (3388241) gsm-nmea: Incoming GNS: $GNGNS,114516.00,xxx.139223,N,xxx.391678,E,AAN,11,1.0,324.4,47.0,,,V*68 V (3388251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (3388261) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
V (3393221) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) D (3393231) gsm-nmea: Incoming RMC: $GPRMC,114521.00,A,xxx.139223,N,xxx.391676,E,0.0,,090922,0.9,W,A*0D V (3393231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (3393231) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
V (3393241) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) D (3393241) gsm-nmea: Incoming GNS: $GNGNS,114521.00,xxx.139223,N,xxx.391676,E,AAN,11,1.0,324.4,47.0,,,V*62 V (3393251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (3393261) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
This also produces a lot of unnecessary stress on the ESP's RX buffer, doesn't it?
Channel 1 is the dedicated NMEA channel, 3 is POLL and 4 is CMD. I don't see why channels 3 & 4 are used for these by the modem, but I also cannot find any command meant to configure this.
Any idea on this?
Regards, Michael
Am 09.09.22 um 13:14 schrieb Michael Balzer:
Mark,
(am I the only one experiencing this?)
I've had multiple times of temporarily frozen modem communication over the last days on my car module. That's new, so I think we should try to fix that before releasing.
On my bench module there's a clear correlation between the extended status query and the frame errors. It's also not related to the NMEA messages, I've checked that, they come at another second.
Log excerpts below.
With frame errors responses also occasionally get corrupted, e.g. D (204251) cellular: mux-rx-line #3: Hologram",7
I think the extended status responses now very often cause an overflow on the RX buffer when coming in together. Solution could be to split the queries and distribute over 2-3 seconds.
I don't know if that will also fix the strange cold/warm boot difference with this, but maybe that's simply because the modem is faster with getting back to the network after a reboot, so the status responses become large quickly.
Regards, Michael
D (204211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (204251) gsm-mux: Frame error: EOF mismatch (CHAN=55, ADDR=df, CTRL=ff, FCS=35, LEN=133) V (204251) gsm-mux: Frame dump: f9 df ff ff bf bf dd ff f9 0d ff af 0d 0a 2b 43 | ..............+C V (204251) gsm-mux: Frame dump: 50 53 49 3a 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c | PSI: LTE,Online, V (204251) gsm-mux: Frame dump: 32 36 32 2d 30 32 2c 30 78 42 30 46 35 2c 31 33 | 262-02,0xB0F5,13 V (204251) gsm-mux: Frame dump: 31 37 39 34 31 32 2c 34 34 38 2c 45 55 54 52 41 | 179412,448,EUTRA V (204251) gsm-mux: Frame dump: 4e 2d 42 41 4e 44 31 2c 31 30 30 2c 34 2c 34 2c | N-BAND1,100,4,4, V (204251) gsm-mux: Frame dump: 2d 39 32 2c 2d 31 31 35 32 2c 2d 38 37 35 2c 31 | -92,-1152,-875,1 V (204251) gsm-mux: Frame dump: 34 0d 0a 34 f9 f9 0d ff ed 0d 0a 2b 43 52 45 47 | 4..4.......+CREG V (204251) gsm-mux: Frame dump: 3a 20 31 2c 35 0d 0a 0d 0a 2b 43 47 52 45 47 3a | : 1,5....+CGREG: V (204251) gsm-mux: Frame dump: 20 31 2c 35 0d | 1,5. V (204251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (204251) cellular: mux-rx-line #3: Hologram",7 V (208231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (208241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (208251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (208251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (208271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82)
…
V (233271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (233271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (234211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234211) cellular: UART frame error W (234231) gsm-mux: Frame error: EOF mismatch (CHAN=63, ADDR=ff, CTRL=ea, FCS=2c, LEN=53) V (234231) gsm-mux: Frame dump: f9 ff ea 5f ff b7 ff fd ff b9 df fd bf f9 ff fd | ..._............ V (234231) gsm-mux: Frame dump: fb ff f9 f9 a9 f9 0d ff af 0d 0a 2b 43 50 53 49 | ...........+CPSI V (234231) gsm-mux: Frame dump: 3a 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c 32 36 32 | : LTE,Online,262 V (234231) gsm-mux: Frame dump: 2d 30 32 2c 30 | -02,0 V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=a7, LEN=124) D (234241) cellular: mux-rx-line #3: +CREG: 1,5 D (234241) cellular: mux-rx-line #3: +CGREG: 1,5 D (234241) cellular: mux-rx-line #3: +CEREG: 1,5 D (234241) cellular: mux-rx-line #3: +CCLK: "22/09/09,12:52:41+08" D (234241) cellular: mux-rx-line #3: +CSQ: 13,99 V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (234251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 V (238231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (238241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78)
…
V (293251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (293251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (293271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (293271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (294211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (294211) cellular: UART frame error W (294211) cellular: UART frame error W (294211) cellular: UART frame error W (294241) gsm-mux: Frame error: EOF mismatch (CHAN=59, ADDR=ef, CTRL=db, FCS=2b, LEN=117) V (294241) gsm-mux: Frame dump: f9 ef db df ef df f7 cb f9 ff ff db 7f fd ff ff | ................ V (294241) gsm-mux: Frame dump: f9 0d ff af 0d 0a 2b 43 50 53 49 3a 20 4c 54 45 | ......+CPSI: LTE V (294241) gsm-mux: Frame dump: 2c 4f 6e 6c 69 6e 65 2c 32 36 32 2d 30 32 2c 30 | ,Online,262-02,0 V (294241) gsm-mux: Frame dump: 78 42 30 46 35 2c 31 33 31 37 39 34 31 32 2c 34 | xB0F5,13179412,4 V (294241) gsm-mux: Frame dump: 34 38 2c 45 55 54 52 41 4e 2d 42 41 4e 44 31 2c | 48,EUTRAN-BAND1, V (294241) gsm-mux: Frame dump: 31 30 30 2c 34 2c 34 2c 2d 39 36 2c 2d 31 31 35 | 100,4,4,-96,-115 V (294241) gsm-mux: Frame dump: 35 2c 2d 38 37 33 2c 31 34 0d 0a 34 f9 f9 0d ff | 5,-873,14..4.... V (294241) gsm-mux: Frame dump: ed 0d 0a 2b 43 | ...+C V (294251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (294251) cellular: mux-rx-line #3: Hologram",7 V (298231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (298241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (298241) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (298251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (298261) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (298271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82)
…
V (323251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (323261) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (323271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (323271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (324211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (324231) gsm-mux: Frame error: EOF mismatch (CHAN=29, ADDR=77, CTRL=fb, FCS=45, LEN=125) V (324231) gsm-mux: Frame dump: f9 77 fb ef 5f ff bb ed fb bb db ff b7 fb cf ff | .w.._........... V (324231) gsm-mux: Frame dump: bf d9 ff bb f9 0d ff b1 0d 0a 2b 43 50 53 49 3a | ..........+CPSI: V (324231) gsm-mux: Frame dump: 20 4c 54 45 2c 4f 6e 6c 69 6e 65 2c 32 36 32 2d | LTE,Online,262- V (324231) gsm-mux: Frame dump: 30 32 2c 30 78 42 30 46 35 2c 31 33 31 37 39 34 | 02,0xB0F5,131794 V (324231) gsm-mux: Frame dump: 31 32 2c 34 34 38 2c 45 55 54 52 41 4e 2d 42 41 | 12,448,EUTRAN-BA V (324241) gsm-mux: Frame dump: 4e 44 31 2c 31 30 30 2c 34 2c 34 2c 2d 31 30 39 | ND1,100,4,4,-109 V (324241) gsm-mux: Frame dump: 2c 2d 31 31 36 36 2c 2d 38 37 34 2c 31 31 0d 0a | ,-1166,-874,11.. V (324241) gsm-mux: Frame dump: c2 f9 f9 0d ff ed 0d 0a 2b 43 52 45 47 | ........+CREG V (324241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (324241) cellular: mux-rx-line #3: Hologram",7 V (328231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (328241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (328251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
…
V (353251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78) V (353251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=b1, LEN=82) V (353271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=f4, LEN=82) V (353271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f9, LEN=82) D (354211) cellular: mux-tx #3: AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS? W (354211) cellular: UART frame error W (354211) cellular: UART frame error W (354211) cellular: UART frame error W (354211) cellular: UART frame error V (354231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=34, LEN=93) D (354231) cellular: mux-rx-line #3: +CPSI: LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-122,-1184,-874,9 V (354241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=a7, LEN=124) D (354241) cellular: mux-rx-line #3: +CREG: 1,5 D (354241) cellular: mux-rx-line #3: +CGREG: 1,5 D (354241) cellular: mux-rx-line #3: +CEREG: 1,5 D (354241) cellular: mux-rx-line #3: +CCLK: "22/09/09,12:54:41+08" D (354251) cellular: mux-rx-line #3: +CSQ: 13,99 V (354251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=da, LEN=25) D (354251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de Hologram",7 V (358231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff, FCS=bf, LEN=78) V (358241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=fa, LEN=78) V (358251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=f7, LEN=78)
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
participants (4)
-
Craig Leres -
Mark Webb-Johnson -
Michael Balzer -
Michael Geddes