April 2018 - OvmsDev - Open Vehicles

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

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

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

Fwd: [openvehicles/Open-Vehicle-Monitoring-System-3] 29e333: Issue #36: Add support for ota/tag in config
by Mark Webb-Johnson 30 Jun '18

30 Jun '18

A few changes to OTA this morning: The ‘ota status’ command used to check available server version only if a WIFI network was up. It now does that if ANY network is up (including modem). I’ve added a config instance ‘tag’ to parameter ‘ota’. This can be used to override the ota tag (default: main) at run-time. I’ve added a config instance ‘server’ to parameter ‘ota’. This can be used to override the ota server URL (default: api.openvehicles.com/firmware/ota <http://api.openvehicles.com/firmware/ota>). From now on, I’m going to be maintaining two tags for the production ota server api.openvehicles.com <http://api.openvehicles.com/>. These are: main: for stable releases edge: for bleeding edge developer releases You can, for example, now set your module to bleeding-edge by ‘config set ota tag edge’. Regards, Mark. > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] 29e333: Issue #36: Add support for ota/tag in config > Date: 16 April 2018 at 8:37:46 AM HKT > To: mark(a)webb-johnson.net > Reply-To: GitHub <noreply(a)github.com> > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: 29e33348f6dff949fd22567083de1d9db04b05e3 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/29e… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-04-16 (Mon, 16 Apr 2018) > > Changed paths: > M vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp > M vehicle/OVMS.V3/main/ovms_version.cpp > > Log Message: > ----------- > Issue #36: Add support for ota/tag in config > Issue #37: Add support for ota/server in config > Issue #38: ota status should show available server version for modem as > well as wifi > >

4 9

It's Here!
by Greg D. 04 Jun '18

04 Jun '18

Hi Mark, The 3.1 module arrived in today's mail. I haven't plugged it in yet, but two "unboxing" observations... The unit looks really nice, though it seems that the top shell is a tad too wide and overlaps the bottom piece by nearly a mm on one corner. And, not evenly, at that; it's like the corner by the Vehicle connector got stretched a bit outward (or the other half pushed inward). The other two sides are all pretty evenly matched. The 3.0 proto unit was not like this. {shrug} Also, the two SMA dust caps seemed to have had some reaction with the adhesive on the flap of the padded envelope. They were stuck to the flap, pulled away from the connectors (so, not much dust protection), and the adhesive on the flap seemed to be very gooey in that area. The caps seemed to have been more or less unaffected, so it's more of a cosmetic issue. Perhaps they could point the module in the other direction (SMA end first), to prevent this in the future? My intent is to play "customer" with this unit, only using officially released code, updated through typical methods (i.e. not via the developer's kit) unless I need to do otherwise. I've got some short-term distractions through the weekend, but will take it out for a spin next week. Greg

6 15

Automatic vehicle notifications
by Mark Webb-Johnson 25 May '18

25 May '18

It is time to implement vehicle notifications (charge started, charge completed, charge interrupted, etc) in the vehicle modules I am supporting. It seems that this can be done in the vehicle.{h,cpp} framework in a standard manner, and work across all vehicle types. However, I guess that will break any notifications already being produced by other vehicle types. My suggestion is: A config parameter ‘notifications’, with individual instances to turn on/off the notifications. Default is all enabled. OvmsVehicle::MetricModified picks up metric changes and issues the standard notifications (checking ‘notifications’ parameter appropriately). charge_mode=>charging: Notify charge started charge_mode=>topoff: Notify charge started charge_mode=>heating: Notify battery heating started charge_mode=>done: Notify charge completed charge_mode=>stopped: Notify charge interrupted valet_mode=>on: Notify valet mode enabled valet_mode=>off: Notify valet mode disabled alarm=>on: Notify alarm is sounding alarm=>off: Notify alarm is off All the above should be suppressed for the initial setting of each parameter. I will have to look into metrics to see how best that should be done; one neat way is to keep a modification count (rather than the current m_defined boolean). Does that make sense? Any objections/suggestions? Regards, Mark

2 4

Turned off commenting on the OVMS v3 User Guide
by Mark Webb-Johnson 08 May '18

08 May '18

I’ve had to turn off commenting on the OVMS v3 user guide. Too many people with just no idea what they are doing messing around. If any developers would like to comment on, or help edit/expand, that guide, send me your email address and I’ll add you with specific access rights. Regards, Mark

7 59

12V calibration default factor
by Michael Balzer 01 May '18

01 May '18

Our default factor of 182 for the 12V ADC converter seems to be too low on current 3.1 production modules. Calibration results from three modules: * 192.35 * 199.15 (that's mine) * 200.2 So the default was way off on these. If these values are typical, our default should be around 197. Can some please check their modules and provide some more factors to verify this? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 1

OTA Automatic updates (middle of the night)
by Mark Webb-Johnson 01 May '18

01 May '18

The last piece of the puzzle falls into place. OVMS# config set auto ota yes OVMS# config set ota auto.hour 2 Module will wake up sometime between 2am and 3am, and if wifi is available it will check the available server version (according to OTA tag and server url). If the server has a later version, the module will download and flash that new version then reboot into it. I’ve also brought in the strverscmp function for GNU library, which is generally useful for comparing versions. Enjoy. Regards, Mark. > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] 1a4301: Bring in GNU strverscmp component, and test comman... > Date: 29 April 2018 at 10:23:54 PM HKT > To: mark(a)webb-johnson.net > Reply-To: GitHub <noreply(a)github.com> > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: 1a4301d7ca1c7ed619109dfcb2e832a599af7dda > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/1a4… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-04-29 (Sun, 29 Apr 2018) > > Changed paths: > A vehicle/OVMS.V3/components/strverscmp/component.mk > A vehicle/OVMS.V3/components/strverscmp/src/strverscmp.c > A vehicle/OVMS.V3/components/strverscmp/src/strverscmp.h > M vehicle/OVMS.V3/main/test_framework.cpp > > Log Message: > ----------- > Bring in GNU strverscmp component, and test command > > > Commit: 58fa1b57448d3491889e3d1d3f487e475d036c92 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/58f… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-04-29 (Sun, 29 Apr 2018) > > Changed paths: > M vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp > M vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.h > > Log Message: > ----------- > AutoFlash implementation: > Config auto[ota]=yes > Config ota[auto.hour]=2 > > > Compare: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/87…

2 9