February 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

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

04 Apr '18

4 24

v3 hardware disconnecting from v2 server
by Tom Parker 27 Mar '18

27 Mar '18

Hi, I've been struggling for some time with intermittent disconnections from the v2 server. I've switched from hologram to a local cellular provider's sim card, to match my v2 hardware which is very stable and the problem persists. With the car stationary, the connection seems very solid, but on the move, it usually disconnects within half an hour. I'm running 98169d8862db2bbc4bea14d013883f26ee6afb4e (from 2018-01-19) with idf 5bf85d06d8c402fe30ecb1bf9c09d5e69b923b2f and xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2.0.tar.gz. I tried logging to the sdcard and on my desk powered by USB that seemed to work well, but it didn't work very well (only a few lines logged to the sdcard and then the whole system seemed to crash) when powered from the OBD2 port. I haven't tried to debug that. With the sdcard logging turned off, and logging with minicom I can get good diagnostics. It would appear that the v3 hardware thinks it is still connected and continues to send data, but the v2 server thinks the client has disconnected. I've got ovms logs which have regular lines quoting the local time from the modem, and server logs from the dexters-web server which I think are not UTC. Anyway, 05:47 in the server log corresponds to 17:47 in the ovms v3 log. The relevant lines of the logs are below. On the server log the ovms v3 hardware client is #72 and then #94. We can see the client sent and the server received S messages at :47:15 and :47:32. The client sent more messages that were not received by the server, more than I've transcribed here (full log attached). The server recorded a disconnect at :48:29, but the client recorded the transmission of messages in it's log for minutes after that. I did a simcom status command which reports that everything is connected, and then I pressed the button to reboot the module. The server records a new connection at :54:07 and the messages logged as transmitted on the client start to correspond with the messages logged as received on the server start again. Thoughts on how to proceed? Another oddity not shown here but included in the full logs is that the client sent a lot of D messages shortly after reconnecting. Server Log: 2018-01-26 05:47:15,36664,'#72 C rx msg S 90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,392.00,96' 2018-01-26 05:47:15,36665,'#72 C rx msg D 128,0,5,0,0,33,0,0,0,79663,32,1,1,1,12.9231,0,0,128,0,0' 2018-01-26 05:47:15,36666,'#72 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2018-01-26 05:47:15,36667,'#72 C rx msg F 3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,6,1,NL,2degrees' 2018-01-26 05:47:32,36717,'#72 C rx msg S 90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,387.00,96' 2018-01-26 05:48:29,36926,'#72 C got error: Connection reset by peer' 2018-01-26 05:50:08,37206,'#93 A got login' 2018-01-26 05:51:24,37485,'#36 A rx msg A ' 2018-01-26 05:52:53,37742,'#93 A got error: Broken pipe' 2018-01-26 05:52:54,37745,'#72 A got login' 2018-01-26 05:54:07,37937,'#94 C got login' 2018-01-26 05:54:13,37957,'#94 C rx msg S 87,K,0,0,stopped,standard,73,0,0,0,0,0,13,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,385.50,0' 2018-01-26 05:54:13,37958,'#94 C rx msg D 128,0,5,0,0,33,0,0,104,59,28,1,0,0,13.011,0,0,128,0,0' 2018-01-26 05:54:13,37959,'#94 C rx msg L 0,0,0,0,0,0,104,0,0,0,0' 2018-01-26 05:54:13,37960,'#94 C rx msg W 0,0,0,0,0,0,0,0,0' 2018-01-26 05:54:13,37961,'#94 C rx msg F 3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,1,1,NL,2degrees' 2018-01-26 05:54:15,37964,'#94 C rx msg D 128,0,5,0,0,33,0,0,104,60,28,1,0,0,13.011,0,0,128,0,0' 2018-01-26 05:54:15,37965,'#94 C rx msg D 128,0,5,0,0,33,0,0,104,61,28,1,0,0,13.011,0,0,128,0,0' Serial Console Log: OVMS > I (79663340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,392.00,96 I (79663340) ovms-server-v2: Send MP-0 D128,0,5,0,0,33,0,0,0,79663,32,1,1,1,12.9231,0,0,128,0,0 I (79663340) ovms-server-v2: Send MP-0 L0,0,0,0,0,0,0,0,0,0,0 I (79663350) ovms-server-v2: Send MP-0 F3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,6,1,NL,2degrees OVMS > D (79665360) simcom: rx line ch=3 len=11 : +CSQ: 10,99 D (79665360) simcom: rx line ch=4 len=11 : +CSQ: 10,99 OVMS > D (79674380) simcom: rx line ch=3 len=11 : +CSQ: 13,99 D (79674390) simcom: rx line ch=4 len=11 : +CSQ: 13,99 OVMS > D (79678420) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79678420) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:47:26+52" D (79678420) simcom: rx line ch=3 len=11 : +CSQ: 13,99 D (79678420) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79678420) simcom: rx line ch=3 len=2 : OK OVMS > I (79681340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,387.00,96 OVMS > D (79683370) simcom: rx line ch=3 len=10 : +CSQ: 9,99 D (79683370) simcom: rx line ch=4 len=10 : +CSQ: 9,99 OVMS > D (79692410) simcom: rx line ch=3 len=10 : +CSQ: 3,99 D (79692420) simcom: rx line ch=4 len=10 : +CSQ: 3,99 OVMS > D (79708420) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79708420) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:47:56+52" D (79708420) simcom: rx line ch=3 len=10 : +CSQ: 3,99 D (79708420) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79708420) simcom: rx line ch=3 len=2 : OK OVMS > D (79713470) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79713470) simcom: rx line ch=4 len=10 : +CSQ: 7,99 OVMS > D (79716420) simcom: rx line ch=3 len=10 : +CSQ: 0,99 D (79716420) simcom: rx line ch=4 len=10 : +CSQ: 0,99 OVMS > I (79724340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,392.00,96 I (79724340) ovms-server-v2: Send MP-0 D128,0,5,0,0,33,0,0,55,79724,30,1,1,1,13.022,0,0,128,0,0 I (79724350) ovms-server-v2: Send MP-0 L0,0,0,0,0,0,55,0,0,0,0 I (79724350) ovms-server-v2: Send MP-0 F3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,0,1,NL,2degrees OVMS > D (79738360) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79738360) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:48:26+52" D (79738360) simcom: rx line ch=3 len=10 : +CSQ: 0,99 D (79738360) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79738360) simcom: rx line ch=3 len=2 : OK OVMS > D (79740490) simcom: rx line ch=3 len=10 : +CSQ: 4,99 D (79740500) simcom: rx line ch=4 len=10 : +CSQ: 4,99 OVMS > I (79741340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,388.50,96 OVMS > D (79764490) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79764490) simcom: rx line ch=4 len=10 : +CSQ: 7,99 OVMS > D (79768360) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79768360) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:48:56+52" D (79768360) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79768360) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79768360) simcom: rx line ch=3 len=2 : OK OVMS > D (79773490) simcom: rx line ch=3 len=10 : +CSQ: 3,99 D (79773500) simcom: rx line ch=4 len=10 : +CSQ: 3,99 OVMS > D (79779500) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79779500) simcom: rx line ch=4 len=10 : +CSQ: 7,99 OVMS > I (79785340) ovms-server-v2: Send MP-0 S89,K,0,0,stopped,standard,75,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.00,96 ... OVMS > simcom status SIMCOM Network Registration: RegisteredHome State: NetMode Ticker: 25111 User Data: 0 Mux Open Channels: 4 PPP Connected on channel: #2 PPP Last Error: None GPS: disabled GPS time: disabled NMEA (GPS/GLONASS) Not Connected ... I rebooted the module and it did the normal connection dance ... D (48359) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:53:57+52" ... I (57609) ovms-server-v2: Status: Connecting... OVMS > I (58219) ovms-server-v2: Connection successful I (58219) ovms-server-v2: Status: Logging in... I (58219) ovms-server-v2: Sending server login: MP-C 0 pwLSijW/3qAZ6z0LOBHbGS rnkkhqHUA6zeZqLx1q1Tow== NZLV3 OVMS > I (58889) ovms-server-v2: Got server response: MP-S 0 QTjRAp8ZQPJQV1UXnepldQ w1vWpIrRR9+eot9z3uslgw== I (58889) ovms-server-v2: Server token is QTjRAp8ZQPJQV1UXnepldQ and digest is w1vWpIrRR9+eot9z3uslgw== I (58899) ovms-server-v2: Status: Server auth ok. Now priming crypto. I (58899) ovms-server-v2: Shared secret key is QTjRAp8ZQPJQV1UXnepldQpwLSijW/3qAZ6z0LOBHbGS (44 bytes) I (58899) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established OVMS > I (59189) ovms-server-v2: Incoming Msg: MP-0 Z4 I (59189) ovms-server-v2: One or more peers have connected I (59339) ovms-server-v2: Send MP-0 S87,K,0,0,stopped,standard,73,0,0,0,0,0,13,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,385.50,0

