June 2018 - OvmsDev - Open Vehicles

3G network
by Stein Arne Sordal 03 Jul '19

03 Jul '19

Hi I guess this question is basically for Mark, In Norway the telecom providers have decided to turn off almost all of the 3G network soon and focus on 4G only. Any plan for 4G modem? Kind regards, Stein Arne Sordal

6 12

Can buses stop after some time
by Tom Parker 02 Jun '19

02 Jun '19

Hi all, I synced up with master about a week ago and since then I've seen both can busses stop working. I still see the 12v battery metric changing, but everything that comes from the car stops. Rebooting the module with "module reset" does not seem to fix it, while make app-flash monitor does fix it. I haven't tried make monitor on it's own. Is anyone else seeing behavior like this? Sorry for the vague bug report. I'll spend some time later this weekend to try to gather more information.

7 45

Android App v3.12.2 in Play Store
by Michael Balzer 07 Apr '19

07 Apr '19

Whoa. Our first public App update since …drumroll… June 2014 :) I didn't get any bug reports for my 3.12.2 beta release, so I just finished some last details and uploaded it. May take some hours to appear in the Play Store. As change history has grown a bit beyond the allowed 500 chars for the release info, I've added a history page to the Wiki: https://github.com/openvehicles/Open-Vehicle-Android/wiki/History I'm afraid it's just the condensed gitlog though. I hope users won't get confused, sure could need some refinement. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

10 47

Power states clarification
by Greg D. 02 Mar '19

02 Mar '19

Hi folks (mostly Mark, probably), I just noticed that there is a power command for OBD2ECU as well as ext12v. I understand (or thought I did) what controlling the ext12v power does, but how is "power" related to OBD2ECU? Is this related to firing up the opened CAN bus, or is there some tie to the ext12v power? I have manually created scripts for vehicle.on and vehicle.off to explicitly control ext12v, so that an attached HUD will follow the key. We talked about having this sort of thing done automatically, but I didn't think it was ever implemented, nor what the particulars would be regarding some of the device corner cases. Is that what is happening here? Related, what do the other states do? (Sleep, deepsleep, etc.) Thanks, Greg

3 3

Collecting information on the Fiat 500e
by Jason Perkins 15 Feb '19

15 Feb '19

