October 2018 - OvmsDev - Open Vehicles

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

3.1.011
by Mark Webb-Johnson 04 Nov '18

04 Nov '18

I think we are overdue for a release. There are some refinements, and the config backup stuff Michael did would be useful to get out. I intend to release to EAP tomorrow, based on whatever we have in HEAD then. Let me know if there is anything that might interfere with that plan. Regards, Mark.

2 2

Roadster cooldown
by Stephen Casner 04 Nov '18

04 Nov '18

Last evening I returned home from a trip and decided to try the "charge cooldown" command to cool the battery on my Roadster. I had not tried it before, and I think it may not have worked correctly. I issued the "charge cooldown" command using the shell page of the web UI. The response was a line indicating that the cooldown had started, and I got a notification through server v2 that the car was charging in Range mode. But later the status page in the iPhone app indicated that the car was charging in Standard mode at 32A, which is the full rate from my EVSE. Over the course of half an hour the SOC increased from 42% to 50%, at which point I manually stopped the charge. I thought the cooldown procedure was supposed to charge in Range mode at 12A and not significantly add to the battery charge level. I have not studied the cooldown code, but after a quick look I see that the procedure is more complicated than one might expect, stepping through multiple cycles as needed. Did I do something incorrectly? Or do these symptoms indicate that there might be a problem with the implementation? While the charge was in progress I blindly tried a "charge status" command hoping that it would tell me about the progress of cooldown, but alas that subcommand does not exist. -- Steve

3 10

ovms_shell
by Mark Webb-Johnson 23 Oct '18

23 Oct '18

