March 2022 - OvmsDev - Open Vehicles

Netmanager priority issue solved
by Michael Balzer 05 Jul '23

05 Jul '23

TL;DR: you need to pull my latest esp-idf changes. I've finally found & solved the strange priority changes for our netmanager task (i.e. being raised suddenly from origin 5 to 18/22): the bug was in the esp-idf posix threads mutex implementation. I had suspected the mutex priority inheritance for a while, so added a way to retrieve the internal mutex hold count for our task list. Using this I noticed the hold count would always & only raise by 2 whenever any kind of mongoose connection was closed. That lead me to checking the thread concurrency protection for mongoose mbufs, because every mongoose connection has two mbufs associated (rx & tx), each having a posix mutex. The bug was: posix mutexes were deleted after locking (taking) them. FreeRTOS mutexes must not be deleted while being taken, that breaks the priority inheritance (more precisely the disinheritance), with the visible effect being the mutex hold count not returning to zero. As a side effect, this may also solve the strange event task starvations (hope so…). I was investigating this as I suspected some busy loop in the netmanager context. With the netman running at prio 22, that would effectively block almost all other processing including the timer service. I've found & fixed one potential busy loop trigger in the netman that would have been caused by the netman task still running while all interfaces had been lost -- not sure if that could happen, but it would explain the effects. So please watch your crash debug info & report if the issue still turns up. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 19

Fiat500e Quirks
by William Reading 19 Nov '22

19 Nov '22

Howdy there, I recently got an OVMS set up with my Fiat 500e and was happy to see that it works, but I noticed noticed a few oddities. The first one is that it uses Valet Mode (CommandActivateValet) for preconditioning instead of CommandClimateControl: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/bd192… <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/bd192…> Is there a downside to changing the code to where it uses Climate Control instead? It seems like that would fit better with the intended functionality. The other is that it seems to rapidly generate spurious charging / not charging events, which en masse seems to make the websocket connection on the web server time out. I can put together a pull request to try to fix these issues, but was wondering if there are any thoughts on these two things before getting started. There's also no pictures of the Fiat on the iOS App, but I assume that's because the last release of the iOS App predates support. Thanks, William Reading

2 3

IOS app reported GSM signal strength
by Craig Leres 17 Oct '22

17 Oct '22

I've noticed for awhile but never asked the question; why does the IOS app report wifi signal strength when I'm connected to wifi as gsm signal strength? I would expect gsm to always be gsm and maybe wifi would also be shown (and identified as such) when present. Note that I run my modules in wifi client-only mode. Craig

2 2

Not processing canbus frames anymore
by Craig Leres 24 Sep '22

24 Sep '22

I have a v3.3 module in my Corvette and recently got it back on the road but I find that following the sim7600 modem testing I did a few weeks ago, it doesn't seem to be processing canbus frames. When the car is running, the module does not appear to update soc or vin although this used to work. Comparing "module sum" between it and my Cadillac turned up something extra in the [vehicle] section: [vehicle] 12v.alert: 12v.ref: - id: RF059 + id: 768V name: timezone: PST8PDT,M3.2.0,M11.1.0 timezone_region: America/Los_Angeles - type: CHEVROLET_C6_CORVETTE units.distance: M While the [auto] section only has expected differences: [auto] @@ -38,9 +44,9 @@ scripting: yes server.v2: yes server.v3: yes - vehicle.type: C6CORVETTE + vehicle.type: C2CTS wifi.mode: client - wifi.ssid.ap: RF059 + wifi.ssid.ap: 768V wifi.ssid.client: Team America I don't really remember/know how to quickly monitor the canbus but with the car running it *seems* to be seeing canbus frames: OVMS# can log start monitor crtd CAN logging to MONITOR active: Type:monitor Format:crtd(discard) Vehicle:C6CORVETTE Note: info logging is at debug log level, frame logging is at verbose, and errors as usual OVMS# can log status #1: open Type:monitor Format:crtd(discard) Vehicle:C6CORVETTE Messages:7240 Dropped:0 Filtered:0 Rate:0.0% MONITOR: running Messages:7240 Discarded:0 Dropped:0 Filtered:0 Rate:0.0% OVMS# can log status #1: open Type:monitor Format:crtd(discard) Vehicle:C6CORVETTE Messages:11447 Dropped:0 Filtered:0 Rate:0.0% MONITOR: running Messages:11447 Discarded:0 Dropped:0 Filtered:0 Rate:0.0% OVMS# can list can1: Active/500000 dbc none can2: Off/1000000 dbc none can3: Off/1000000 dbc none Any suggestions on how to figure out what I'm doing wrong? Craig

