Storing Calibration Data
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.
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@lists.teslaclub.hk on behalf of tom@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
One more twist is that 2016 models (SV and SL) have the 30kWh battery (not the 24). Lots more gids so going to a gid based scheme is good as long as you don't think 281 is the max number of gids. My 2016 Leaf SL will charge to 363 gids. Phil H. On Mon, May 2, 2016 at 9:02 AM, Tom Saxton <tom@idleloop.com> 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@lists.teslaclub.hk on behalf of tom@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi Phil, That's why I was careful to specify 24 kWh in my comments. It would be great to get your numbers into the Plug In America Leaf survey. You can be the first 30 kWh owner to contribute. http://www.pluginamerica.org/surveys/batteries/leaf/survey.php Tom
On May 2, 2016, at 10:25 AM, phil hochstetler <phil.hochstetler@gmail.com> wrote:
One more twist is that 2016 models (SV and SL) have the 30kWh battery (not the 24). Lots more gids so going to a gid based scheme is good as long as you don't think 281 is the max number of gids. My 2016 Leaf SL will charge to 363 gids.
Phil H.
On Mon, May 2, 2016 at 9:02 AM, Tom Saxton <tom@idleloop.com> 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@lists.teslaclub.hk on behalf of tom@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Done. On Mon, May 2, 2016 at 10:52 AM, Tom Saxton <tom@idleloop.com> wrote:
Hi Phil,
That's why I was careful to specify 24 kWh in my comments.
It would be great to get your numbers into the Plug In America Leaf survey. You can be the first 30 kWh owner to contribute.
http://www.pluginamerica.org/surveys/batteries/leaf/survey.php
Tom
On May 2, 2016, at 10:25 AM, phil hochstetler <phil.hochstetler@gmail.com> wrote:
One more twist is that 2016 models (SV and SL) have the 30kWh battery (not the 24). Lots more gids so going to a gid based scheme is good as long as you don't think 281 is the max number of gids. My 2016 Leaf SL will charge to 363 gids.
Phil H.
On Mon, May 2, 2016 at 9:02 AM, Tom Saxton <tom@idleloop.com> 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@lists.teslaclub.hk on behalf of tom@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 05/03/2016 05:25 AM, phil hochstetler wrote:
One more twist is that 2016 models (SV and SL) have the 30kWh battery (not the 24). Lots more gids so going to a gid based scheme is good as long as you don't think 281 is the max number of gids. My 2016 Leaf SL will charge to 363 gids.
I've made the "maximum gids" value configurable when in fixed gids SOC mode. In sinking lid mode, the firmware will work it out by itself (because it uses the largest gids value seen). The different battery sizes don't make a difference to the range calculations because they're based on the current gids and a miles per gids constant. I made that constant configurable so you can fiddle with it to suit your model year and situation, though driving a few km/h faster on the motorway probably makes more difference than the model year.
Parameter space is getting tight, but there seems to be space after ACC. 0x14 and 0x15. Regards, Mark.
On 3 May 2016, at 7:12 PM, Tom Parker <tom@carrott.org> wrote:
On 05/03/2016 05:25 AM, phil hochstetler wrote:
One more twist is that 2016 models (SV and SL) have the 30kWh battery (not the 24). Lots more gids so going to a gid based scheme is good as long as you don't think 281 is the max number of gids. My 2016 Leaf SL will charge to 363 gids.
I've made the "maximum gids" value configurable when in fixed gids SOC mode. In sinking lid mode, the firmware will work it out by itself (because it uses the largest gids value seen).
The different battery sizes don't make a difference to the range calculations because they're based on the current gids and a miles per gids constant. I made that constant configurable so you can fiddle with it to suit your model year and situation, though driving a few km/h faster on the motorway probably makes more difference than the model year. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 05/06/2016 03:13 PM, Mark Webb-Johnson wrote:
Parameter space is getting tight, but there seems to be space after ACC. 0x14 and 0x15.
https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/e4213e93... looks like each feature is stored in a separate parameter but only uses 1 out of 32 bytes? When we actually run out, I think we can refactor to pack more than one feature into each parameter? I found 0x14 and 0x15 were free too and things are working well using them.
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@lists.teslaclub.hk on behalf of tom@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
In C, integer calculations truncates instead of rounding. 99/100 = 0. Adding half of the denominator to the numerator causes the calculation to round up, i.e., (99 + 50) / 100 = 1. That's great for positive values, the case here, but isn't the right thing for negative values. Gary Gidding's original SOC meter didn't round, so that's been the de facto standard in the Leaf world. As for configuration, I think there's real value in having a pack energy number, like rated miles, that isn't configurable so it can be compared between owners. If the parameters change, I think it should be based on model configuration (which I'm hoping can be determined from the CAN bus), and not from owner configuration. Tom On 5/3/16, 4:07 AM, "Tom Parker" <ovmsdev-bounces@lists.teslaclub.hk on behalf of tom@carrott.org> wrote:
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@lists.teslaclub.hk on behalf of tom@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Tom, if you want to store data that cannot be changed directly by the user, consider using a memory structure and base64 or binary storage in some parameter slot(s). That gives you 32 byte storage space per parameter slot, and you can combine multiple parameters if you need more. Have a look at the Twizy code: parameters 16..21 are marked as binary and exluded from direct manipulation. They contain struct twizy_cfg_profile data and can only be changed indirectly through a specific command extension. Regards, Michael Am 03.05.2016 um 18:13 schrieb Tom Saxton:
As for configuration, I think there's real value in having a pack energy number, like rated miles, that isn't configurable so it can be compared between owners. If the parameters change, I think it should be based on model configuration (which I'm hoping can be determined from the CAN bus), and not from owner configuration.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
What I proposed was using data from the CAN bus to determine the Leaf pack size, then based on that use the appropriate nominal new pack Gids and rated range to calculate rated range from current SOC. I don't think that would require storing any parameter data. It's like the options on the Roadster based on v1.5 or v2.x. Tom On 5/6/16, 10:30 AM, "Michael Balzer" <ovmsdev-bounces@lists.teslaclub.hk on behalf of dexter@expeedo.de> wrote:
Tom,
if you want to store data that cannot be changed directly by the user, consider using a memory structure and base64 or binary storage in some parameter slot(s). That gives you 32 byte storage space per parameter slot, and you can combine multiple parameters if you need more.
Have a look at the Twizy code: parameters 16..21 are marked as binary and exluded from direct manipulation. They contain struct twizy_cfg_profile data and can only be changed indirectly through a specific command extension.
Regards, Michael
Am 03.05.2016 um 18:13 schrieb Tom Saxton:
As for configuration, I think there's real value in having a pack energy number, like rated miles, that isn't configurable so it can be compared between owners. If the parameters change, I think it should be based on model configuration (which I'm hoping can be determined from the CAN bus), and not from owner configuration.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 05/07/2016 07:22 AM, Tom Saxton wrote:
What I proposed was using data from the CAN bus to determine the Leaf pack size, then based on that use the appropriate nominal new pack Gids and rated range to calculate rated range from current SOC. I don't think that would require storing any parameter data. It's like the options on the Roadster based on v1.5 or v2.x. I'm happy to do something like that, but I'd need someone to explain how to tell the difference between a 30kWh battery and a 24kWh battery.
Can we get the VIN from the EV CAN bus? I know it's on the Car CAN bus, but I'm behind on the current state of knowledge on what's know about getting info from the EV Bus. I suspect the battery size is encoded in the VIN, but from some poking around online I'm guessing that encoding is in the Leaf service manual, which is behind a pay wall. Tom On 5/7/16, 4:12 PM, "Tom Parker" <ovmsdev-bounces@lists.teslaclub.hk on behalf of tom@carrott.org> wrote:
On 05/07/2016 07:22 AM, Tom Saxton wrote:
What I proposed was using data from the CAN bus to determine the Leaf pack size, then based on that use the appropriate nominal new pack Gids and rated range to calculate rated range from current SOC. I don't think that would require storing any parameter data. It's like the options on the Roadster based on v1.5 or v2.x. I'm happy to do something like that, but I'd need someone to explain how to tell the difference between a 30kWh battery and a 24kWh battery.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 05/08/2016 11:45 AM, Tom Saxton wrote:
Can we get the VIN from the EV CAN bus? I know it's on the Car CAN bus, but I'm behind on the current state of knowledge on what's know about getting info from the EV Bus.
https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/e4213e93... decodes the VIN but on my car at least, it doesn't work. There associated poll requests set up in https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/e4213e93... cause a relay to go click every 30s or so while the car is charging, so it's doing something, but on my car, not the right thing. In my branch I disabled the poll requests to stop the relay clicking and haven't come back to look at why it doesn't work yet.
I suspect the battery size is encoded in the VIN, but from some poking around online I'm guessing that encoding is in the Leaf service manual, which is behind a pay wall.
The earlier manuals are at https://carmanuals2.com/brand/nissan/leaf-2012-372 and I can't find a VIN decode in them, but maybe my search fu is weak.
On 05/04/2016 04:13 AM, Tom Saxton wrote:
In C, integer calculations truncates instead of rounding. 99/100 = 0. Adding half of the denominator to the numerator causes the calculation to round up, i.e., (99 + 50) / 100 = 1. That's great for positive values, the case here, but isn't the right thing for negative values. Gary Gidding's original SOC meter didn't round, so that's been the de facto standard in the Leaf world.
Thanks for the explanation, I've already removed the 140 and it sounds like putting it back will move further from Gary's algorithm so I won't put it back.
As for configuration, I think there's real value in having a pack energy number, like rated miles, that isn't configurable so it can be compared between owners. If the parameters change, I think it should be based on model configuration (which I'm hoping can be determined from the CAN bus), and not from owner configuration.
Would it be better to expose the raw number of gids for comparison, so there's no confusion about what the numbers mean? I've got some rudimentary historical data reporting that sends the current gids. I don't think there is a way to see the historical data other than the HTTP api? I've not yet tried to be compatible with the Twizzy historical format, and I don't have anything to visualize the data I am sending (I've mostly used it as a channel for debugging).
Tom, historical records can be downloaded via perl as well, and the android App contains some statistics on the Twizy records. My web frontend (dexters-web.de) also offers the data in CSV format and can send a daily report on them by mail. You don't need to be compatible with the Twizy format, the "RT-" prefix denominates a car specific record type. Define "NL-..." records as appropriate. If you think we can generalize some record type, propose a "*-" record type. Regards, Michael Am 08.05.2016 um 01:09 schrieb Tom Parker:
Would it be better to expose the raw number of gids for comparison, so there's no confusion about what the numbers mean? I've got some rudimentary historical data reporting that sends the current gids. I don't think there is a way to see the historical data other than the HTTP api?
I've not yet tried to be compatible with the Twizzy historical format, and I don't have anything to visualize the data I am sending (I've mostly used it as a channel for debugging).
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
participants (5)
-
Mark Webb-Johnson -
Michael Balzer -
phil hochstetler -
Tom Parker -
Tom Saxton