OVMS team, As an owner of a Fiat 500e I was very interested when I stumbled across this project on the TMC forums. The Fiat factory telematics system deactivates 3 years from the original vehicle sale and is non renewable. I think FCA wants to kill the whole system at this point (it's been replaced with the corporate UConnect system) so another solution would be ideal. I have a 2013 500e with deactivated telematics, and our roommate has a 2014 with working telematics. If any data could be captured from the car with working telematics (branded as Fiat Access) to assist integrating OVMS I'd love to help. The Fiat Access telematics provides vehicle location, battery level, tire pressure, setting the charge schedules, locking / unlocking the car, and starting the climate control. I believe the actual control unit was adapted from some kind of remote-disablement system used in europe (the Fiat literature calls this the Vehicle Tracking Module). The Fiat has a normal J1962 plug, but does not have OBDII protocol support. Like the Kia Soul the powertrain CAN on pin 6 / 14 and the body CAN on 1 / 9. There's no telling how long the telematics will keep working on our roommates '14, so doing a capture sooner than later would be good. I'm open to any suggestions on how best to do this. The car related diag tools I have on hand are: ELM327 Bluetooth, Ross-Tech VCDS (For VW / Audi Products), and AlfaOBD (which can talk to most of the modules in the 500e - but not the VTM :( ), and an adapter to swap the CAN wires so a standard interface can get to the Body CAN. Thanks! -J

5 28

esp32can issue
by Michael Balzer 04 Nov '18

04 Nov '18

Frank Demes reported a very strange CAN behaviour. He managed to get a CRTD log of one incident. The effect is triggered by an unknown cause freezing the CAN rx task for short periods of time, i.e. 70 - 120 ms. This alone should be no problem, the RXFIFO will probaly overflow, but that is handled by our driver, so except some messages lost this should not be an issue. Unfortunately, something goes completely wrong: a) on the overrun event, the last valid message is delivered multiple times (i.e. 5 times) b) after resolving the overrun, a garbled message is received. The garbled message contains a valid byte sequence in the wrong place, i.e. bytes 5-8 would be valid if they were bytes 1-4. Bytes 1-4 cannot have been read from the bus, so something is going very wrong here. I have walked through the esp32can driver and checked the SJA1000 documentation but have no clue what is going wrong. Any ideas? CRTD excerpt below. (Frame 155 is reflected by the module with byte 1 changed from 07 to 01 to limit the charge current. The problem is, it also reflects the garbled message, which causes the charger to stop.) Regards, Michael ---------------------------------------------------------------------------------------- … 274.341 1R11 155 07 97 E4 54 4B A8 00 6C 274.341 1T11 155 01 97 E4 54 4B A8 00 6C 274.351 1R11 155 07 97 E5 54 4B A8 00 6C 274.351 1T11 155 01 97 E5 54 4B A8 00 6C 274.361 1R11 155 07 97 E5 54 4B A8 00 6C 274.361 1T11 155 01 97 E5 54 4B A8 00 6C 274.371 1R11 423 03 22 FF FF 00 E0 00 DB 274.371 1R11 426 00 38 01 00 4D 7E 00 274.371 1R11 597 20 A4 03 B1 2F 00 01 53 274.371 1R11 627 00 00 00 274.371 1R11 155 07 97 E5 54 4B A8 00 6C 274.371 1T11 155 01 97 E5 54 4B A8 00 6C 274.381 1R11 155 07 97 E5 54 4B A8 00 6C 274.381 1T11 155 01 97 E5 54 4B A8 00 6C 274.391 1R11 5D7 FF FF 01 E4 53 80 00 - normal up to here !!! CAN RX is blocked here for ~70 ms !!! … interrupts disabled? by whom? 274.461 1R11 599 00 00 4D 7E 1E 26 FF FF 274.461 1R11 436 00 0E 3C B2 00 00 274.461 1R11 155 07 97 E5 54 4B A8 00 6C 274.461 1R11 424 11 40 15 26 47 64 00 48 274.461 1R11 425 0A 1D 44 FF FE 40 01 1F 274.461 1R11 556 30 63 07 30 73 07 30 7A 274.461 1T11 155 01 97 E5 54 4B A8 00 6C ← reflection for 155 still works here !!! next RX pause, ~90 ms this time !!! !!! ID 599 has a period of 100 ms, but we now get it 5 times: 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1CEV Error intr=58445 rxpkt=27132 txpkt=528128 errflags=0x15433 rxerr=0 txerr=0 rxovr=2 txovr=0 txdelay=17 crtd fprintf bug compensation: 274.551 1CEV Error rxpkt=58445 txpkt=27132 errflags=528128 intr=0x15433 rxerr=0 txerr=0 rxovr=2 txovr=0 txdelay=17 errflags=528128 = 08 0F 00 0x08 = IR: Data overrun 0x0F = SR: Bus OK, error limit not yet reached, RX & TX idle, RXFIFO overrun, RX buffer full 0x00 = ECC: - 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1R11 155 07 97 E6 54 4B A8 00 6C RX "A" 274.551 1R11 155 07 97 E6 54 4B A8 00 6C RX "B" 274.551 1R11 155 07 97 E7 54 4B A8 00 6C RX "C" 274.551 1R11 423 03 22 FF FF 00 E0 00 DB 274.551 1R11 426 00 38 01 00 4D 7E 00 274.551 1R11 597 20 A4 03 B1 2F 00 01 53 274.551 1R11 627 00 00 00 274.551 1T11 155 01 97 E6 54 4B A8 00 6C reflection "A" 274.551 1CEV TX_Queue T11 155 01 97 E6 54 4B A8 00 6C reflection "B" 274.551 1CEV TX_Queue T11 155 01 97 E7 54 4B A8 00 6C reflection "C" 274.551 1T11 155 01 97 E8 54 4B A8 00 6C reflection "D" !!! 120 ms pause !!! 274.671 1R11 155 07 97 E8 54 4B A8 00 6C RX "D" → "D" was sent to the listeners & reflected by vehicle::IncomingFrame() then, before the LogFrame() call was processed, the CAN task was paused for 120 ms and now it's getting really weird: 274.671 1R11 155 07 08 2A A0 07 97 E7 54 RX "E": invalid frame / garbled message! … this frame certainly was not on the bus! bytes 2-4 (08 2A A0) = complete nonsense, not matching any frame on the bus bytes 5-8 (07 97 E7 54) = normally bytes 1-4 (!) of ID 155 - copy / memory error? … very unlikely - CAN RX handling error? … doesn't seem so - RXFIFO message window bug? 274.671 1CEV Error intr=58458 rxpkt=27134 txpkt=528128 errflags=0x15456 rxerr=0 txerr=0 rxovr=3 txovr=0 txdelay=19 274.671 1R11 155 07 97 E7 54 4B A8 00 6C 274.671 1R11 155 07 97 E7 54 4B A8 00 6C 274.671 1R11 155 07 97 E7 54 4B A8 00 6C 274.671 1T11 155 01 97 E6 54 4B A8 00 6C 274.671 1CEV TX_Queue T11 155 01 97 E7 54 4B A8 00 6C 274.671 1R11 155 07 97 F2 54 4B A8 00 6C 274.671 1R11 155 07 97 F3 54 4B A8 00 6C 274.671 1R11 423 03 22 FF FF 00 E0 00 DB 274.671 1R11 426 00 38 01 00 4D 7E 00 274.671 1R11 597 20 A4 03 B1 2F 00 01 53 274.671 1R11 627 00 00 00 274.671 1R11 155 07 97 F5 54 4B A8 00 6C 274.671 1R11 155 07 97 F6 54 4B A8 00 6C 274.671 1R11 5D7 FF FF 01 E4 53 80 00 274.671 1R11 599 00 00 4D 7E 1E 26 FF FF 274.671 1R11 155 07 97 F7 54 4B A8 00 6C 274.671 1R11 436 00 0E 3C B2 00 00 274.671 1R11 041 A0 07 97 F5 54 4B A8 00 274.671 1T11 155 01 97 E7 54 4B A8 00 6C 274.671 1T11 155 01 08 2A A0 07 97 E7 54 reflection of invalid msg "E" → charge terminates due to error -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 19

