[Ovmsdev] Integration of Simcom 7670 and changes to Simcom Powering

Michael Balzer dexter at expeedo.de
Sun Mar 30 23:31:54 HKT 2025


Christian,

this looks very good now. I've mistreated my test modules in all ways I 
could think of including switching off the running modem via S1, the 
cellular system recovered nicely from all situations.

Regards,
Michael


Am 30.03.25 um 16:01 schrieb Info via OvmsDev:
> Hi Michael,
> I think I found the problem which caused the 5360 not to powercycle 
> correctly. Actually the T_on time was in that instance set to 
> 1126913089 ms, so this will take a while!
> This was caused by a stupid mistake with an incorrect modulo 
> calculation of the timing index .
>
> I fixed the unused variables as well.
>
> Best regards
>    Christian
>
>
>
>
> Am 30.03.2025 um 14:26 schrieb Michael Balzer via OvmsDev:
>> PS: please fix the two unused variables now in gsmnmea.cpp:
>>
>> /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_cellular/src/gsmnmea.cpp: 
>> In member function 'void GsmNMEA::IncomingLine(std::__cxx11::string)':
>> /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_cellular/src/gsmnmea.cpp:148:40: 
>> warning: variable 'vdop' set but not used [-Wunused-but-set-variable]
>>      float lat=0, lon=0, alt=0, hdop=0, vdop=0, pdop=0;
>>                                         ^
>> /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_cellular/src/gsmnmea.cpp:148:48: 
>> warning: variable 'pdop' set but not used [-Wunused-but-set-variable]
>>      float lat=0, lon=0, alt=0, hdop=0, vdop=0, pdop=0;
>>                                                 ^
>>
>> Regards,
>> Michael
>>
>>
>> Am 30.03.25 um 14:21 schrieb Michael Balzer via OvmsDev:
>>> Christian,
>>>
>>> the user way to power off/on the modem is via "power cellular 
>>> off/on", that's what I test/ed, and that works.
>>>
>>> After having no issues now with the 7600, I did the tests with my 
>>> old 5360 module.
>>>
>>> That generally also worked, with one exception: on one of four crash 
>>> reboots, the cellular system got stuck in PowerOffOn state, with 
>>> state ticker at 0 and no more activity.
>>>
>>> Logs attached.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 30.03.25 um 13:08 schrieb Info via OvmsDev:
>>>> Michael,
>>>> one more thing: if you are performing another test, please check 
>>>> from the console, that the powering of the modem works as well.
>>>>
>>>> cellular setstate PoweringOff
>>>> cellular setstate PoweringOn
>>>>
>>>> It did not work when I started with the 7670 and I had to modify 
>>>> ovms_cellular (set m_powermode according to the state) to get it going.
>>>>
>>>> Thanks
>>>>   Christian
>>>>
>>>>
>>>>
>>>> Am 30.03.2025 um 12:02 schrieb Info via OvmsDev:
>>>>> OK, thanks Michael.
>>>>> At least this was an easy fix.
>>>>>
>>>>> Had a look at the NMEA code and I screwed up the istringstream 
>>>>> object when checking for the CGNSSINFO string.
>>>>> Fixed it and I hope this works now as well.
>>>>>
>>>>> Best regards
>>>>>   Christian
>>>>>
>>>>>
>>>>>
>>>>> Am 29.03.2025 um 18:42 schrieb Michael Balzer via OvmsDev:
>>>>>> Christian,
>>>>>>
>>>>>> the GSM/PPP part now works smoothly with all standard situations 
>>>>>> tested so far.
>>>>>>
>>>>>> But the GPS part doesn't work. It looks like the NMEA sentences 
>>>>>> are received in the MUX channel, but not forwarded to the NMEA 
>>>>>> module.
>>>>>>
>>>>>> V (794230) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, 
>>>>>> FCS=fa, LEN=78)
>>>>>> V (794230) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, 
>>>>>> FCS=f4, LEN=82)
>>>>>>
>>>>>> These should be the NMEA sentences, but there are no 
>>>>>> corresponding log entries from gsm-nmea.
>>>>>>
>>>>>> New logs attached.
>>>>>>
>>>>>> Regards,
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> Am 29.03.25 um 15:13 schrieb Info via OvmsDev:
>>>>>>> Hi Michael,
>>>>>>> thanks for testing.
>>>>>>>
>>>>>>> The results look odd, so I went back to the schematics of OVMS 
>>>>>>> modules and realized, that I was mistaken. The PWRKEY pin is 
>>>>>>> actually inverted in the modules as well. This definetly 
>>>>>>> explains the strange behaviour.
>>>>>>>
>>>>>>> I changed now the logic in simcom_powering.h and the inverted 
>>>>>>> PWRKEY level is now the default.
>>>>>>>
>>>>>>> Could you please run another test?
>>>>>>>
>>>>>>> Best regards
>>>>>>>   Christian
>>>>>>>
>>>>>>> Am 29.03.2025 um 09:25 schrieb Michael Balzer via OvmsDev:
>>>>>>>> Christian,
>>>>>>>>
>>>>>>>> well done on the 7670 support :-)
>>>>>>>>
>>>>>>>> I've just done some first tests of your branch on the 7600, 
>>>>>>>> which turned up some issues. Logs attached:
>>>>>>>>
>>>>>>>>   * Cold boot failed in 2 of 3 test boots, with the driver
>>>>>>>>     getting stuck in a loop (poweredon / identify / muxstart)
>>>>>>>>   * Regular shutdown fails to power down the modem in time --
>>>>>>>>     for a deep sleep phase, this would mean the modem will
>>>>>>>>     remain powered on
>>>>>>>>   * After a crash, the modem driver gets somehow stuck in
>>>>>>>>     PowerOffOn state
>>>>>>>>
>>>>>>>> It seems the test for reaction ("AT") sometimes gets skipped, 
>>>>>>>> even though the modem isn't ready yet.
>>>>>>>>
>>>>>>>> On the failed cold boot log, you can see this at the end:
>>>>>>>>
>>>>>>>> *I (389178) cellular-modem-auto: Power Cycle*
>>>>>>>> I (389178) Simcom: Power Cycle - T_off 2500 ms - T_on 200 ms
>>>>>>>> D (389178) events: Signal(system.modem.poweringon)
>>>>>>>> D (389188) events: Signal(egpio.output.0.low)
>>>>>>>> D (391678) events: Signal(egpio.output.0.high)
>>>>>>>> D (396678) events: Signal(egpio.output.0.low)
>>>>>>>> D (396878) events: Signal(egpio.output.0.high)
>>>>>>>> *I (396878) cellular: State: Enter Identify state
>>>>>>>> D (396978) cellular: tx-cmd: AT+CGMM*
>>>>>>>> D (396978) cellular: tx-cmd: AT+CGMM
>>>>>>>> D (396978) cellular: tx-cmd: AT+CGMM
>>>>>>>> D (396978) cellular: tx-cmd: AT+CGMM
>>>>>>>> D (396978) cellular: tx-cmd: AT+CGMM
>>>>>>>> D (396978) cellular: tx-cmd: AT+CGMM
>>>>>>>> D (396978) cellular: tx-cmd: AT+CGMM
>>>>>>>> I (397008) cellular: Identified cellular modem: 
>>>>>>>> SIM7600/Experimental support for SIMCOM SIM7600
>>>>>>>> D (397008) cellular: Remove old 'auto' modem driver
>>>>>>>> I (397008) cellular: Set modem driver to 'SIM7600'
>>>>>>>> *I (397008) cellular: State: Enter PoweredOn state*
>>>>>>>> D (397008) events: Signal(system.modem.installed)
>>>>>>>> D (397008) events: Signal(system.modem.poweredon)
>>>>>>>> D (406178) cellular: tx-cmd: 
>>>>>>>> AT+CPIN?;+CREG=1;+CGREG=1;+CEREG=1;+CTZU=1;+CTZR=1;+CLIP=1;+CMGF=1;+CNMI=1,2,0,0,0;+CSDH=1;+CMEE=2;+CSQ;+AUTOCSQ=1,1;E0;S0=0
>>>>>>>> D (408178) cellular: tx-cmd: AT+CGMR;+ICCID
>>>>>>>> D (416178) cellular: tx-cmd: AT+CMUX=0;+CATR=6
>>>>>>>> D (434808) cellular: mux-rx-line #0 (2/46): OK
>>>>>>>> *D (434808) cellular: mux-rx-line #0 (3/39): RDY*
>>>>>>>> D (434808) cellular: mux-rx-line #0 (12/23): +CPIN: READY
>>>>>>>> D (434808) cellular: mux-rx-line #0 (8/11): SMS DONE
>>>>>>>> D (434808) cellular: mux-rx-line #0 (7/0): PB DONE
>>>>>>>> I (434808) cellular: State: Enter MuxStart state
>>>>>>>> D (434808) events: Signal(system.modem.muxstart)
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 26.03.25 um 13:13 schrieb Info Zeitnitz via OvmsDev:
>>>>>>>>> Dear all,
>>>>>>>>> I finished to integrate the Simcom 7670 modem into the OVMS code.
>>>>>>>>> See 
>>>>>>>>> https://github.com/zbchristian/Open-Vehicle-Monitoring-System-3.git 
>>>>>>>>> branch update_cellular.
>>>>>>>>>
>>>>>>>>> Modem Powering
>>>>>>>>> ===============
>>>>>>>>> I had problems to get the 7670 working with the current code. 
>>>>>>>>> The modem was stuck in a power cycle loop.
>>>>>>>>>
>>>>>>>>> I checked the Simcom documentation for the 4 models 5360, 7000 
>>>>>>>>> series, 7600, 7670 and the powering procedure via the PWRKEY 
>>>>>>>>> pin is the same, but with different on/off timing. Depending 
>>>>>>>>> on the hardware, the PWRKEY can be inverted as well. This is 
>>>>>>>>> the case for my Lilygo TCall board, but I think not for the 
>>>>>>>>> OVMS HW versions. At least version 3.1 connects the 
>>>>>>>>> corresponding MAX7317 pin directly to the modem.
>>>>>>>>>
>>>>>>>>> Assuming, that all hardware versions use the PWRKEY procedure 
>>>>>>>>> for powering, I streamlined the code and moved the 
>>>>>>>>> corresponding functions into separate files 
>>>>>>>>> (simcom_powering.cpp and simcom_powering.h). This avoids the 
>>>>>>>>> duplication of the code.
>>>>>>>>>
>>>>>>>>> All this leads to substantial changes in ovms_cellular and 
>>>>>>>>> ovms_cellular_modem_driver as well.
>>>>>>>>>
>>>>>>>>> The code works now perfectly for the 7670, but testing is 
>>>>>>>>> required for all other models.
>>>>>>>>> If my assumptions about the OVMS HW versions are not correct, 
>>>>>>>>> or the modems do not work as documented, some modifications 
>>>>>>>>> might be needed.
>>>>>>>>>
>>>>>>>>> GNSS Location
>>>>>>>>> ============
>>>>>>>>> The 7670 no longer accepts the currently used AT commands to 
>>>>>>>>> obtain the location  as a GRMC sentence. So, I added code to 
>>>>>>>>> the new 7670 class to request the location via the 
>>>>>>>>> AT+CGNSSINFO command.
>>>>>>>>> Since this has to be send explicitly again and again,  I 
>>>>>>>>> implemented a corresponding call in the StatusPoller of the 7670.
>>>>>>>>> All the NMEA related code has been adapted to handle the 
>>>>>>>>> corresponding CGNSSINFO response.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In conclusion, before doing a pull request, it would make 
>>>>>>>>> sense that the code is tested with the other hardware and 
>>>>>>>>> modem models.
>>>>>>>>>
>>>>>>>>> So, tell me what you think and if the general strategy of the 
>>>>>>>>> mods make sense to you.
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>>   Christian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OvmsDev mailing list
>>>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
>>>>>>>> Fon 02330 9104094 * Handy 0176 20698926
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OvmsDev mailing list
>>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>
>>>>>> -- 
>>>>>> Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
>>>>>> Fon 02330 9104094 * Handy 0176 20698926
>>>>>>
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>> -- 
>>> Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
>>> Fon 02330 9104094 * Handy 0176 20698926
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> -- 
>> Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
>> Fon 02330 9104094 * Handy 0176 20698926
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250330/bb958898/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250330/bb958898/attachment-0001.sig>


More information about the OvmsDev mailing list