5 20

GPS flatbed alerts from military jamming/spoofing?
by Michael Balzer 29 Apr '22

29 Apr '22

I've had no GPS false alerts since Craig added the NMEA checksum validation and I fixed the VW e-Up state detection. That is, until war on Ukraine began. Since then, I've had multiple alerts, mostly late night. I wouldn't have thought military GPS jamming or spoofing would have an effect with that range, the next war region is ~ 1.200 km from here. I've added some more logging to see if we can detect and filter this. Reduced log from the latest event below. HDOP jumps from 1.8 (good) to 5.6 (bad), but only after the alert has been triggered. Should we generally scale the alarm threshold by HDOP (if available)? Regards, Michael 01:31:35 vehicle dist=15 smoothed=13 alarm=500 gpsmode=AA satcount=6 hdop=2.0 gpsspeed=0.0 01:48:30 vehicle dist=15 smoothed=15 alarm=500 gpsmode=AA satcount=5 hdop=1.8 gpsspeed=0.0 02:04:10 vehicle dist=15 smoothed=15 alarm=500 gpsmode=AA satcount=4 hdop=1.9 gpsspeed=0.0 02:20:50 vehicle dist=14 smoothed=16 alarm=500 gpsmode=AA satcount=3 hdop=500.0 gpsspeed=0.0 04:15:15 vehicle dist=260 smoothed=60 alarm=500 gpsmode=AA satcount=4 hdop=1.9 gpsspeed=0.0 04:15:15 vehicle dist=297 smoothed=107 alarm=500 gpsmode=AA satcount=4 hdop=1.9 gpsspeed=0.0 04:15:20 vehicle dist=216 smoothed=129 alarm=500 gpsmode=AA satcount=4 hdop=1.9 gpsspeed=8.5 04:15:20 vehicle dist=184 smoothed=140 alarm=500 gpsmode=AA satcount=4 hdop=1.9 gpsspeed=8.5 04:16:00 vehicle dist=1162 smoothed=344 alarm=500 gpsmode=AA satcount=4 hdop=1.9 gpsspeed=0.0 04:16:00 vehicle dist=1322 smoothed=540 alarm=500 gpsmode=AA satcount=4 hdop=1.9 gpsspeed=0.0 04:16:00 CEST W flatbed.moved gpsmode=AA satcount=4 hdop=1.9 gpsspeed=0.0 04:16:05 vehicle dist=1419 smoothed=716 alarm=500 gpsmode=AA satcount=5 hdop=1.8 gpsspeed=0.0 04:16:05 vehicle dist=1426 smoothed=858 alarm=500 gpsmode=AA satcount=5 hdop=1.8 gpsspeed=0.0 04:17:25 vehicle dist=710 smoothed=828 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=5.2 04:17:25 vehicle dist=303 smoothed=723 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=5.2 04:17:30 vehicle dist=245 smoothed=627 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=0.0 04:17:30 vehicle dist=233 smoothed=549 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=0.0 04:17:35 vehicle dist=161 smoothed=471 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=13.7 04:17:35 vehicle dist=143 smoothed=405 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=13.7 04:17:40 vehicle dist=100 smoothed=344 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=0.0 04:17:40 vehicle dist=87 smoothed=293 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=0.0 04:17:45 vehicle dist=50 smoothed=244 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=0.0 04:17:45 vehicle dist=36 smoothed=203 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=0.0 04:17:50 vehicle dist=127 smoothed=187 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=0.0 04:17:50 vehicle dist=136 smoothed=177 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=0.0 04:17:55 vehicle dist=110 smoothed=164 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=0.0 04:17:55 vehicle dist=104 smoothed=152 alarm=500 gpsmode=AA satcount=5 hdop=5.6 gpsspeed=0.0 04:18:00 vehicle dist=107 smoothed=135 alarm=500 gpsmode=AA satcount=6 hdop=1.8 gpsspeed=0.0 04:18:05 vehicle dist=57 smoothed=119 alarm=500 gpsmode=AA satcount=6 hdop=1.8 gpsspeed=9.4 04:18:05 vehicle dist=44 smoothed=104 alarm=500 gpsmode=AA satcount=6 hdop=1.8 gpsspeed=9.4 04:18:10 vehicle dist=34 smoothed=90 alarm=500 gpsmode=AA satcount=6 hdop=1.8 gpsspeed=7.2 04:18:15 vehicle dist=17 smoothed=66 alarm=500 gpsmode=AA satcount=6 hdop=1.8 gpsspeed=7.8 04:18:15 vehicle dist=6 smoothed=54 alarm=500 gpsmode=AA satcount=6 hdop=1.8 gpsspeed=7.8 04:18:25 vehicle dist=25 smoothed=35 alarm=500 gpsmode=AA satcount=6 hdop=1.8 gpsspeed=1.7 04:18:25 vehicle dist=29 smoothed=34 alarm=500 gpsmode=AA satcount=6 hdop=1.8 gpsspeed=1.7 04:18:35 vehicle dist=25 smoothed=30 alarm=500 gpsmode=AA satcount=5 hdop=1.8 gpsspeed=0.0 04:32:25 vehicle dist=15 smoothed=15 alarm=500 gpsmode=AA satcount=4 hdop=1.9 gpsspeed=0.0 04:48:15 vehicle dist=15 smoothed=14 alarm=500 gpsmode=AA satcount=5 hdop=3.1 gpsspeed=0.0 04:48:20 vehicle dist=15 smoothed=14 alarm=500 gpsmode=AA satcount=5 hdop=3.1 gpsspeed=0.0 04:48:25 vehicle dist=18 smoothed=15 alarm=500 gpsmode=AA satcount=4 hdop=3.1 gpsspeed=1.5 04:48:30 vehicle dist=14 smoothed=16 alarm=500 gpsmode=AA satcount=4 hdop=6.2 gpsspeed=0.0 -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 10