Production batch 2 and onwards
by Mark Webb-Johnson 30 Aug '18

30 Aug '18

FYI The order for production batch #2 has just been placed: 50x US kits (module + US 3G modem + Hologram sim) 150x EU kits (module + EU 3G modem + Hologram sim) 20x modules only (board + case, but no modem) 5x EU 3G modems (incl. Hologram sim) 5x US 3G modems (incl. Hologram sim) No change to specification and board layout from the first production batch, except to re-iterate the points that came in from feedback. We are arranging a foam box to ship the modules in, with our logo on it, to avoid the issues with sticky glue on those padded bags. Availability at Fasttech perhaps in about 3 weeks time. Our deadline for firmware is about 10 days. This is a lot of $$$ upfront payment, and the project is pretty tapped financially (I’ve had to pay for most of this myself). Once the money from sales starts to come in, we’ll be better off. I have quotes from certification labs for CE and FCC certs, and it seems possible. They say we may have some small changes to make (ESD primarily), but overall our design seems fine and they are confident we can achieve the certification. The process is expensive, but is just a one off upfront payment. Current plan is to start with that process once we have this production batch built and at Fasttech. We did consider doing this before this production batch #2, but that would have just delayed things several months. So long as this certification process doesn’t drag on, we should be able to keep OVMS v3 in stock and available from now. Regards, Mark.

3 15

3.1.007 OTA
by Mark Webb-Johnson 30 Jul '18

30 Jul '18

