[Ovmsdev] Leaf canbus
Tom Saxton
tom at idleloop.com
Wed May 7 10:15:35 HKT 2014
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=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1O
>> N2xZSzlMUXc#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/ovmsdev
>> _______________________________________________
>> 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
_______________________________________________ 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/20140506/ebeabcfd/attachment.htm>
More information about the OvmsDev
mailing list