To help with supporting end-users, I’ve cobbled together a small command line shell for OVMS. It may be of use to others for working on their own cars. You’ll find it in the ovms v2 repository, under clients, as ovms_shell.pl. It should run fine under unix-like operating systems (Mac, Linux, BSD, etc). Perhaps workable under windows, but would require a perl environment. Here is an example of it in use: $ ovms_shell.pl api.openvehicles.com Welcome to the OVMS shell Server is api.openvehicles.com:6867 (can be specified on the command line) Enter 'open <vehicleid> [<password>]' to connect to a vehicle, or 'close' to disconnect ovms> open DEMO DEMO Connecting to DEMO... Connected to server >MP-A 0 ZxDqLCFCXhe4S8r/LK0gyC KVDjwsJWZxQCrFX+NQ3GRQ DEMO <MP-S 0 9K0rAt/ViViZkHm2ik/mw8 8wsotf+GCUqVIIhrofBHXg== Connected and logged in to DEMO Server reports 1 app(s) connected (including this shell) Vehicle Firmware Message: Version: 1.5.0 Type: TRDM VIN: VIN123456789012345 Signal: (5) Vehicle Status Message: Battery: soc 41 cac soh voltage range-full K Range: ideal 146K estimated 131K Charge: state charging mode standard (220 V 13 A, limit 13 A) type state 1 mode 0 substate 5 time 6 duration (0 kWh) to-full to-set K/%% timer 0 (start 0) Cooling: (limit temp time ) estimated K %% Vehicle Environment Message Temps: inverter 35 motor 45 battery 30 environment 25 charger cabin (stale 1) Locked: 4 Trip/Odo: trip 0 odometer 7098790 speed 50 park-time 0 12vBatt: level 12.0 current (ref ) Doors: doors1 124 doors2 24 doors3 0 doors4 0 doors5 Vehicle Location Message: Position: 22.442075,114.028017 (lock: 1) Direction: 90 Altitude: 0 Speed: 1 DriveMode: Battery: power used recd Vehicle TPMS Message: FL: 29 PSI 27 C FR: 29 PSI 27 C RL: 40 PSI 31 C RR: 40 PSI 31 C Vehicle data is currently 5 second(s) delayed Vehicle Firmware Message: Version: 1.5.0 Type: TRDM VIN: VIN123456789012345 Signal: (5) Server Firmware Message: Version: 2.1.1-20121216 Vehicle is online live Vehicle Status Message: Battery: soc 41 cac soh voltage range-full K Range: ideal 146K estimated 131K Charge: state charging mode standard (220 V 13 A, limit 13 A) type state 1 mode 0 substate 5 time 6 duration (0 kWh) to-full to-set K/%% timer 0 (start 0) Cooling: (limit temp time ) estimated K %% Vehicle Location Message: Position: 22.442075,114.028017 (lock: 1) Direction: 90 Altitude: 0 Speed: 1 DriveMode: Battery: power used recd Vehicle Environment Message Temps: inverter 35 motor 45 battery 30 environment 25 charger cabin (stale 1) Locked: 4 Trip/Odo: trip 0 odometer 7098790 speed 50 park-time 0 12vBatt: level 12.0 current (ref ) Doors: doors1 124 doors2 24 doors3 0 doors4 0 doors5 Vehicle TPMS Message: FL: 29 PSI 27 C FR: 29 PSI 27 C RL: 40 PSI 31 C RR: 40 PSI 31 C (here is some data from another live car - as DEMO is limited) ovms> metric list v.b ... Vehicle Response: v.b.12v.current v.b.12v.voltage 12.75V v.b.12v.voltage.alert v.b.12v.voltage.ref 12.6V v.b.c.level.avg v.b.c.level.max 88% v.b.c.level.min 86% v.b.c.level.stddev v.b.cac 144.469Ah v.b.consumption 173.746Wh/km v.b.coulomb.recd v.b.coulomb.used v.b.current 35A v.b.energy.recd v.b.energy.used v.b.health CAC 144.47Ah SOC 100% LIM 87% MIN 86% MAX 88% ovms> ota status ... Vehicle Response: Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.010/ota_1/eap (build idf v3.1-dev-1585-g812f959 Aug 26 2018 17:09:48) Server Available: 3.1.010 (no update required) Sun Aug 26 09:10:00 UTC 2018 OTA release ... It supports both v2 and v3 modules, and doesn’t care - just uses the v2 protocol, and is pretty basic. Messages from the vehicle/server are decoded where implemented, and just dumped on the screen otherwise. Anything you type (other than the system commands ‘open’ and ‘close’) is sent to the car as a type ‘7’ command, and responses shown on the screen. The decodes are not amazing, and at the moment are pretty simple value dumps, but good enough for support purposes. I use it on the server itself, so it defaults to 127.0.0.1 (but that can be changed on the command line). Similarly, if you configure in ovms_shell.conf a mysql server connection, it can read server passwords from the database directly. Otherwise, you can specify the server password as a parameter on the ‘open’ statement. As I said, it is pretty much designed just for my own support use, but might be useful to others. Enjoy. Regards, Mark. P.S. I haven’t been able to contribute much to the project code for the past month or so. Overwhelmed at work, and out of action with a shoulder rotator cuff problem (cortisone injections are wonderful). Anyway, it seems more under control now, so I should be back to contribute more in the coming weeks. I really need to finish off the bluetooth support, and resolve that alloca crash we have been seeing (related to esp32 wifi stack it seems). Then, I have some fun contributions for the roadster (taking advantage of the 3 bus cable we now have).

1 0

Config backup & restore
by Michael Balzer 14 Oct '18

14 Oct '18

I've added ZIP archive support. This is based on zlib and libzip, which are included as new submodules, so you'll need to do "git submodule update" after pulling the update. First application is config backup & restore. New commands: * config backup <path> [password=module password] * config restore <path> [password=module password] The backup covers the directories "ovms_config" and "events" from "/store". Restore will only replace those by the restored versions, anything else on "/store" is left untouched. Restore automatically reboots the module on success. Web UI is todo. Note: backup ZIP encryption is AES-256, so you'll need 7z or a similar modern zip utility on your PC. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 2

Privacy Policy
by Mark Webb-Johnson 01 Oct '18

01 Oct '18

We are way overdue from having a privacy policy. Given what we do, it is tough. We are a community project not charging for services, and need to protect both our user’s data and ourselves. I’ve created a draft policy, based on an open source template. It is available here: https://www.openvehicles.com/privacypolicy <https://www.openvehicles.com/privacypolicy> Reading those policy documents is always scary. If anyone has any suggestions to make it less so, while still providing the necessary protections, please help! Regards, Mark.

2 4

Antenna
by Tamás Kovács 01 Oct '18

01 Oct '18

Can I test OVMS without connected gsm antenna, is modem is disabled in web interface, or remove the modem from OVMS board

2 1

Fw.:OVMS notification type A
by Henrik Scheel 01 Oct '18

01 Oct '18

1 0