On my devices I’m seeing a problem with doing OTA updates when running 3.1.007. I’m seeing: OVMS# ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3.1/edge/ovms3.bin to ota_0 Expected file size is 2850336 Preparing flash partition... abort() was called at PC 0x401b8e84 on core 0 0x401b8e84: pm_on_beacon_rx at ??:? Backtrace: 0x40091e6b:0x3ffcc4a0 0x40091fc3:0x3ffcc4c0 0x401b8e84:0x3ffcc4e0 0x401b94ef:0x3ffcc520 0x401b9bd1:0x3ffcc550 0x40089e62:0x3ffcc5a0 0x40091e6b: invoke_abort at /Users/mark/esp/esp-idf/components/esp32/panic.c:669 0x40091fc3: abort at /Users/mark/esp/esp-idf/components/esp32/panic.c:669 0x401b8e84: pm_on_beacon_rx at ??:? 0x401b94ef: ppRxProtoProc at ??:? 0x401b9bd1: ppRxPkt at ??:? 0x40089e62: ppTask at ??:? (this is a firmware rebuild so addresses may vary from stock 3.1.007, but the functions are the same) The pm_on_beacon_rx function is in libpp (as are ppRxProtoProc, ppRxPkt, and ppTask. If I comment out the esp_ota_* functions, it does the download and works fine. But if esp_ota_begin is called, then the crash occurs within http.BodyRead. (although I think it is within the ppTask, not in our code). It I reduce the size parameter given to esp_ota_begin, I can get it to work just fine. Around 1.5MB is fine, but above that is starts to get flaky. Espressif say that during flash writes the cache must be disabled, so all access to SPIRAM halted. Sometimes, I get to see a message 'I (20642) wifi: bcn_timout,ap_probe_send_start’ which seems to confirm the wifi task is being starved for cpu time during the esp_ota_begin(). I guess that is triggering a bug within the wifi stack where it doesn’t handle it gracefully. I then tried hacking around the esp_ota_begin() function. The Espressif implementation simply calls esp_partition_erase_range() to erase the partition in one call. For us, that now means blanking 2.8MB of flash and takes about 15 seconds or so. I changed that to call esp_partition_erase_range() multiple times, in 256KB chunks, with a 10ms vTaskDelay between each chunk. Problem solved. OTA works again doing it that way. I’m not sure how to get this fix applied. The issue is in Espressif’s code, related to big partition sizes. I guess they haven’t seen it because with 1MB OTA partitions the delay is only 3 seconds or so and probably not long enough to trigger the issue. I’ll raise a bug report with them, but suspect it will be a while for them to address it. As a temporary workaround for us, I think I’ll bring esp_ota_begin() into our ovms_ota code and customise it there specifically for us. We can always switch back to the normal esp_ota_begin when/if Espressif come up with a permanent solution. I don’t really want to change that core Espressif code, without direction from Espressif as to how to change it (been there, done that, and wasted a lot of time doing it). For safety, I’ve rolled back edge to 3.1.006-15-g14b8eb6. That will stop new deployments of this, while we solve the problem. For existing deployments in the field, I can only think of two solutions: (a) switch ota to factory, reboot, and flash to fixed code, or (b) ota from sdcard, with wifi unused/off. I should have the fix later today. Regards, Mark.

4 8

CAN bus hacking
by Mark Webb-Johnson 27 Jul '18

27 Jul '18