3.3.002 to EAP
by Mark Webb-Johnson 20 Mar '22

20 Mar '22

I have today built 3.3.002 (based one latest edge): Released 3.3.002 to v3.1/eap (and v3.2/eap via symlink) Released 3.3.002 to v3.3/eap Released 3.3.002 to v3.3/main Regards, Mark.

2 2

Newly installed 4G modem getting DeniedRegistration
by Stephen Casner 15 Mar '22

15 Mar '22

On Saturday I installed a new 4G modem in Timothy Rodgers' OVMS (he is "Timothy" on TMC). When I did mine, it came right up on AT&T, but Timothy's is repeatedly failing. Both his and my OVMS are running 3.3.002. Both of us are using the Hologram SIM. At first, it looked like I might need to set the new IMEI at Hologram somehow because the old IMEI for the 3G modem still showed. Later, though, the IMEI changed to the new one, but the connection still did not come up. I suggested that Timothy contact Hologram support, which he did. The reply from the support agent is below. It says there have been many momentary connects and disconnects with zero bytes transferred. Has anything like this been seen elsewhere? Are there other tests we should do? -- Steve ---------- Forwarded message ---------- From: Rudy R (Hologram) <support(a)teamhologram.zendesk.com> Sent: Monday, March 14, 2022 6:41 AM To: Timothy Rodgers <timothy(a)cal.berkeley.edu> Subject: [Hologram] Re: My OVMS (On Vehicle Monitoring System) has been wo... ##- Please type your reply above this line -## Your request (147988) has been updated. To add additional comments, reply to this email. <https://secure.gravatar.com/avatar/2a79f7d3cba57758d4d2dbbb139c7bc9?size=40…> Rudy R (Hologram) Mar 14, 2022, 8:40 CDT Hi Timothy, Thanks so much for contacting Hologram support! My name is Rudy and I'd be happy to help with your request. After reviewing your Hologram admin dashboard I found an indication your device has at some points connected to the AT&T cellular network, however no data is passing after a connection is made with the network. A device with many zero-byte sessions in quick succession indicates excessive and unnecessary reconnects. This may be caused by improper connection logic by the device firmware or the cellular module's current configuration. For example, a device constantly trying to connect despite successfully opening data sessions will result in multiple zero-byte sessions over time. You may also find this Help Center <http://support.hologram.io/> article called, <https://support.hologram.io/hc/en-us/articles/360040668834-What-is-a-Sessio…> "What is a Session without Data and what causes it." useful in diagnosing the problem. If the article's recommendations do not help resolve the issue, to further help diagnose the connectivity issues with the connecting network, can you please run these modem diagnostics <https://support.hologram.io/hc/en-us/articles/360035697393-Modem-SIM-annota…> and send back the results? If you prefer, you can also run this script <https://support.hologram.io/hc/en-us/articles/4417363338647> for the diagnostics to automatically execute. The diagnostics will help our engineering team pinpoint possible causes and in most cases we can at least get you on the right path! Looking forward to your response! Rudy Hologram Support | support(a)hologram.io <mailto:support@hologram.io> For more information check out our awesome Help Center <https://support.hologram.io/hc/en-us> <https://secure.gravatar.com/avatar/983069bffb928389d285266979d0d8a5?size=40…> Timothy Rodgers Mar 12, 2022, 23:29 CST My OVMS (On Vehicle Monitoring System) has been working fine with my long standing Hologram account. Because of the ending of 2G and the addition of 5G it was recommended to put a new card in the device. An engineer who is a friend did this for the identical device in his car and it worked fine. When my new card was installed in my device and connected in my car, it worked when connected my home network but not with cell when away from home. When I typed in 'cell status' as a message on my device the reply was State: NetWait, Mux: Status up, and PPP:not running and GPS: not running. The PPP and GPS ran fine on my friends car. He was not sure why mine didn't work or what to do next and suggested I contact Hologram. I would appreciate your help. Thank you. My org ID 3616 ------------------ Submitted from: https://www.hologram.io/ This email is a service from Hologram. [660GYP-L5VDZ]