6 72

3.1 Production
by Mark Webb-Johnson 11 Mar '18

11 Mar '18

It is with great relief that I can announce I just wrote a very big cheque to produce the first batch of 120 OVMS v3.1 modules. That is on top of the last big cheque I wrote a couple of months ago for the injection moulding. The order is in, and production has started. Specifically, I’ve ordered: 120x OVMS v3.1 modules (cased in black injection moulded enclosures) 60x OVMS 3G modems with EU frequencies 60x OVMS 3G modems with US frequencies These include WROVER modules with dual processor cores, 16MB flash and 4MB SPI RAM. Also all the other OVMS v3 features such as Wifi, Bluetooth, 3x CAN buses, SD CARD, GPIOs, external 12V power control, pluggable modem modules, OTA firmware updates, etc. 100 (50x EU, 50x US) of these will go direct to FastTech for end users. 20 will come to me in Hong Kong for developers and special users. We have enough stock of the other cables, antennas, etc, already at FastTech. I’ll announce pricing in the next few days. There will be special pricing for everybody here (developers) as well as existing users who want to upgrade. This first batch are early production units, with beta firmware, intended for expert users only. To all those that have contributed to the project so far, we owe a huge debt of thanks. We’ve still got a long way to go with the firmware, but It feels good to finally get this out the door. I’m confident that we have a fantastic base on which to build great things in the coming years. Regards, Mark.

