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

Info info at zeitnitz.eu
Sun Mar 30 19:08:35 HKT 2025 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250330/828adf16/attachment-0001.htm>

More information about the OvmsDev mailing list