1 0

OVMS App Charge Status
by Michael Iimura 14 Mar '22

14 Mar '22

With my new RAV4 EV port, every time there is a charge status change, the OVMS App pops up a notification that Charging Stopped. Even when a charging session is starting, the notification says Stopped. What do I need to set so that the notification indicates the correct state change? Also the Vehicle status pane on the web server Status page always says "Not Charging", even when the ms_v_charge_state is "charging" and ms_v_charge_inprogress is TRUE. Also, where do I send my stock image so it can be included in the app? Thanks, - Mike

2 1

Build / release infrasructure
by Mark Webb-Johnson 07 Mar '22

07 Mar '22

My directory structure for firmware releases on api.openvehicles.com <http://api.openvehicles.com/>: /firmware/ota v3.0 main v3.1 edge pre -> eap eap main v3.2 -> v3.1 v3.3 edge -> ……/firmware/ota/v3.1/edge pre -> ……/firmware/ota/v3.1/pre eap main I build v3.1/edge automatically each night. cd $IDF_PATH git config pull.rebase false git pull git submodule init git submodule update cd $OVMS_TREE git config pull.rebase false git fetch --tags git pull git submodule init git submodule update cd $OVMS_PATH make defconfig make size >$INFO_PATH echo >>$INFO_PATH git log --graph --decorate --pretty=oneline --abbrev-commit --all -n 10 >>$INFO_PATH cp build/ovms3.bin $REL_PATH/${REV_NEW}.ovms3.bin cp build/ovms3.elf $REL_PATH/${REV_NEW}.ovms3.elf echo $REV_NEW >${REL_PATH}/ovms3.new echo `/usr/bin/date -u` "Automated build ($HOSTNAME)" >>${REL_PATH}/ovms3.new echo >>${REL_PATH}/ovms3.new cat $INFO_PATH >>${REL_PATH}/ovms3.new rm -f ${REL_PATH}/ovms3.bin ln -s ${REL_PATH}/${REV_NEW}.ovms3.bin ${REL_PATH}/ovms3.bin rm -f ${REL_PATH}/ovms3.elf ln -s ${REL_PATH}/${REV_NEW}.ovms3.elf ${REL_PATH}/ovms3.elf mv ${REL_PATH}/ovms3.new ${REL_PATH}/ovms3.ver The v3.1/pre, */eap, and */main are all manually released when ready. My directory structure for plugin releases on api.openvehicles.com <http://api.openvehicles.com/>: /plugins plugins.json plugins.rev abrp auxbatmon chgind chgthrottle edimax foglight helloworld pwrmon regenmon repidscan retools I build plugins automatically each night. See support/buildplugins.pl That is what I do today. At some point, we will build the v3.3 tree separately (rather than symlink to v3.1), to take advantage of a ESP32 rev3 specific sdkconfig. Regards, Mark.

1 0

Repeated WDT crashes after upgrade to 3.3 with 4G
by Stephen Casner 07 Mar '22

07 Mar '22

