Hi Michael, great! Thanks a lot for your effort and patience. I first thought, that debugging the code without direct access to the hardware would be very difficult, but this really worked out fine. So, I will issue a PR. Best regards Christian Am 30.03.2025 um 17:31 schrieb Michael Balzer via OvmsDev:
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@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@lists.openvehicles.com >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@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@lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev