- OvmsDev - Open Vehicles

Cables
by Mark Webb-Johnson 03 May '18

03 May '18

FYI Here is our current cable standard (for normal OBDII, not including Nissan Leaf, Tesla Roadster, and Tesla S). This standard is valid for OBDII connectors except for Nissan Leaf (where primary and alternate CANs have been historically switched). At some point it would be good to get away from that proprietary Nissan Leaf cable, but we’d need to do it in a transparent way (presumably by listening on both buses for traffic, before transmitting anything, and then deciding which is which dynamically). For DB9 cables: Pinout “C" J1962-M DB9-F Signal 4 3 Chassis/Power GND 6 7 CAN-H (primary CAN) 14 2 CAN-L (primary CAN) 13 5 CAN-H (alternate CAN) 12 4 CAN-L (alternate CAN) 16 9 +12V Vehicle Power J1962 end should be MALE plug with angle cable. DB9 end should be FEMALE. Both ends should be enclosed in shells, and cable should be 1metre in length. We also have a new standard cable for OBDII HUDs/Dongles, called “HUD”. This cable plugs into the OVMS v3 diagnostic port and provides power and signal to simulate an OBDII (female end) port. Cable design for the new “HUD” cable is attached below. For DA26 cables: Pinout: “HUD" J1962-F DA26-M Signal 4 8 Chassis/Power GND 5 8 Chassis/Power GND 6 16 CAN-H (primary CAN) 14 6 CAN-L (primary CAN) 16 18 +12V Vehicle Power Notes: • Require 120ohm resistor between DA26 pins 16 and 6 (this can be either at J1962 or DA26 ends). • J1962 pins 4 and 5 are both connected to single DA26 pin 8. • J1962 end should be FEMALE plug with moulded straight cable. DA26 end should be MALE. • Both ends should be enclosed in shells, and cable should be 15cm in length. I’ve (re)ordered stock of these just now, and paid for 400 of them (200 left, 100 right, 100 HUD). We should have them up on Fasttech in about 10 days. Regards, Mark.

2 1

Re: [Ovmsdev] Issue #99, Can't turn off SIMCOM power
by Stephen Casner 02 May '18

02 May '18

As I commented on Issue #99, I created the problem with SIMCOM not powering off because I had excluded CONFIG_OVMS_COMP_MAX7317 from the config and the power to the SIMCOM is controlled through the MAX7317 chip. Would it make sense in Kconfig for config OVMS_COMP_MODEM_SIMCOM to depend upon OVMS_COMP_MAX7317? -- Steve

2 3

Automatic OTA updates
by Mark Webb-Johnson 02 May '18

02 May '18

Woke up and checked my car this morning, to find: Loving the new automatic OTA update feature. Regards, Mark.

2 1

3.1.005
by Mark Webb-Johnson 01 May '18

01 May '18

We are now 102 commits beyond 3.1.004. Time for a 3.1.005? I just want to get the CAC metric working for Tesla Roadster (which I should be able to get done today). After that, I am ready. Anything else blocking this release? OK to build? Regards, Mark

4 17

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

Firmware updates, EU server
by Michael Balzer 30 Apr '18

30 Apr '18

It seems users are not aware they should do a firmware update ASAP after receiving the module. I have advised the german users to do so, maybe we should add that to the manual as well. I now provide the following URLs for firmware updates on my server: * The latest official release: o ovms.dexters-web.de/f/v3.1/release.bin * My latest build: o ovms.dexters-web.de/f/v3.1/current.bin o …with git log since release at: https://ovms.dexters-web.de/f/v3.1/current.log Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 1

Mongoose update
by Michael Balzer 28 Apr '18

28 Apr '18

Netmanager/Mongoose: use interface specific DNS servers Note: *mongoose update involved*, issue "*git submodule update*". This switches mongoose to use LWIP getaddrinfo() as it is superior to the mongoose resolver. Netmanager then stores DNS servers acquired by connections and restores them accordingly as the default interface changes. Should solve issue #43 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/43>. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 1

Re: [Ovmsdev] PCAP CAN bus dump
by Tom Parker 27 Apr '18

27 Apr '18

https://carrott.org/pcaps/ These were captured with tcpdump and an USB can interface with slcan driver. I post processed them to byte swap the can ID with https://carrott.org/git/leaf-can-dissector.git/blob/HEAD:/pcap-canid-endian… I don't know why tcpdump and wireshark disagree on the byte order of the can id. On Apr 27, 2018 5:24 PM, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: > > > Has anybody got an example of a PCAP format canbus dump file? Some dump from a car in a suitable format for loading into wireshark (pcap not pcapng). > > If so, please eMail to me (mark(a)webb-johnson.net) or give me a link to where I can download from. > > I need it to verify that OVMS can read/write to that format. > > Thanks, Mark. >

3 5

PCAP CAN bus dump
by Mark Webb-Johnson 26 Apr '18

26 Apr '18

Has anybody got an example of a PCAP format canbus dump file? Some dump from a car in a suitable format for loading into wireshark (pcap not pcapng). If so, please eMail to me (mark(a)webb-johnson.net <mailto:mark@webb-johnson.net>) or give me a link to where I can download from. I need it to verify that OVMS can read/write to that format. Thanks, Mark.

1 0