June 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

SWCAN
by Mark Webb-Johnson 22 Jun '22

22 Jun '22

Regarding: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/704 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/704> Marko did some work on the back in 2019, and helpfully published under MIT license here: https://github.com/mjuhanne/OVMS-SWCAN <https://github.com/mjuhanne/OVMS-SWCAN> Very grateful for that. Now, the Bolt EV people are asking for this. In general, it seems that we can do a simple board in the same way as the K-Line was done. Use the two available GPIOs (one for INT and the other CS). Then the GPIOs on the MCP2515 to control the transceiver mode. Expose the single SWCAN pin on the DB9, in the same way as K-Line does it. GND (for SWCAN-low) is already available there. Anybody see any problems with that approach? I am happy to arrange the hardware, given sufficient interest, but have almost no way of testing (as none of the cars I have access to have SWCAN). Regards, Mark.

3 7

175.45.17.222 -> 14.198.177.61
by Mark Webb-Johnson 13 Jun '22

13 Jun '22

Note that the openvehicles.com server is changing IP address: 175.45.17.222 -> 14.198.177.61 This should all be handled by DNS, so no changes needed on the modules. The old 175.45.17.222 address will be decommissioned in a few days time. Regards, Mark.

1 0