[Ovmsdev] Leaf canbus
Tom Saxton
tom at idleloop.com
Sat May 10 00:48:06 HKT 2014
Mark,
I have this cable with connects the CAR CAN to the Sparkfun board. Sadly,
the pin-out on the DB9 end isn't compatible with the OVMS.
https://www.sparkfun.com/products/10087
It's a straight cable, which I've been connecting via a this Y-cable:
http://www.amazon.com/gp/product/B00EEDOWU8/
The Y-cable points to the left when plugged into the car, which is the
orientation that works best for the Gary Giddings SOC meter we run in the
Leaf.
Tom
On 5/9/14, 6:42 AM, "Mark Webb-Johnson" <mark at webb-johnson.net> wrote:
Tom, Nigel,
What OBDII-OVMS cable are you guys using - left or right? I would like to
see if they are easily modded to switch to EV CAN bus.
Regards, Mark.
On 9 May, 2014, at 3:55 pm, Nigel Jones <nigel at cherrybyte.me.uk> wrote:
> Just a quick FYI. I reconnected the OVMS this morning (with the modified code)
> and it's up and running. I can't check SOC as I'm in the office & not by car
> but it looks as if my build at least worked. That's helpful for
> debugging/making progress ;-)
>
>
> On 9 May 2014 01:26, Tom Saxton <tom at idleloop.com> wrote:
>> Hi Nigel,
>>
>> Some comments on your comments...
>>
>> When the Leaf shuts down probably depends on when the weakest battery module
>> voltage drops below some threshold rather than on the total energy remaining
>> in the pack. So, when it stops will vary by vehicle, conditions, and history.
>> I believe the 6 Gids number came from Tony Williams exhaustive
>> experimentation with early Leafs. If you're driving down to single-digit
>> Gids, you're past the point where the car can accurately predict when it's
>> going to stop.
>>
>> Basing the car_SOC on Gids will have the effect of showing smaller numbers
>> for a full charge as the pack loses capacity. To me this is far preferable to
>> the so-called "True SOC" that will show 100% even when the pack has lost half
>> its capacity. Gids are available on both the Car and EV bus.
>>
>> The EPA range only changed significantly when Nissan removed the 80% charge
>> option. In order for Leaf owners to be able to compare numbers between
>> vehicles, I think it's vital that the conversion from Gids to percent and
>> Gids to ideal miles be invariant across years and models. Ideal miles is an
>> energy measure stated it units that are move convenient than Gids or percent.
>> If it's to be usable as an energy unit, it has to be the same across all
>> Leafs, and not a customizable mapping.
>>
>> It's great to have someone digging into the Leaf implementation of OVMS. Good
>> luck sleuthing!
>>
>> Tom
>>
>> On 5/8/14, 11:54 AM, "Nigel Jones" <nigel at cherrybyte.me.uk> wrote:
>>
>> A few thoughts
>>
>> * When I tested my leaf the car shutdown at 3 GIDS - I think the exact point
>> may depend on cell voltage. I have no idea what the > 2013 MY leaf shows as %
>> on the dash when the car stops, it might be good to get similar to this - but
>> the above is a great 1st pass.
>>
>> * The car_SOC will drop as the car ages/battery life goes down. I think
>> ideally we'd want to offer similar feedback to the in-car display - but I'm
>> aware this isn't on the car can, we need the other message for that
>>
>> * The EPA range differs by MY - a feature (like in the TR code?) may allow
>> this to be configured. This may help with other differences too
>>
>> * Good point about car vs ev can when it comes to what's live. I'm used to
>> leafdd which is on the ev can and is thus able to always display charge etc.
>> It would be really useful, but then given that once charging stops even the
>> ev can isn't available, any active control (heat/charge etc) is not going to
>> be possible with ovms?
>>
>> * Agree on Hx etc... & custom data... the key enabler here is being able to
>> read ev can as above -- either via picking up data from another pin, or by sw
>> bridging
>>
>> * first step (only limited time) I'll build test Mark's latest commit with
>> Tom's update
>>
>> * second step - understand the polling framework and try to read data from
>> EVcan - say % charge
>>
>> * third step - look at cable mod & in addition to above see if I can read
>> some data from car can
>>
>> Slow progress - the embedded side is new to me & limited time but hope i can
>> help :-)
>>
>> Nigel.
>>
>>
>> On 7 May 2014 03:15, Tom Saxton <tom at idleloop.com> wrote:
>>> Mark,
>>>
>>> You're too quick!
>>>
>>> I neglected the other end of the mapping. Since the car stops around 6 Gids,
>>> we should map 6 Gids to 0 ideal miles. So:
>>>
>>> case 0x5b3:
>>> // get raw Gids
>>> car_idealrange = (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5];
>>> // convert Gids to percent
>>> car_SOC = (car_idealrange * 100 + 281/2) / 281;
>>> // convert Gids to EPA rated miles: 6 Gids -> 0 IM, 281 Gids -> 84 IM
>>> car_idealrange = ((car_idealrange-6) * 84 + (281-6)/2) / (281-6);
>>> break;
>>>
>>> Historically the bottom end mapping is not done when converting Gids to
>>> percent SOC. I mixed feelings about doing a better job vs. following
>>> community expectations. Since people in the community aren't doing a fixed
>>> ideal miles calculation, I think it's OK to do it the more correct way.
>>>
>>> The car_SOC calculation will be fine. All the math with be done with 16-bit
>>> ints because car_idealrange forces it. The result may be a couple of points
>>> over 100, but it will always easily fit in an unsigned char.
>>>
>>> On the EV CAN vs. Car CAN bus issue, I wasn't aware that the Car CAN isn't
>>> live during charging. That's not good! LeafSpy demonstrates that we can get
>>> everything interesting from Car CAN. Has anyone demonstrated that all
>>> interesting values are available from the EV CAN? I suppose it doesn't
>>> matter if using the Car CAN won't let OVMS monitor charging.
>>>
>>> Given all that, I have to say the EV CAN is looking like the way to go for
>>> OVMS, but we'll need to figure out how to get at least a few key things like
>>> the odometer which aren't known to exist on the EV CAN.
>>>
>>> Tom
>>>
>>> On 5/6/14, 6:23 PM, "Mark Webb-Johnson" <mark at webb-johnson.net> wrote:
>>>
>>> Tom,
>>>
>>> I just committed this:
>>>
>>>> index 1e17f34..2b695ec 100644
>>>> --- a/vehicle/OVMS.X/vehicle_nissanleaf.c
>>>> +++ b/vehicle/OVMS.X/vehicle_nissanleaf.c
>>>> @@ -92,7 +92,9 @@ BOOL vehicle_nissanleaf_poll1(void)
>>>> }
>>>> case 0x5b3:
>>>> // Rough and kludgy
>>>> - car_SOC = ((((int)can_databuffer[5]&0x01)<<1) +
>>>> ((int)can_databuffer[6])) / 3;
>>>> + car_idealrange = (((int)can_databuffer[4]&0x01)<<8) +
>>>> can_databuffer[5]; // raw Gids
>>>> + car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to
>>>> percent
>>>> + car_idealrange = (car_idealrange * 84 + 140) / 281;
>>>> break;
>>>> }
>>>> return TRUE;
>>>
>>> But, perhaps too simplistic (due to car_SOC being unsigned char). The
>>> car_idealrange is unsigned int, so it may be ok.
>>>
>>> What is your thinking regarding the EV bus vs CAN bus decision?
>>>
>>> Regards, Mark.
>>>
>>> On 7 May, 2014, at 9:13 am, Tom Saxton <tom at idleloop.com> wrote:
>>>
>>>> Mark,
>>>>
>>>> That's exactly what I proposed with the code that converts Gids to EPA
>>>> rated miles; scale 281 Gids to 84 EPA miles.
>>>>
>>>> Still, Leaf nerds will want to see raw Gids, SOH, and Hx so having a way to
>>>> display those sorts of values will be great.
>>>>
>>>> Tom
>>>>
>>>> On 5/6/14, 5:48 PM, "Mark Webb-Johnson" <mark at webb-johnson.net> wrote:
>>>>
>>>> Tom,
>>>>
>>>> In general, I think it best to keep the original meaning of the
>>>> standardised messages and values. So, 'ideal' range is some standardised
>>>> measure of ideal range (based on EPA or whatever the manufacturer suggests)
>>>> and 'estimated' range is based on prior driving habits (or some more
>>>> realistic estimate).
>>>>
>>>> For per-vehicle custom information (such as GIDs), I've been meaning to add
>>>> something to allow that for some time. It is actually fairly simple -
>>>> include a callback hook in the vehicle.{h,c} functions to allow the vehicle
>>>> to output vehicle-specific custom data. I've been thinking we can use
>>>> protocol messages '0' through '9' for this custom information, so it gets
>>>> through to the Apps. The apps themselves can use a custom tab to display
>>>> this in a vehicle-specific manner.
>>>>
>>>> Regards, Mark.
>>>>
>>>> On 7 May, 2014, at 7:16 am, Tom Saxton <tom at idleloop.com> wrote:
>>>>
>>>>> OVMS reports 0% SOC and sends out panicked low battery messages when it's
>>>>> not getting a valid SOC message from the CAN bus. I get this when I screw
>>>>> up the vehicle setting, which is set via the MODULE command. The first
>>>>> thing I'd do is make sure the vehicle type is set correctly. You can see
>>>>> it from the smartphone app on the Vehicle Info screen, look at the Car
>>>>> line. For my set up I see:
>>>>>
>>>>> Car: 2.6.5/TR/V2
>>>>>
>>>>> This says the car is running firmware version 2.6.5, the car type is TR
>>>>> (Tesla Roadster), and it's V2 hardware.
>>>>>
>>>>> You can get the same info by texting MODULE? to the car, which returns the
>>>>> VehicleID, VehicleType, Units (miles or km), and the notifications
>>>>> setting.
>>>>>
>>>>> For the Leaf, you should see NL as the vehicle type.
>>>>>
>>>>> Which CAN bus OVMS reads depends on how the cable is wired. I believe the
>>>>> group consensus is that reading from the CAR CAN bus is the best strategy
>>>>> since we know LeafSpy is able to get everything from the that bus.
>>>>>
>>>>> The code in vehicle_nissanleaf.c that decodes data from message 0x5b3
>>>>> looks like it's trying to pull out the Gid values scaled down to work as a
>>>>> rough SOC %, but it looks like the array offsets are off by one. Dividing
>>>>> by 3 is a rough approximation to multiplying by 100 and dividing by 281 to
>>>>> get the standard conversion from Gids to percent.
>>>>>
>>>>> case 0x5b3:
>>>>> // Rough and kludgy
>>>>> car_SOC = ((((int)can_databuffer[5]&0x01)<<1) +
>>>>> ((int)can_databuffer[6])) / 3;
>>>>> break;
>>>>>
>>>>> Here's a sample message from our Leaf:
>>>>>
>>>>> 5B3 69 BE FF FF FC DD 53 0A
>>>>>
>>>>> When I captured that message, I was reading 221 = 0xDD Gids. Both the Leaf
>>>>> message decoder spreadsheet and the OVMS can_databuffer array start
>>>>> indexing bytes at 0, so byte zero is 0x69, byte 1 is 0xBE, etc. Using the
>>>>> Leaf message decoder spreadsheet, I believe the Gids calculation is: take
>>>>> the low bit of byte 4, shift left by 8 into 16 bits then add byte 5:
>>>>>
>>>>> (((int)0xFC&0x01)<<8) + 0xDD = 0xDD = 221.
>>>>>
>>>>> So I think the code to extract Gids from CAR CAN message 0x5B3 is:
>>>>>
>>>>> (((int)can_databuffer[4]&0x01)<<8) + can_databuffer[5]
>>>>>
>>>>> My thought is that the Gids value should be stored in car_idealrange. Like
>>>>> Gids, the ideal range on the Roadster is an estimate of the state of
>>>>> charge in absolute energy units. An ideal mile is 225.4 Wh; a Gid is 80
>>>>> Wh. The UI on the Smartphone app will have to change, or Gids will have to
>>>>> be scaled.
>>>>>
>>>>> I propose this:
>>>>>
>>>>> car_idealrange = (((int)can_databuffer[4]&0x01)<<8) +
>>>>> can_databuffer[5]; // raw Gids
>>>>> car_SOC = (car_idealrange * 100 + 140) / 281; // convert Gids to
>>>>> percent
>>>>>
>>>>> Optionally, we could do the same thing with Gids that Tesla did to compute
>>>>> ideal miles. The EPA said the Roadster's range is 244 miles, so Tesla
>>>>> equated that with the nominal full capacity of a new Roadster battery, and
>>>>> thus the ideal miles was created. To do the same for the Leaf, take the
>>>>> EPA rating of 84 miles (after Nissan eliminated the 80% charge to get rid
>>>>> of the EPA's stupidity in taking the range to be the average of the 100%
>>>>> and 80% charge levels). After using the raw gids to compute the SOC
>>>>> percent, convert to EPA rated miles:
>>>>>
>>>>> car_idealrange = (car_idealrange * 84 + 140) / 281;
>>>>>
>>>>> We can also get the SOH value out of message 0x5B3. According to the
>>>>> spreadsheet, it's the top seven bits in byte one, so
>>>>>
>>>>> soh = can_databuffer[1] >> 1;
>>>>>
>>>>> For my sample message above, that's 0xBE >> 1 = 0x5F = 95, which agrees
>>>>> with the SOH reported by LeafSpy when I did that data capture.
>>>>>
>>>>> BTW, SOH and Hx appear to be different, but perhaps related. I'm trying to
>>>>> figure that out. I suspect SOH is just the Hx value rounded, but I have
>>>>> some data from the Plug In America Leaf survey which contradicts that. The
>>>>> value in message 0x5BE doesn't have enough bits to be the higher
>>>>> resolution Hx.
>>>>>
>>>>> Tom
>>>>>
>>>>> On 5/6/14, 11:39 AM, "Nigel Jones" <nigel at cherrybyte.me.uk> wrote:
>>>>>
>>>>> I have the OVMS module running in my car so found an hour tonight to start
>>>>> looking through the source - sorry it's taking a while to catch up, so
>>>>> forgive the newbie questions too......
>>>>>
>>>>> One thing I noticed is that I'm getting a 0% state of charge indication,
>>>>> and regular texts saying my battery is low (for testing I setup the sim
>>>>> with unlimited texts.....). I see there was a commit last year which used
>>>>> some of the data from the spreadsheet at
>>>>>
>>>>> https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQM
>>>>> y1ON2xZSzlMUXc#gid=0
>>>>>
>>>>> which I found references from the nissan leaf forum discussion at
>>>>> http://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=340
>>>>>
>>>>> If I'm not mistaken the OVMS currently reads the CAR CanBus ?
>>>>>
>>>>> There's an indication in the spreadsheet that CAN message 0x5b3 contains
>>>>> SOC information - but in fact the spreadsheet refers to it as SOH. I have
>>>>> a leafDD and I think this is also known as the Hx figure -- ie it seems to
>>>>> vary with battery age/capacity -- mine for example is down to around 82%,
>>>>> but it is not current state of charge, so I don't think decoding that will
>>>>> help?
>>>>>
>>>>> GIDs are what I use in daily driving as they are absolute. The sheet
>>>>> suggests that figure might be retrievable from this message, but then most
>>>>> people would only see a % of 95% for example as life is lost? Is that's
>>>>> what's wanted? I suspect not for the overall SOC figure.
>>>>>
>>>>> I can't see much else decoded yet (I was looking for low hanging fruit!)
>>>>> on the CAR canbus - instead most work was done on the EV canbus, including
>>>>> looking at state of charge etc.
>>>>>
>>>>> So the question comes how to bridge the data from that bus onto the CAR
>>>>> can. There was reference to this previously on the list at
>>>>>
>>>>> http://lists.teslaclub.hk/pipermail/ovmsdev/2013-October/001712.html
>>>>>
>>>>> It would appear the way to get any of the EV can data is to actively
>>>>> request the data. I can see examples of CAN data requests in the tesla
>>>>> module but haven't yet figured how I might for example retrieve CAN msg
>>>>> 0x5bb for example (it's one of the ones to try). I can also see the
>>>>> developers guide p24 which refers to writing on the bus. I'm also wary of
>>>>> the need to be careful in making active requests rather than the easier
>>>>> passive monitoring! Can anyone point me to an example of how I might do
>>>>> this? I'd make that call from the ticker functions? and then handle it in
>>>>> the poll right?
>>>>>
>>>>> Apologies if this is all covered in the nissan leaf forum thread - I have
>>>>> 39 pages to read now...
>>>>>
>>>>> Thanks
>>>>> Nigel.
>>>>> nigel at cherrybyte.me.uk
>>>>>
>>>>> --
>>>>> ----
>>>>> Nigel Jones
>>>>> _______________________________________________ OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsd
>>>>> ev
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>
>>>> _______________________________________________ OvmsDev mailing list
>>>>
OvmsDev at lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsde>>>>
v
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________ OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>
>>
>>
>> --
>> ----
>> Nigel Jones
>> _______________________________________________ OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>
>
>
> --
> ----
> Nigel Jones
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140509/9f66d69a/attachment.htm>
More information about the OvmsDev
mailing list