[Ovmsdev] Leaf canbus
Nigel Jones
nigel at cherrybyte.me.uk
Fri May 9 15:55:05 HKT 2014
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140509/c72e800f/attachment.htm>
More information about the OvmsDev
mailing list