I installed version 3.3.001-285 from edge on my OVMS v3.1 unit before replacing the 3G modem with a 4G modem. Upon rebooting with the unit still on the bench I noticed that the unit was crashing every three minutes with a watchdog timeout: I (112275) gsm-mux: Start MUX I (112285) gsm-mux: Channel #0 is open I (112295) gsm-mux: Channel #1 is open I (112305) gsm-mux: Channel #2 is open I (112315) gsm-mux: Channel #3 is open I (112325) gsm-mux: Channel #4 is open I (113265) cellular: State: Enter NetWait state I (122265) housekeeping: System considered stable (RAM: 8b=81540-82392 32b=12344 SPI=3454300-3456824) I (122505) webserver: HTTP GET / I (122535) webserver: HTTP GET /apple-touch-icon.png I (122555) webserver: HTTP GET /status I (123265) ovms-server-v2: Send MP-0 h1,0,*-OVM-DebugCrash,0,2592000,3.3.001-285-g601f2a70/ota_1/edge (build idf v3.3.4-848-g1ff5e24b1 Feb 20 2022 00:04:30),2,Crash,12,12,2,0,abort(),0,,0x4008ddca 0x4008e065 0x400e9608 0x40084176 ,6,Task watchdog,ticker.1,esp32wifi,0,IDLE0,OVMS WIFI BLE BT cores=2 rev=ESP32/1; MODEM SIM7600 I (123295) cellular: Network Registration status: RegisteredRoaming I (123295) cellular: Network Provider is: AT&T Hologram I (123595) ovms-server-v2: Incoming Msg: MP-0 h1 I (124265) cellular: State: Enter NetStart state I (129845) webserver: HTTP POST /status I (129845) webserver: HandleLogin: 'admin' logged in, sid c3bb26091e718ad I (129875) webserver: HTTP GET /status I (130035) webserver: HTTP GET /menu W (178175) websocket: WebSocketHandler[0x3f8b19f0]: job queue overflow detected OVMS> E (185265) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (185265) task_wdt: - IDLE0 (CPU 0) E (185265) task_wdt: Tasks currently running: E (185265) task_wdt: CPU 0: Tmr Svc E (185265) task_wdt: CPU 1: IDLE1 E (185265) task_wdt: Aborting. abort() was called at PC 0x400e9608 on core 0 ELF file SHA256: 2d4b51699f53abce Backtrace: 0x4008ddca:0x3ffb0aa0 0x4008e065:0x3ffb0ac0 0x400e9608:0x3ffb0ae0 0x40084176:0x3ffb0b00 Rebooting... I was hoping that when I put the module back into the car with all the right inputs on its data cable that this problem would not continue, but sad to say the crashes remain the same. I have not heard about this issue for others who have upgraded to 3.3 and 4G. Any suggestions? Here are a couple of examples of the boot status: auge1> ssh ovms Welcome to the Open Vehicle Monitoring System (OVMS) - SSH Console Firmware: 3.3.001-285-g601f2a70/ota_1/edge Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1; MODEM SIM7600 OVMS# boot Last boot was 152 second(s) ago Time at boot: 2022-03-02 14:29:11 PST This is reset #1 since last power cycle Detected boot reason: EarlyCrash (12/12) Reset reason: Task watchdog (6) Crash counters: 1 total, 1 early Last crash: abort() was called on core 0 Backtrace: 0x4008ddca 0x4008e065 0x400e9608 0x40084176 Event: ticker.1@esp32wifi 0 secs WDT tasks: IDLE0 Version: 3.3.001-285-g601f2a70/ota_1/edge (build idf v3.3.4-848-g1ff5e24b1 Feb 20 2022 00:04:30) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1; MODEM SIM7600 OVMS# packet_write_wait: Connection to 192.168.1.74 port 22: Broken pipe auge2> ssh ovms Welcome to the Open Vehicle Monitoring System (OVMS) - SSH Console Firmware: 3.3.001-285-g601f2a70/ota_1/edge Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1 OVMS# boot Last boot was 76 second(s) ago Time at boot: 2022-03-02 14:32:18 PST This is reset #2 since last power cycle Detected boot reason: Crash (12/12) Reset reason: Task watchdog (6) Crash counters: 2 total, 0 early Last crash: abort() was called on core 0 Backtrace: 0x4008ddca 0x4008e065 0x400e9608 0x40084176 Event: ticker.1@esp32wifi 0 secs WDT tasks: IDLE0 Version: 3.3.001-285-g601f2a70/ota_1/edge (build idf v3.3.4-848-g1ff5e24b1 Feb 20 2022 00:04:30) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1 OVMS# OVMS# packet_write_wait: Connection to 192.168.1.74 port 22: Broken pipe -- Steve

5 27