[Ovmsdev] Leaf canbus
Nigel Jones
nigel at cherrybyte.me.uk
Fri May 9 23:20:29 HKT 2014
This is mine
Also I note that with that new message decode I'm still not seeing any
battery level reported just 0. I'll try to debug when I get a chance
On 9 May 2014 14:42, "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=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1ON2xZSzlMUXc#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.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>> _______________________________________________
>>> 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
>>> _______________________________________________
>>> 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
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> ----
> 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/d86a6234/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20140509_161801_Frogmore Ln.jpg
Type: image/jpeg
Size: 2038434 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140509/d86a6234/attachment-0002.jpg>
More information about the OvmsDev
mailing list