[Ovmsdev] Storing Calibration Data

Tue May 3 19:07:43 HKT 2016

Thanks for the feedback. The leaf firmware in ovms master already 
implements pretty close to what you describe:

car_SOC = (gids * 100 + 140) / 281;
car_idealrange = (gids * 84 + 140) / 281;

I'm not sure what the + 140 is trying to do, especially since it's added 
after the multiplication. I've removed this offset in my branch.

I had changed the SOC calculation in my branch to a sinking lid (ie full 
charge gives 100% SOC) but kept the Ideal Range calculation. I've now 
added a config switch to choose between these two SOC algorithms or to 
use the LBC's SOC value (I haven't implemented that last one yet).

Rather than exposing the 84 and 281 constants used in the Ideal Range 
calculation, I'm using a single miles per gid constant so that it is 
easier to parse the configuration parameter (84 miles on 281 gids is 
0.298 miles per gid (when you truncate) times 1000 for faster integer 
math) but this doesn't actually change the result.

There is a difference in efficiency between the various model years 
(Wikipedia quotes 73, 75 & 84 for the 24kWh battery). Hence I've made 
the miles per gid configurable so the estimated range can be modified. I 
haven't yet tried to work out what the best value for my car and driving is.

On 05/03/2016 04:02 AM, Tom Saxton wrote:
> As a 2011 Leaf owner, I'd rather have a number that shows an estimate of how much energy is available in the pack rather than a percentage of a constantly-varying pack capacity. 100% means one thing when you have a new full pack in the summer and something else entirely in the winter after losing 2 capacity bars. A remaining energy estimate is an easy number to compute, just use gids or gids divided by gids for a nominal new pack (281 for a 24 kWh pack).
>
> For compatibility with Gary Gidding's original SOC meter, use (100 * gids / 281), done in integer math so it truncates instead of rounds.
>
> It's arguably more intuitive to express the pack energy as miles, but such a range estimate is always going to be wonky. The car can know how you've driven recently, but can't know how you're going to drive. If you've got lots of charge (the most common case) you can drive however you like. If you're low on the charge, the case that matters the most, you want to know how much energy is the pack to inform your driving decisions. Can I make it if I turn off the HVAC? Do I need to get off the freeway and drive lower speed highways? Can I make it to that next charging station, or do I need to look for less traditional charging (an outlet at a 7-11, etc.)?
>
> For that, I need an energy number, not an SOC number based on a varying pack capacity, and not a range estimate based on how I have been driving. A true, unadulterated energy number.
>
> One could express the energy number as gids or kWh, but those are pretty nerdy numbers. A more intuitive approach is to use the EPA (or NEDC) range estimate for a full, new, nominal pack and scale from there. For the 24 kWh Leaf, the EPA rating is 84 miles, so to calculate rated miles remaining in the pack use (84 * gids / 281).
>
> Just like a range estimate based on your recent driving, the rated range won't tell you how many miles you'll get, but you can easily develop intuition. In moderate weather, at a steady highway speed (55 to 60 mph) on level road, you can get mile-for-mile. At steady 40 mph, you can get even better. Cold weather, higher speeds and climbing elevation will all reduce your range, and you'll build up intuition for that.
>
> The rated ranged also gives drivers a standard number they can compare with other drivers who likely have different driving style and conditions.
>
> Building that intuition from a SOC percent based on changing capacity or a range estimate based on recent driving is much more difficult.
>
> OVMS has support for both a rated range (called ideal range because that's what the Roadster called that calculation) and estimated range based on recent driving.
>
> That just leaves the question of how to compute the SOC percentage, and I personally prefer current energy divided by the original pack capacity rather than the degraded pack capacity. As I lose capacity, I want that number fully visible in the SOC I see after a charge.
>
> We've lost one capacity bar in our Leaf. When we do a full charge, we see 79.0% on the Gid meter and when we do an "80%" charge we see 66.9%. As those numbers change, I know how to adjust my expectations and my driving so I don't get surprised.
>
>     Tom
>
>
> On 5/2/16, 3:51 AM, "Tom Parker" <ovmsdev-bounces at lists.teslaclub.hk on behalf of tom at carrott.org> wrote:
>
>> Hi,
>>
>> The Leaf's range estimate is pretty wonky as it's strongly influenced by
>> your recent consumption. A much better range estimate is obtained from
>> the current gids (approximately the kWh stored in the battery) and a
>> Wh/km value. The Gen 2 Leaf is a little more efficient and I'm guessing
>> people might want to adjust the value, so this efficiency probably
>> shouldn't be hard coded into the firmware.
>>
>> I'm currently using the gids value to calculate state of charge, based
>> on the maximum gids that the car can hold (as the battery degrades it
>> can't store so many gids, so the SOC calculation needs to know this. I'm
>> currently using the largest gids value seen since startup. Every period,
>> I set the maximum gids to the largest I've seen in the period (currently
>> 60 days) to allow the maximum gids to sink as the battery degrades.
>>
>> I've since found the BMS's state of charge field and may abandon this
>> complex gids based SOC and use whatever the Lithium Battery Controller
>> thinks the state of charge is. The car also knows it's Wh/km (it's
>> displayed on the dashboard) so if I could locate that data in the CAN
>> bus, I could replace the hard coded efficiency with something based off
>> that.
>>
>> In the meantime, I'd like to store both the efficiency and the maximum
>> gids in parameters so they're visible to the user and they can be changed.
>>
>> Is it safe to use Parameter 0x14 and 0x15 (20 and 21 in the app) to
>> store calibration data? These parameters don't seem to be defined or
>> used and the android app will let you modify them.
>>
>> Thanks.
>> _______________________________________________
>> 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