For those of us working on vehicle support, I am concentrating on the last pieces for Tesla Roadster, ongoing work on Tesla Model S, and helping out Chris (in AU) to try to get Volt/Ampera ported (he has the car, I don’t). We have a lot of users waiting for Volt/Ampera support. For all of this, I’m trying to extend the RE tools and CAN frameworks to allow for OVMS to be used for CAN bus analysis and simulation. It is really coming together nicely, and it looks like the system is powerful enough to handle this admirably. I’m trying hard not to plug a USB-CAN adaptor into my car, or use any other desktop tools. This should bring the barrier to entry right down for new vehicle support. A few examples… Using ‘can rx’ to simulate an incoming CAN bus message and see what happens to metrics: OVMS# metrics trace on Metric tracing is now on OVMS# vehicle module VA I (26522) v-voltampera: Volt/Ampera vehicle module I (26522) metrics: Modified metric v.type: VA I (26582) metrics: Modified metric v.e.parktime: 26Sec I (27582) metrics: Modified metric v.e.parktime: 27Sec I (28582) metrics: Modified metric v.e.parktime: 28Sec OVMS# can can1 rx standard 135 01 I (49462) metrics: Modified metric v.e.on: yes I (49462) metrics: Modified metric v.e.awake: yes I (49462) metrics: Modified metric v.e.handbrake: no I (49582) metrics: Modified metric v.e.parktime: 0Sec OVMS# can can1 rx standard 4e1 42 55 31 30 32 36 38 39 OVMS# can can1 rx standard 514 47 31 52 44 36 45 34 36 I (94402) metrics: Modified metric v.vin: 1G1RD6E46BU102689 OVMS# can can1 rx standard 135 00 I (103342) metrics: Modified metric v.e.on: no I (103342) metrics: Modified metric v.e.awake: no I (103342) metrics: Modified metric v.e.handbrake: yes I (103582) metrics: Modified metric v.e.parktime: 1Sec I (104582) metrics: Modified metric v.e.parktime: 2Sec I (105582) metrics: Modified metric v.e.parktime: 3Sec I (106582) metrics: Modified metric v.e.parktime: 4Sec I (107582) metrics: Modified metric v.e.parktime: 5Sec I (108582) metrics: Modified metric v.e.parktime: 6Sec I (109582) metrics: Modified metric v.e.parktime: 7Sec I (110582) metrics: Modified metric v.e.parktime: 8Sec Showing CAN message changes, and discovering new messages (or bytes within that were not previously changing but now are): OVMS# re start OVMS# re mode analyse Now running in analyse mode OVMS# can can1 rx standard 100 01 02 03 04 OVMS# can can1 rx standard 101 01 02 03 04 OVMS# can can1 rx standard 102 01 02 03 04 OVMS# re discover list changed key records ms last can1/100 1 8000 01 02 03 04 | .... can1/101 1 8000 01 02 03 04 | .... can1/102 1 8000 01 02 03 04 | .... OVMS# re discover clear changed Cleared all change flags OVMS# can can1 rx standard 102 01 02 13 04 OVMS# re discover list changed key records ms last can1/102 2 15500 01 02 13 04 | .... OVMS# re mode discover Now running in discover mode OVMS# can can1 rx standard 102 01 02 13 04 OVMS# re discover list discovered key records ms last OVMS# can can1 rx standard 102 01 12 13 04 OVMS# re discover list discovered key records ms last can1/102 4 14500 01 12 13 04 | .... OVMS# can can1 rx standard 110 01 02 03 04 OVMS# re discover list discovered key records ms last can1/102 4 17500 01 12 13 04 | .... can1/110 1 70000 01 02 03 04 | .... A CRTD format can bus dump: I (372613) re: Log service connection from 10.8.8.83 OVMS# can can1 rx standard 120 01 02 03 04 OVMS# can can1 rx standard 121 01 02 03 04 OVMS# can can1 rx standard 121 DE AD BE AT I (466333) re: Log service disconnection from 10.8.8.83 $ telnet devbench.local 3000 Connected to devbench.local. 1524105901.244120 1R11 120 01 02 03 04 1524105905.794094 1R11 121 01 02 03 04 1524105915.194145 1R11 121 de ad be at The TODO list for this is huge, so it will progress as I have time to work on it (and as I hit a requirement for each unfinished part). For example, simulating CAN bus traffic (replaying) would be nice (something like ‘$ cat mylogfile.crtd | nc devbench.local 3000’) - and that is something I need now, so will probably come next (and is pretty trivial - just pickup on data coming in the tcp/3000, decode it, and either simulate reception or transmit it on the actual car bus). The whole decoding/encoding thing (where we use DBC or whatever to say key X byte Y is converted to v.bat.soc using this formula) is of course the holy grain of this; and is built upon all the foundation I’m laying now. The end goal remains for vehicle modules with just a DBC (or whatever) and no actual code. It is all command line at the moment, but this could be very very cool using Michael’s web framework (particularly with real-time websocket updates). Regards, Mark.

2 6

GPS / NMEA integration
by Michael Balzer 11 Jul '18

11 Jul '18

I'm currently working on the NMEA module. The MUX channel is working, but I don't get a GPS fix. I've tried all GPS commands and now suspect my SIMCOM module having a hardware issue. I'm doing this: OVMS > level debug OVMS > power simcom on …wait for the MUX to be ready, then issue… OVMS > simcom muxtx 4 AT+CGPSNMEA=1 OVMS > simcom muxtx 4 AT+CGPS=1,1 …now the SIMCOM begins sending NMEA $GPGGA lines once per second looking like this: D (2937174) SIMCOM rx: f9 05 ff 35 24 47 50 47 47 41 2c 2c 2c 2c 2c 2c ...5*$GPGGA,,,,,,* D (2937174) SIMCOM rx: 30 2c 2c 2c 2c 2c 2c 2c 2c 2a 36 36 0d 0a 60 f9 *0,,,,,,,,*66*..`. Normally the modem should get a GPS fix within about 1-2 minutes and begin filling data in the $GPGGA record. But my modem won't, it just keeps sending empty fields. Can someone please try this with his/her module? To disable the GPS receiver, issue: OVMS > simcom muxtx 4 AT+CGPS=0 Thanks & regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

7 30