[Ovmsdev] SIM7600 Registration Denied
Michael Balzer
dexter at expeedo.de
Tue Sep 27 15:43:43 HKT 2022
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/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
>
> _______________________________________________
> 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/20220927/87b5c2a1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20220927/87b5c2a1/attachment-0001.sig>
More information about the OvmsDev
mailing list