March 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

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

Moving to a production cycle
by Mark Webb-Johnson 16 Apr '18

16 Apr '18

My v3.1 test board seems stable, and we are ready for hardware production. I’m ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we’ll clearly say these are early units for ‘technically capable’ people, and the firmware still has a way to go. On the firmware side, we need to move to a production style release cycle, and I will need to provide the first ‘factory’ firmware around the second week of March. Accordingly, I’m setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download). I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the ‘next’ version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don’t tag at all for the moment and let me maintain this. The last list of things I have for this build are: OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I’ve still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file. We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features. SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware). Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?). End-User Documentation. Real-world stability (in cars). My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months). Anything I’ve missed? Regards, Mark.

6 73

LWIP lock-up
by Mark Webb-Johnson 06 Apr '18

06 Apr '18

My car managed to repeat the issue with the task lockup I have seen occasionally. The symptom is that network connectivity fails and the async console becomes unresponsive when you issue a command to bring up/down wifi, simcom, etc. The new housekeeping 10 minute ticker worked well for this, and stopped in the middle of the night: … I (134401020) housekeeping: Local time: Sat Mar 24 20:15:45 2018 I (135001020) housekeeping: Local time: Sat Mar 24 20:25:45 2018 I (135601020) housekeeping: Local time: Sat Mar 24 20:35:45 2018 I (136201020) housekeeping: Local time: Sat Mar 24 20:45:45 2018 Looking at the logs after Sat Mar 24 20:45:45, I see: D (136543060) simcom: rx line ch=4 len=19 : +PPPD: DISCONNECTED I (136543070) simcom: PPP Connection disconnected I (136544020) simcom: Lost network connection (+PPP disconnect in NetMode) I (136544020) simcom: State: Enter NetLoss state ... I (136544030) gsm-ppp: Shutting down (hard)... I (136544040) events: Signal(system.modem.down) I (136544040) netmanager: Interface priority is st1 (x.y.z.212/255.255.248.0 gateway x.y.z.64) I (136544050) events: Signal(network.modem.down) I (136544050) netmanager: MODEM down (with WIFI client up): staying with WIFI client priority I (136544060) events: Signal(network.interface.change) OK, so ppp went down (lost network connectivity), and WIFI client was up so we kept with that. The GSM signal is still up (CREG), so we try to reconnect PPP: I (136558160) simcom: PPP Connection is ready to start I (136559020) simcom: State: Enter NetMode state I (136559020) gsm-ppp: Initialising.. ... D (136589180) simcom: rx line ch=4 len=8 : +CREG: 2 I (136589190) simcom: CREG Network Registration: Searching ... D (136589250) simcom: rx line ch=4 len=8 : +CREG: 5^[[0m ^[[0;32mI (136589250) simcom: CREG Network Registration: RegisteredRoaming ... D (136589320) simcom: rx line ch=4 len=8 : +CREG: 2^[[0m ^[[0;32mI (136589320) simcom: CREG Network Registration: Searching ... D (136589380) simcom: rx line ch=4 len=8 : +CREG: 5^[[0m ^[[0;32mI (136589390) simcom: CREG Network Registration: RegisteredRoaming ... D (136601690) simcom: rx line ch=3 len=8 : +CREG: 2^[[0m ^[[0;32mI (136601690) simcom: CREG Network Registration: Searching ... D (136601780) simcom: rx line ch=3 len=8 : +CREG: 5^[[0m ^[[0;32mI (136601780) simcom: CREG Network Registration: RegisteredRoaming ... V (136617440) gsm-ppp: tx: 7e ff 7d 23 c0 21 7d 25 7d 2c 7d 20 20 4e 6f 20 | ~.}#.!}%},} No V (136617440) gsm-ppp: tx: 6e 65 74 77 6f 72 6b 20 70 72 6f 74 6f 63 6f 6c | network protocol V (136617450) gsm-ppp: tx: 73 20 72 75 6e 6e 69 6e 67 4b 8f 7e | s runningK.~ V (136617450) simcom: tx: f9 09 ff 59 7e ff 7d 23 c0 21 7d 25 7d 2c 7d 20 | ...Y~.}#.!}%},} V (136617450) simcom: tx: 20 4e 6f 20 6e 65 74 77 6f 72 6b 20 70 72 6f 74 | No network prot V (136617460) simcom: tx: 6f 63 6f 6c 73 20 72 75 6e 6e 69 6e 67 4b 8f 7e | ocols runningK.~ V (136617460) simcom: tx: a6 f9 | .. V (136617490) simcom: rx: f9 09 ff 25 7e ff 7d 23 c0 21 7d 26 7d 2c 7d 20 | ...%~.}#.!}&},} V (136617500) simcom: rx: 7d 24 8f 7d 3d 7e fb f9 | }$.}=~.. V (136617510) gsm-mux: ProcessFrame(CHAN=2, ADDR=09, CTRL=ff, FCS=fb, LEN=24) V (136617520) gsm-mux: ChanProcessFrame(CHAN=2, ADDR=09, CTRL=ff, LEN=21, IFP=3) V (136617520) gsm-ppp: rx: 7e ff 7d 23 c0 21 7d 26 7d 2c 7d 20 7d 24 8f 7d | ~.}#.!}&},} }$.} V (136617530) gsm-ppp: rx: 3d 7e | =~ I (136617540) gsm-ppp: StatusCallBack: Connection Lost E (136617540) gsm-ppp: status_cb: Connection lost I (136617550) gsm-ppp: Shutdown (via status callback) I (136617550) events: Signal(system.modem.down) I (136617560) netmanager: Interface priority is st1 (x.y.z.212/255.255.248.0 gateway z.y.z.64) I (136617560) gsm-ppp: Attempting PPP reconnecting in 30 seconds... So, while initialising PPP we’ve been told that the cellular network is down (CREG: 2). Then, it flaps up and down like a yoyo, until the PPP connect finally fails. At this point, things go screwy. The simcom tells us the PPP is down, and then we lose the ability to transmit to the modem (or at least log those transmits): V (136618650) simcom: rx: 50 50 50 44 3a 20 44 49 53 43 4f 4e 4e 45 43 54 | PPPD: DISCONNECT V (136618660) simcom: rx: 45 44 0d 0a d4 f9 f9 11 ff 2f 0d 0a 2b 50 50 50 | ED......./..+PPP V (136618660) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=d4, LEN=29) V (136618670) gsm-mux: ChanProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, LEN=26, IFP=3) D (136618680) simcom: rx line ch=3 len=19 : +PPPD: DISCONNECTED I (136618690) simcom: PPP Connection disconnected V (136618690) simcom: rx: 44 3a 20 44 49 53 43 4f 4e 4e 45 43 54 45 44 0d | D: DISCONNECTED. V (136618700) simcom: rx: 0a d9 f9 | ... V (136618710) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=d9, LEN=29) V (136618710) gsm-mux: ChanProcessFrame(CHAN=4, ADDR=11, CTRL=ff, LEN=26, IFP=3) D (136618720) simcom: rx line ch=4 len=19 : +PPPD: DISCONNECTED I (136618730) simcom: PPP Connection disconnected I (136619020) simcom: Lost network connection (+PPP disconnect in NetMode) I (136619020) simcom: State: Enter NetLoss state V (136619030) simcom: tx: f9 0d ff 19 41 54 2b 43 47 41 54 54 3d 30 0d 0a | ....AT+CGATT=0.. V (136619030) simcom: tx: 14 f9 | .. I (136619030) gsm-ppp: Shutting down (hard)...^[[0m I (136619040) events: Signal(system.modem.down)^[[0m I (136619040) netmanager: Interface priority is st1 (x.y.z.212/255.255.248.0 gateway x.y.z.64) V (136632920) simcom: rx: f9 0d ff 0d 0d 0a 4f 4b 0d 0a 0f f9 | ......OK.... V (153076210) simcom: rx: f9 09 ff 1d 0d 0a 2b 43 53 51 3a 20 31 2c 39 39 | ......+CSQ: 1,99 V (153076220) simcom: rx: 0d 0a d1 f9 f9 0d ff 1d 0d 0a 2b 43 53 51 3a 20 | ..........+CSQ: V (153076220) simcom: rx: 31 2c 39 39 0d 0a 13 f9 f9 11 ff 1d 0d 0a 2b 43 | 1,99..........+C V (153076230) simcom: rx: 53 51 3a 20 31 2c 39 39 0d 0a 1e f9 | SQ: 1,99.... V (153202470) simcom: rx: f9 09 ff 1d 0d 0a 2b 43 53 51 3a 20 34 2c 39 39 | ......+CSQ: 4,99 V (153202480) simcom: rx: 0d 0a d1 f9 f9 0d ff 1d 0d 0a 2b 43 53 51 3a 20 | ..........+CSQ: V (153202490) simcom: rx: 34 2c 39 39 0d 0a 13 f9 f9 11 ff 1d 0d 0a 2b 43 | 4,99..........+C V (153202500) simcom: rx: 53 51 3a 20 34 2c 39 39 0d 0a 1e f9 | SQ: 4,99.... V (179212720) simcom: rx: f9 09 ff 1d 0d 0a 2b 43 53 51 3a 20 30 2c 39 39 | ......+CSQ: 0,99 V (179212730) simcom: rx: 0d 0a d1 f9 f9 0d ff 1d 0d 0a 2b 43 53 51 3a 20 | ..........+CSQ: V (179212730) simcom: rx: 30 2c 39 39 0d 0a 13 f9 f9 11 ff 1d 0d 0a 2b 43 | 0,99..........+C V (179212740) simcom: rx: 53 51 3a 20 30 2c 39 39 0d 0a 1e f9 | SQ: 0,99.... V (179242750) simcom: rx: f9 09 ff 1d 0d 0a 2b 43 53 51 3a 20 30 2c 39 39 | ......+CSQ: 0,99 V (179242760) simcom: rx: 0d 0a d1 f9 f9 0d ff 1d 0d 0a 2b 43 53 51 3a 20 | ..........+CSQ: V (179242770) simcom: rx: 30 2c 39 39 0d 0a 13 f9 f9 11 ff 1d 0d 0a 2b 43 | 0,99..........+C V (179242770) simcom: rx: 53 51 3a 20 30 2c 39 39 0d 0a 1e f9 | SQ: 0,99.... V (179246100) simcom: rx: f9 09 ff 19 0d 0a 2b 43 52 45 47 3a 20 32 0d 0a | ......+CREG: 2.. V (179246110) simcom: rx: d6 f9 f9 0d ff 19 0d 0a 2b 43 52 45 47 3a 20 32 | ........+CREG: 2 V (179246110) simcom: rx: 0d 0a 14 f9 f9 11 ff 19 0d 0a 2b 43 52 45 47 3a | ..........+CREG: V (179246120) simcom: rx: 20 32 0d 0a 19 f9 | 2.... V (179251580) simcom: rx: f9 09 ff 1d 0d 0a 2b 43 53 51 3a 20 34 2c 39 39 | ......+CSQ: 4,99 V (179251590) simcom: rx: 0d 0a d1 f9 f9 0d ff 1d 0d 0a 2b 43 53 51 3a 20 | ..........+CSQ: V (179251600) simcom: rx: 34 2c 39 39 0d 0a 13 f9 f9 11 ff 1d 0d 0a 2b 43 | 4,99..........+C V (179251600) simcom: rx: 53 51 3a 20 34 2c 39 39 0d 0a 1e f9 | SQ: 4,99.... I (179290100) wifi: bcn_timout,ap_probe_send_start I (179292610) wifi: ap_probe_send over, resett wifi status to disassoc I (179292610) wifi: state: run -> init (1) I (179292620) wifi: pm stop, total sleep time: 0/138543477 I (179292620) wifi: n:13 0, o:13 0, ap:255 255, sta:13 0, prof:1 The simcom itself seems to be up, and is giving us unsolicited notifications. Finally, the wifi stack falls over (bcn_timeout.ap_probe_sent). This is very nasty, and I suspect will take some time to resolve. We can probably make it more stable by introducing a check for network loss, and requiring the network to be up and stable for N seconds before even attempting a reconnection; but I don’t think that addresses the core issue (which is most likely in the lwip ppp stack). Code-wise, the simcom driver entering ‘NetLoss’ state calls m_ppp.Shutdown(true) (which issues the shutting down (hard) message). Our pppos driver issues the system.modem.down event (which causes netmanager to do it’s thing), and then calls ppapi_close(m_ppp, nocarrier). I suspect that never returns (but don’t know for sure). The other workaround is to enable watchdog timers. I’m 99% certain this sort of lockup would mess up the idle tasks and those would pickup and fire a watchdog timer. So, I’ve gone ahead and committed code to enable the watchdog timers (2 minutes), and make that available as an OTA update: OVMS# ota status Firmware: 3.1.001/ota_0/main (build idf v3.1-dev-453-g0f978bcb Mar 25 2018 14:45:59) Server Available: 3.1.001 The module in my car is now running OTA, so I can verify the OTA update process is smooth (it seems so). Regards, Mark.

3 9

OBDII ECU Documentation, and a request for help
by Greg D. 05 Apr '18

05 Apr '18

Hi folks In a fit of prose, if not Shakespeare, I took a pass at creating the documentation chapter for the OBD2ECU task. Comments, corrections, and general feedback is requested. Is there anything significant missing? Mark, if this looks acceptable, can it be posted to the Google Doc, or send me an invite such that I can do so? Note that I don't have any reference material on the OBDII-to-DB26 cable, other than the wiring. If we eventually have a purchase source, that should get referenced, or lacking that, perhaps pointers to where the connectors can be purchased? Placeholders are noted, but only that. For the EEs in the group, a question: I have both signal and chassis grounds connected together on the OBDII connector; should they be, or just signal ground? I think it would also be helpful to include a table of what metrics are available (supported) on what vehicles, as an aid to those who want to remap things for monitoring on an OBDII HUD or Dongle. A glance at the available documentation didn't turn up anything, so I took a first pass at the table. See the attached, which includes what I know of the Roadster's implementation (since I have one and have studied the code a bit). I would rather not try to guess at the other cars. Could the various vehicle authors contribute their columns to the table? Send me an updated spreadsheet, and I will do the merge. Thanks! Greg

5 14

Crash / reboot loop with log level Info
by Greg D. 04 Apr '18

04 Apr '18

4 24

Re: [Ovmsdev] OVMS v3.1 Availability
by Mark Webb-Johnson 03 Apr '18

03 Apr '18

And we’re sold out of EU kits in the first 5 hours. I’ve even had to redirect some of the stock coming to me, to Fasttech, to cope with demand. There are still US kits available (I guess USA is just waking up now). I hope everyone here who needs one got one. If not, let me know and I’ll see what can be done. Regards, Mark. > On 24 Mar 2018, at 3:52 PM, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: > > > Attn: All OVMS users > > The first batch of production OVMS v3 modules and modems is now available for pre-order from fasttech.com <https://www.fasttech.com/search?ovms>. Specifications, Pricing, and details, follow. > > Bundle Kit: OVMS v3.1 module (US$90) + OVMS v3.1 modem (US$60) > > Existing users: US$130 (uses US$20 Fasttech discount coupon code offered to all existing OVMS v1/v2 users) > New users: US$150. > > Black injection-moulded plastic enclosure > ESP32 WROVER processor (16MB flash, 4MB SPI RAM, 520KB SRAM, dual core 160/240MHz Xtensa LX6 processor) > WIFI 802.11 b/g/n > Bluetooth v4.2 BR/EDR and BLE > 3x CAN buses > 1x Micro USB connector (for flash download and serial console) > 1x Micro SD card slot > 1x Internal expansion slot > 8x EGPIO, 2x GPIO > 1x GSM antenna connector > 1x GPS antenna connector > 1x DB9 vehicle connector > 1x DB26 expansion connector > OVMS v3.1 SIM5360E 3G modem module (either US or EU edition) > Modem is an optional plug-in module, that can be changed in future (to allow for new technology) > 3G (EV-DO/HSPA+) dual band modem > Includes 2G (GSM/GPRS) and 2.5G (EDGE) quad band > GPS/GNSS > Nano (4FF) SIM slot > HOLOGRAM.IO nano sim > US edition is SIM5360A (Dual-Band UMTS/HSPA+ 850/1900MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz) > EU edition is SIM5360J(E) (Dual-Band UMTS/HSPA+ 900/2100MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz) > > First Production Batch > > This first production batch is intended for experienced OVMS v2 users and v3 developers. Please note: > > Firmware is not complete, and should be considered beta > Functionality is approximately equivalent to basic OVMS v2 firmware, but some advanced features (such as ACC, SMS control, etc) are not available yet > Firmware is far in advance of v2 in other aspects (such as built in web server, metrics, console, tcp/ip support, diagnostics, geofencing, scripting, etc) > Firmware can be updated either Over The Air (OTA), by Micro SD card, or over USB interface > Vehicle support currently includes: Kia Soul EV, Nissan Leaf, Renault Twizy, Tesla Roadster > > Antenna and Vehicle Connectors > > The antenna and vehicle connectors for OVMS v3 are the same as for OVMS v2, and existing cables/antennas can generally be re-used for OVMS v3. Note, however, that the frequency ranges supported by individual 3G networks may be different than 2G, so may benefit from an antenna specifically designed for the 3G frequency ranges used. > > Coupon Code and Ordering Arrangements > > For existing OVMS v1 or v2 users, please login to www.openvehicles.com <http://www.openvehicles.com/>, then click My Account, then Vehicles. You will see the Fasttech coupon code next to your registered vehicle. When using the Fasttech ordering system, add the products you want to your cart, click View Cart, then “Have a coupon code?” to enter the code. > > We expect the first stock to arrive next week, and first shipments will start pretty soon after that. > > Should you wish to donate to the project, you can use this link to donate via PayPal: > > https://www.openvehicles.com/helpme <https://www.openvehicles.com/helpme> > > Regards, Mark. >

6 16

Migration of lists.teslaclub.hk to new server
by Mark Webb-Johnson 31 Mar '18

31 Mar '18

I am migrating this lists.teslaclub.hk to a new server, over the next hour or two. During that time, mailing list posts will be queued and not delivered. Delivery should resume after the migration is complete. Regards, Mark

1 1

Webserver "status" crash
by Greg D. 31 Mar '18

31 Mar '18

2 2