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
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev