[Ovmsdev] SIM7600 Registration Denied

Sat Sep 24 14:42:43 HKT 2022

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/5404252e803f5489a72119a3ad41b580f2881a2a)
>     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/5404252e803f5489a72119a3ad41b580f2881a2a
>   * https://github.com/espressif/esp-idf/commit/f482e9e54ce83e249e46f5ee082f6ffb61431339
>   * …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 at 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 at 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 at 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 at 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 at lists.openvehicles.com
>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>>>> --
>>>>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OvmsDev mailing list
>>>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>
>>>>>> -- 
>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>>
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>
>>>>> -- 
>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>> <220904-UART-frame-errors.txt>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>> -- 
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20220924/86cf4bf7/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simcom-poll-split.diff
Type: text/x-patch
Size: 2472 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20220924/86cf4bf7/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20220924/86cf4bf7/attachment-0001.sig>