- OvmsDev - Open Vehicles

Dead OVMS
by Geir Øyvind Vælidalo 04 Mar '19

04 Mar '19

Hi guys, My newest OVMS-unit just died. It’s the one I use for development on the e-Niro :-( Opening it up, I noticed that the outermost pin on C1 was loose and a few of the pins on the modem was bent. I can’t flash the ESP as it won’t respond at all. Is the quality control good enough? Anyone else got problems with their unit? I have opened at ticket at fasttech, so I hope I can get it sorted out quickly. I had such a good momentum :-( Regards, Geir

2 1

Callout for JDM Nissan Leaf VINs
by Anko Hanse 03 Mar '19

03 Mar '19

This is related to feature requests #180 and #181 (automatic detection of model-year and battery size). For USA and EU style VINs we might have a method of deriving the year and battery size. Unfortunately cars made for the Japanese Domestic Market and frequently imported 2nd hand into Australia and New Zealand do not use a VIN but instead have some sort of serial number in the form of ZE0-123456 or AZE0-123456. I have posted a request on a NZ forum (www.geekzone.co.nz<http://www.geekzone.co.nz/>) for people to email me their JDM style VIN combined with year (and possibly month) and battery size. Note that LeafSpy-Pro also toggles with another VIN-like number, I'm interested in that too if people can get it. If not then just the ZE0- or AZE0- number is fine... Possibly any NZ OVMS users seeing this post can do the same and also email me those details or reply here. For privacy reasons I would suggest to mask the lowest digits of your VINs, i.e: AZE0-2003xx, Dec 2015, 30kwh, 230JT11122000xxx Hopefully that will give us some new insights... I very much hope our collective powers can confirm that ZE0-1xxxxx and AZE0-1xxxxx is 24kwh, AZE0-2xxxxx is 30kwh, AZE1-1xxxxx is 40kwh and possibly AZE1-2xxxxx will be 62kwh :-)

3 14

Power states clarification
by Greg D. 02 Mar '19

02 Mar '19

Hi folks (mostly Mark, probably), I just noticed that there is a power command for OBD2ECU as well as ext12v. I understand (or thought I did) what controlling the ext12v power does, but how is "power" related to OBD2ECU? Is this related to firing up the opened CAN bus, or is there some tie to the ext12v power? I have manually created scripts for vehicle.on and vehicle.off to explicitly control ext12v, so that an attached HUD will follow the key. We talked about having this sort of thing done automatically, but I didn't think it was ever implemented, nor what the particulars would be regarding some of the device corner cases. Is that what is happening here? Related, what do the other states do? (Sleep, deepsleep, etc.) Thanks, Greg

3 3

RETOOLS web
by Mark Webb-Johnson 25 Feb '19

25 Feb '19

Michael, this is probably for you - but if anybody else can help please do… I am trying to see how hard it would be to do a web based interface to the RETOOLS system. Presumably this would appear in the menu as Tools / Reverse Engineering (or some such abbreviation if that is too long). The basic screen would look something like this: +----------------------------------------------------------------------------------------------------+ | | | +----------+ +------+-------+------------------------------------+------+ +--------------------+ | | | | | hdr1 | hdr2 | hdr3 | hdr4 | | | | | | | +------+-------+------------------------------------+------+ | | | | | Controls | | | | | | | Info | | | | | | col1 | col2 | col3 | col4 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +----------+ | | | | | +--------------------+ | | | | | | | | | +----------+ | | | | | +--------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Status | | | | | | | | | | | | | | | TABLE | | | | | | | | | | | | | | Extra | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +----------+ | | | | | +--------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +------+-------+------------------------------------+------+ | | | +----------------------------------------------------------------------------------------------------+ The controls are just a set of controls - things that bring up dialogs for more information or perform actions. Like start/stop RE, switch modes, manipulate DBC files, etc. Left justified in the frame, and perhaps 10% of the width. Height can dynamically adjust with the text content. The Status, Info, and Extra panes are just a dynamically updated text panes. Main code needs to be able to send text here and have it shown in the appropriate pane. Right justified in the frame and perhaps 30% of the width. Height can dynamically adjust with the text content. The TABLE is a table. Probably 5 columns by many rows (anywhere from 20 to 200 or so). Either paged, scrolling, or just very tall. Paged is probably preferable. Would need a simple mechanism to dynamically add/update a row (identified by ‘key’ column and in sorted order), presumably using the web socket. Also need something to be able to dynamically clear the entire table. The RETOOLS code would use this to update the table in realtime (presumably over a web socket). It would be good if the table could do things like search filtering of displayed rows, column sorting, etc (all client side - something like datatables.net) For example, look at this output: OVMS# re dbc list key records ms last can1/100:0081 2 22000 01 02 03 04 05 | ..... can1/101 1 44000 01 02 03 04 | .... dbc/DI_Signal1: 129 km dbc/DI_Signal2: 1 km dbc/DI_Signal3: 130 kWh dbc/DI_Signal4: 122 Degrees The idea is to be able to show the key, records, ms, last, and ascii dump in the main table. Then, clicking on a row would show the statistics for that message in the Info pane, and DBC signals in the Extra pane. I can handle the RETOOLS side, but the javascript is beyond me. I also had a look at the ovms web server framework, but it doesn’t seem to be able to do the table part (yet)? Any idea how complex this is? Regards, Mark.

4 11

Leaf charge time estimates
by Robin O'Leary 24 Feb '19

24 Feb '19

https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/207 This adds support for 6 metrics ("xnl.v.c.duration....") reporting the Leaf BMS's time estimates in minutes for various hypothetical charging conditions: * to 100% charge (".full") * to 80% charge (".range") * with power ~1.6kW (".l0") * with power ~3.3kW (".l1") * with power ~6.7kW (".l2") I find them useful, although they don't seem to fit in the existing OVMS charge reporting framework, which expects an on-going charge before it calculates any estimate. They may also help us reverse-engineer whether the BMS expects temperature, cell state, tapering near full, etc. to affect the duration, if we want to make our own time estimation algotithm, On my Leaf (which has the 6.6kW charger), the dash display normally shows two charge time estimates: at 3.3kW power ("xnl.v.c.duration.full.l1") and at 6.6kW power ("xnl.v.c.duration.full.l2"). My model has the option for "Long life battery mode"; when this is enabled, it instead shows the values to 80% ("xnl.v.c.duration.range.l1", "xnl.v.c.duration.range.l2").

2 1

Nissan Leaf - Stop Charge
by Lance Tjessem 19 Feb '19

19 Feb '19

You'd think there would be a way to stop charging - if you have the vehicle plugged in but not charging and start climate control it will activate charging, then stop charging when you turn CC off. Also, lock/unlock don't seem to work on my 2015 S, is it only for specific models?

2 1

Nissan Leaf - Stop Charge
by Mark Webb-Johnson 17 Feb '19

17 Feb '19

Interesting question on a support ticket: Why is ‘stop charge’ not implemented on Nissan Leaf? We have vehicle codes for door lock/unlock and start charge, but not stop? Regards, mark.

2 1

OTA download incremental progress no longer happens
by Craig Leres 17 Feb '19

17 Feb '19

When doing an OTA download the download progress used to incrementally display, e.g. it would start with: Processing… (do not interrupt, may take some minutes) and then slowly spit out a bunch of lines like this: Downloading... (100029 bytes so far) And then finish with a form offering to reboot or whatever. This has been broken for a few versions now. Basically when you start the OTA download you get the initial dialog and then nothing happens until the download completes and then you see the rest of the output at once. I normally use firefox but the behavior is the same with chorme. Craig

3 3

Collecting information on the Fiat 500e
by Jason Perkins 14 Feb '19

14 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

DBC and Endian-ness
by Mark Webb-Johnson 11 Feb '19

11 Feb '19

I’ve been going round and round in circles on this, most of the weekend, but not getting anywhere. I’ve rewritten the Decoder code four times so far, but just can’t get it to work. So calling for help here. I attach the DBC specification. You can also find an extensive python library here: https://github.com/eerimoq/cantools.git (for anyone playing with DBC, that seems an excellent library and set of command line tools) The seemingly simple problem that I am trying to solve is: Given a CAN frame, we need to decode a particular signal. We want the integer value (signed or unsigned) out of it. The signal species the start bit, size (number of bits), endian-ness (big or little), and value type (signed or unsigned). The DBC specification says: The start_bit value specifies the position of the signal within the data field of the frame. For signals with byte order Intel (little endian) the position of the least-significant bit is given. For signals with byte order Motorola (big endian) the position of the most significant bit is given. The bits are counted in a saw-tooth manner. byte_order = '0' | '1' (* 0=little endian, 1=big endian *) The byte_format is 0 if the signal's byte order is Intel (little endian) or 1 if the byte order is Motorola (big endian). There are also factor and offset values for signals, but that is irrelevant for the moment (trivial to apply once we have the actual integer raw signal value extracted) and can be ignored for the moment. Wikipedia explains endian-ness: In big-endian format, whenever addressing memory or sending/storing words bytewise, the most significant byte—the byte containing the most significant bit—is stored first (has the lowest address) or sent first, then the following bytes are stored or sent in decreasing significance order, with the least significant byte—the one containing the least significant bit—stored last (having the highest address) or sent last. Little-endian format reverses this order: the sequence addresses/sends/stores the least significant byte first (lowest address) and the most significant byte last (highest address). So, we have two strange things in the DBC specification: (1) the start bit is not always the first bit in the stream, and (2) this ’saw-tooth manner’ comment. So, I create a very simple DBC, and run it through the cantools dump to visualise it: $ cat mark.dbc BU_: WS200 MCN_Powertrain BO_ 1 LittleEnd: 8 WS200 SG_ OneByte : 7|8@0+ (1,0) [0|0] "" Vector__XXX SG_ TwoByte : 15|16@0+ (1,0) [0|0] "" Vector__XXX SG_ TwelveBit : 39|12@0+ (1,0) [0|0] "" Vector__XXX $ cantools dump mark.dbc ================================= Messages ================================= ------------------------------------------------------------------------ Name: LittleEnd Id: 0x1 Length: 8 bytes Cycle time: - ms Senders: WS200 Layout: Bit 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ 0 |<-----------------------------x| +---+---+---+---+---+---+---+---+ +-- OneByte +---+---+---+---+---+---+---+---+ 1 |<------------------------------| +---+---+---+---+---+---+---+---+ 2 |------------------------------x| +---+---+---+---+---+---+---+---+ B +-- TwoByte y +---+---+---+---+---+---+---+---+ t 3 | | | | | | | | | e +---+---+---+---+---+---+---+---+ 4 |<------------------------------| +---+---+---+---+---+---+---+---+ 5 |--------------x| | | | | +---+---+---+---+---+---+---+---+ +-- TwelveBit +---+---+---+---+---+---+---+---+ 6 | | | | | | | | | +---+---+---+---+---+---+---+---+ 7 | | | | | | | | | +---+---+---+---+---+---+---+---+ Signal tree: -- {root} +-- OneByte +-- TwoByte +-- TwelveBit ------------------------------------------------------------------------ I also used 'cantools generate_c_source mark.dbc’ to generate a C decoder for this, and this is what it looks like: int mark_little_end_unpack( struct mark_little_end_t *dst_p, const uint8_t *src_p, size_t size) { if (size < 8u) { return (-EINVAL); } memset(dst_p, 0, sizeof(*dst_p)); dst_p->one_byte |= unpack_right_shift_u8(src_p[0], 0u, 0xffu); dst_p->two_byte |= unpack_left_shift_u16(src_p[1], 8u, 0xffu); dst_p->two_byte |= unpack_right_shift_u16(src_p[2], 0u, 0xffu); dst_p->twelve_bit |= unpack_left_shift_u16(src_p[4], 4u, 0xffu); dst_p->twelve_bit |= unpack_right_shift_u16(src_p[5], 4u, 0xf0u); return (0); } Let’s look at that TwoByte value. This is little endian, so the least significant byte should come first in p[1] followed by the most significant in p[2]. So, why does the generator produce: dst_p->two_byte |= unpack_left_shift_u16(src_p[1], 8u, 0xffu); dst_p->two_byte |= unpack_right_shift_u16(src_p[2], 0u, 0xffu); From what I can see, that means take p[1] and shift it left 8, then add on p[2]. That seems big endian, not little endian? Let’s try a big endian example: BO_ 3 BigEnd2: 8 WS200 SG_ EightBit2 : 5|8@1+ (1,0) [0|0] "" Vector__XXX SG_ OneByte2 : 16|8@1+ (1,0) [0|0] "" Vector__XXX SG_ TwelveBit2 : 48|11@1+ (1,0) [0|0] "” Vector__XXX Bit 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ 0 |----------x| | | | | | +---+---+---+---+---+---+---+---+ 1 | | | |<------------------| +---+---+---+---+---+---+---+---+ +-- EightBit2 +---+---+---+---+---+---+---+---+ 2 |<-----------------------------x| +---+---+---+---+---+---+---+---+ B +-- OneByte2 y +---+---+---+---+---+---+---+---+ t 3 | | | | | | | | | e +---+---+---+---+---+---+---+---+ 4 | | | | | | | | | +---+---+---+---+---+---+---+---+ 5 | | | | | | | | | +---+---+---+---+---+---+---+---+ 6 |------------------------------x| +---+---+---+---+---+---+---+---+ 7 | | | | | |<----------| +---+---+---+---+---+---+---+---+ +-- TwelveBit2 Notice the weird alignment of EightBit2 and TwelveBit2? I presume that is the ’saw-tooth’ pattern talked about in the DBC specification. A Tesla Model S encodes values like the battery temperature in CAN ID 0x102, and we decode this in C like this: StandardMetrics.ms_v_bat_temp->SetValue((float)((((int)d[7]&0x07)<<8)+d[6])/10); So that is little endian (d[7] is shifted right, followed by d[6] normally - so d[7] is the MSB and d[6] the LSB). But how to represent that in DBC? BO_ 1 LittleEnd2: 8 WS200 SG_ TwoByte : 47|11@0+ (1,0) [0|0] "” Vector__XXX Bit 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ 0 | | | | | | | | | +---+---+---+---+---+---+---+---+ 1 | | | | | | | | | +---+---+---+---+---+---+---+---+ 2 | | | | | | | | | +---+---+---+---+---+---+---+---+ B 3 | | | | | | | | | y +---+---+---+---+---+---+---+---+ t 4 | | | | | | | | | e +---+---+---+---+---+---+---+---+ 5 |<------------------------------| +---+---+---+---+---+---+---+---+ 6 |----------x| | | | | | +---+---+---+---+---+---+---+---+ +-- TwoByte +---+---+---+---+---+---+---+---+ 7 | | | | | | | | | +---+---+---+---+---+---+---+—+ dst_p->two_byte |= unpack_left_shift_u16(src_p[5], 3u, 0xffu); dst_p->two_byte |= unpack_right_shift_u16(src_p[6], 5u, 0xe0u); That doesn’t work. How about big endian? BO_ 1 BigEnd2: 8 WS200 SG_ TwoByte : 48|11@1+ (1,0) [0|0] "” Vector__XXX Bit 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ 0 | | | | | | | | | +---+---+---+---+---+---+---+---+ 1 | | | | | | | | | +---+---+---+---+---+---+---+---+ 2 | | | | | | | | | +---+---+---+---+---+---+---+---+ B 3 | | | | | | | | | y +---+---+---+---+---+---+---+---+ t 4 | | | | | | | | | e +---+---+---+---+---+---+---+---+ 5 | | | | | | | | | +---+---+---+---+---+---+---+---+ 6 |------------------------------x| +---+---+---+---+---+---+---+---+ 7 | | | | | |<----------| +---+---+---+---+---+---+---+---+ +— TwoByte dst_p->two_byte |= unpack_right_shift_u16(src_p[6], 0u, 0xffu); dst_p->two_byte |= unpack_left_shift_u16(src_p[7], 8u, 0x07u); That seems correct. Looking in the source for cantools dbc (cantools/cantools/database/can/formats/dbc.py), I see: byte_order=(0 if signal.byte_order == 'big_endian' else 1), This code also says the same thing (0 = big endian): https://github.com/julietkilo/CANBabel/blob/master/src/main/java/com/github… boolean isBigEndian = "0".equals(splitted[2]); WTF? There is this (from googling), which makes things clear as mud: https://github.com/ebroecker/canmatrix/wiki/signal-Byteorder https://se.mathworks.com/help/vnt/ug/canpack.html https://github.com/ebroecker/SocketCandecodeSignals/blob/master/datenbasis.… https://github.com/julietkilo/CANBabel/blob/master/src/main/java/com/github… My conclusions are that: The DBC specification is incorrect, in that 0 is big endian, and 1 is little endian in the public code we see. and/or The DBC specification is incorrect, in that all CAN bus byte ordering is little endian, and the byte_order setting only affects the interpretation of the bit_ordering, and saw-tooth decode/encode. But that really makes no sense to me. This is supposed to be the defacto standard for automotive CAN bus signal definition - how can it be such a mess? Help? Mark

2 2