7 15

System date set?
by Stephen Casner 03 Mar '18

03 Mar '18

Does the sytem date get set anywhere (presumably from GPS)? This question occurred to me as I'm working on a side project using the DEVKIT-C module which won't have access to GPS so I added the code to set the data using SNTP. -- Steve

4 13

Igor Medvedev
by Mark Webb-Johnson 28 Feb '18

28 Feb '18

I got a ‘hello’ eMail from a new developer interested in helping out with OVMS. His name is Igor, and for the last 17 years he has been working on embedded projects. He drives a Nissan Leaf, and has a background with 3G modems and CAN protocols like CANOPEN. He is asking what tasks he can help out with. Perhaps reviewing the SIMCOM modem support (for reliability) and/or helping Tom out with Nissan Leaf support? Anybody else got any suggestions for Igor? Regards, Mark.

4 6

OVMS v3.1 Release Candidate
by Mark Webb-Johnson 28 Feb '18

28 Feb '18

I fixed the issue with SIMCOM UART. It was another compatibility issue with SDCARD. The GPIO4 and GPIO13 we are using for v3.1 simcom modem are SD_DATA1 and SD_DATA3. Even though I had set SDCARD to 1-line mode, the ESP IDF driver was still reserving all those GPIO pins for itself (at hardware controller level). A 1-line (sic) change to our SD-CARD component fixes this and frees SD_DATA1, SD_DATA2, SD_DATA3 for our other uses. With firmware fix made, I can mount the SD CARD, and run ‘test sd’ while talking to simcom modem. All ok. CAN2 is now also ok. I re-flowed the solder on that part of the board, and all looks good now. OVMS > can can1 start active 1000000 Can bus can1 started in mode active at speed 1000000Kbps OVMS > can can2 start active 1000000 Can bus can2 started in mode active at speed 1000000Kbps OVMS > can can3 start active 1000000 Can bus can3 started in mode active at speed 1000000Kbps OVMS > can log trace CAN logging active: Type:trace; Path:''; Filter:off; Vehicle:; Note: info logging is done at log level debug, frame logging at verbose OVMS > log level verbose Logging level for * set to verbose OVMS > can can1 tx standard 100 01 02 03 04 V (66710) canlog: TX can1 id 100 len 4: 01 02 03 04 | .... V (66710) canlog: RX can2 id 100 len 4: 01 02 03 04 | .... V (66710) canlog: RX can3 id 100 len 4: 01 02 03 04 | …. OVMS > can can2 tx standard 100 01 02 03 04 V (73230) canlog: TX can2 id 100 len 4: 01 02 03 04 | .... V (73230) canlog: RX can1 id 100 len 4: 01 02 03 04 | .... V (73230) canlog: RX can3 id 100 len 4: 01 02 03 04 | .... OVMS > can can3 tx standard 100 01 02 03 04 V (80380) canlog: TX can3 id 100 len 4: 01 02 03 04 | .... V (80380) canlog: RX can1 id 100 len 4: 01 02 03 04 | .... V (80380) canlog: RX can2 id 100 len 4: 01 02 03 04 | .... OVMS > can can1 status CAN: can1 Mode: Active Speed: 1000000 Interrupts: 4 Rx pkt: 2 Rx err: 0 Rx ovrflw: 0 Tx pkt: 2 Tx delays: 0 Tx err: 0 Tx ovrflw: 0 Err flags: 0 D (88210) canlog: Status can1 intr=4 rxpkt=2 txpkt=2 errflags=0 rxerr=0 txerr=0 rxovr=0 txovr=0 txdelay=0 OVMS > can can2 status CAN: can2 Mode: Active Speed: 1000000 Interrupts: 4 Rx pkt: 3 Rx err: 0 Rx ovrflw: 0 Tx pkt: 1 Tx delays: 0 Tx err: 0 Tx ovrflw: 0 Err flags: 0 D (90770) canlog: Status can2 intr=4 rxpkt=3 txpkt=1 errflags=0 rxerr=0 txerr=0 rxovr=0 txovr=0 txdelay=0 OVMS > can can3 status CAN: can3 Mode: Active Speed: 1000000 Interrupts: 4 Rx pkt: 3 Rx err: 0 Rx ovrflw: 0 Tx pkt: 1 Tx delays: 0 Tx err: 0 Tx ovrflw: 0 Err flags: 0 D (92910) canlog: Status can3 intr=4 rxpkt=3 txpkt=1 errflags=0 rxerr=0 txerr=0 rxovr=0 txovr=0 txdelay=0 So 16MB Flash, 4MB SPIRAM, ESP32, modem, CAN, EGPIO, and SDCARD are all ok. I will test the remaining few peripherals tonight (need 12v power). I think we are going to be ok now. Component orders have been placed. I’m going to order a first batch of 120 modules tonight (assuming no issues with the last few peripherals). Regards, Mark.

3 4