[Ovmsdev] Charge Control

[Dominik Westner]

I already did some tests calculating the remaining charge time and had it implemented in the iPhone app.

First I took the simple approach to linearly estimate the remaining time by taking the charge current and voltage and calculate the energy per sec. Then take the missing energy from the current SOC. This will give you an approximation of the remaining time.

If you are looking at +/- 1 hour. This already should work from my experience.

I tried to make it better by taking into account that the charging curve is not linear, but more on a logarithmic scale. This worked a bit better. I also figured that there is some loss when charging, which I set to 5% (this probably varies by temperature).

What I did not know is the fact that once finished charging the batteries will be rebalanced for 30 minutes. Is this still shown as charging in OVMS? If yes, this would explain, why I've been off for about 30 - 60 minutes with my calculation.

I also did not take the age of the battery into account, which should be an important factor, too.

I think that it might be better to use a formula which tries to approximate the charging curve instead of using a fixed lookup table. At least it also could be fine tuned a bit easier by just setting a couple of parameters through the app to change the calculation.

Greetings

Dominik

On 08.04.2012, at 06:16, Tom Saxton wrote:

> I think your model would work pretty well.
> 
> To calculate charge time, you also have to take into account the current
> tapering near the top of the charge.
> 
> We can get most of the required data from log files. The only tricky bit is
> getting the ambient temperature, which I don't think anyone has identified
> in the log files. You could get a good approximating by only considering
> charge sessions that start a least an hour of the most recent drive and then
> use the starting temperature of the coolant as a proxy for ambient
> temperature.
> 
> Range mode is the trickiest and the most important to time, they are also
> done less often, so it's harder to get data. I'd be happy to collect logs
> and extract data if we can get owners to contribute logs for a variety of
> charging levels and ambient temperatures.
> 
>    Tom
> 
> on 4/6/12 5:52 PM, Mark Webb-Johnson wrote:
> 
>> The core question I have here is whether it is possible to build a static
>> table saying that at this temperature, this available voltage+currrent, the
>> charging efficiency is X%? Something accurate enough to give us a charge time
>> prediction (given temperature, kWh needed by the pack, available
>> voltage+current) of +/- 1 hour?
>> 
>> I'm assuming the temperature should be ambient, as that is more important
>> overt the duration of a reasonable charge than pack temperature?
>> 
>> If we can have such a table, with steps of 5 degrees celcius between -10C and
>> +40C, and say 10 current levels, that is only 100 entries - and we would only
>> need 1 byte for each entry. The module could then put in the current
>> temperature, current/voltage level, and get out an efficiency factor. It could
>> estimate the kWh the pack needs (by mode and SOC/ideal-miles difference), then
>> multiply by efficiency factor, and get out an estimate of how many minutes is
>> required to achieve that.
>> 
>> Without this table, we could do the lookup on the server, but that would mean
>> having to set it _every_ night from the App/Server - as it would depend on the
>> SOC% the car was actually at.
>> 
>> If we could build this data, where could we get the data from?
>> 
>> Regards, Mark.
>> 
>> Begin forwarded message:
>> 
>>> From: Mark Webb-Johnson <mark at webb-johnson.net>
>>> Subject: Re: [Ovmsdev] Charge Control
>>> Date: 6 April, 2012 8:25:51 PM GMT+08:00
>>> To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
>>> 
>>> 
>>> Bennett Leeds and I have had a discussion off-list (I'm not sure if he is on
>>> this list or not), and he brings up a valid point about balancing the pack
>>> perhaps not occurring if we cut short the charge with a SOC limit.
>>> 
>>> Looking here:
>>> 
>>> http://www.teslamotorsclub.com/showthread.php/3848-Tesla-Roadster-Battery-Car
>>> e?p=41995&viewfull=1#post41995
>>> 
>>> it seems that this approach may be non-optimal. For clarity, let me
>>> cut-and-paste the Tesla reply here:
>>> 
>>> For simplicity’s sake, I will refer to all SOC (State Of Charge) numbers as a
>>> percentage of a full (100%) charge. I cannot provide exact percentages, as
>>> there are many variables which can cause these numbers to vary slightly,
>>> however, I will get as close as I can.
>>> 
>>> When plugging in a nearly empty car that is set to Storage mode, the charge
>>> will generally stop at around 20%. The car will then settle into its normal
>>> Storage mode rhythm, topping up and discharging between 10% and 50% as the
>>> car sees fit. Oftentimes it will keep a tighter envelope based on parameters
>>> that I am not aware of.
>>> 
>>> Most important to remember is that Storage mode is not intended to be a
>>> driving mode. This charge setting is primarily meant to optimize battery life
>>> while the car is under storage conditions for two weeks or more.
>>> 
>>> Storage mode does not attempt to balance the pack, and you will cause an
>>> imbalance in the pack by driving and charging in this mode regularly.
>>> 
>>> This will penalize you when you do occasionally charge the car fully in the
>>> other modes, as you will not have the full range of the car available to you
>>> until the car has a chance to balance its battery. Additionally, the car’s
>>> range will not be as accurate if driven while in Storage mode vs. having
>>> charged it in Standard mode after storing the car, then driving it.
>>> 
>>> Allowing the car to sit plugged in after it has finished charging in Standard
>>> mode automatically balances the pack, and it may take a few rounds of this to
>>> bring an imbalanced pack back to its full potential after many partial
>>> charges. This is one of the major reasons we recommend keeping the car in
>>> Standard mode whenever possible. Partial charges in any mode, while not on
>>> their own bad for the battery, do not give the car an opportunity to balance
>>> its battery, and over time can prevent you from accessing the car’s full
>>> range potential.
>>> 
>>> When balanced, Standard mode charges the car to about 87%, with Range and
>>> Performance modes getting the car to about 97%. These two percentages are
>>> very much affected by the balance between bricks in the battery. An
>>> imbalanced pack will not fill up all the way in any mode, nor will it be able
>>> to discharge as far. Additionally, the range predictions will not be as
>>> accurate.
>>> 
>>> Your voltages are about right.
>>> 4.10 volts = full standard mode (187-195 ideal miles)
>>> 4.15 volts = full range mode
>>> 4.20 volts = maximum of the cells that we never touch
>>> As you may know, there is much more to it than just using voltage to
>>> calculate range with Lithium batteries. This is something that is incredibly
>>> complicated, and not something that I am qualified to discuss in detail, as I
>>> do not have the full picture.
>>> 
>>> It is important to remember that SOC is not the only factor in maximizing
>>> battery life. For instance most lithium batteries are shipped at around
>>> 30-50% SOC in consumer electronics, and part of the reasoning is that they
>>> are less susceptible to damage from extreme temperatures at these charge
>>> levels. It is also safer to store them at these levels. Part of the benefit
>>> of Storage mode is that there is less work required from the HVAC system to
>>> keep the batteryhappy and safe, and therefore, less energy is consumed while
>>> stored.
>>> 
>>> We chose ~90% as a Standard full charge level because it offers most of the
>>> longevity benefit of keeping the car at a lower state of charge, while still
>>> allowing a high degree of autonomy. I understand that you are interested in
>>> taking extra steps to maximize your battery’s life, so I do have some
>>> suggestions for you.
>>> 
>>> I would not recommend that you continue to use Storage mode as a means of
>>> maintaining a lower state of charge. As I explained earlier, this mode is not
>>> optimized for this type of use.
>>> 
>>> Think of battery degradation this way. It is very much a function of time
>>> spent at voltage and temperature. For instance, you do not want to charge a
>>> car all the way in performance mode, and then let it sit in the sun all day.
>>> Between the higher thermal limits and the high SOC, you are causing the
>>> battery a relatively high amount of degradation .In fact, the car will
>>> eventually allow itself to discharge to Standard levels if left in
>>> Performance mode to prevent inadvertent damage to the battery. If you start
>>> driving right away after charging in Performance or Range Mode, and don’t let
>>> it sit, you would minimize the damage incurred, as the time spent at these
>>> extremes is an important part of the calculation.
>>> 
>>> Similarly, if you top off to full in Standard mode, then jump in the car
>>> right away and bring the SOC down quickly, you will minimize the small amount
>>> of degradation that occurs at ~90%.
>>> 
>>> If you prefer to keep a lower average SOC in an attempt to maximize the life
>>> of your battery, I would instead suggest that you stay in Standard mode and
>>> utilize the Roadster’s built in charge timer and current limiting options to
>>> find an average SOC that works for you. For instance, try starting your
>>> charge at a time that allows the car to top off to a level you are
>>> comfortable with right before you need to leave. Alternately, you can use the
>>> Current limiting function to adjust the amount of time it takes the car
>>> reaches a target SOC, or even a combination of these two options. The car
>>> will remember the settings you select based on your location, so once you
>>> find something that works for your commute, you can set it and forget it.
>>> 
>>> Just remember that the car does benefit from being allowed to sit fully
>>> charged in Standard mode, and should be allowed to do so frequently,
>>> especially if being used on a daily basis. Leaving the car plugged in in
>>> Standard mode after it is done charging will initiate this balancing program
>>> automatically. This doesn’t take much time, 30 minutes or so should do. It
>>> may take several of these balancing cycles to bring the car back to a
>>> balanced state if it has become imbalanced, which is something that a lack of
>>> regular Standard mode top ups and subsequent balancing cycles can induce.
>>> 
>>> It would therefore be a good idea to set the car to “Charge on Plug In”
>>> instead of “Charge at X time” in the charge timing menu for at least a few
>>> Standard mode charges per week to keep the pack balanced. There are simply
>>> too many variables for me to be able to predict how often you would need to
>>> do this, and we do not have a recommended procedure for alternate desired
>>> average SOC levels.
>>> 
>>> I hope this helps answer your questions, and gives you a better idea of how
>>> to maximize battery life under your driving conditions.
>>> 
>>> Regards,
>>> 
>>> Dan Myggen
>>> 
>>> From what he is saying, it appears optimal to time the charge to bring it to
>>> full charge in standard mode 30 minutes before you leave. That would leave
>>> the car sitting at high charge rate for the least amount of time, but allow
>>> enough time for balancing to occur if necessary.
>>> 
>>> This sounds exactly like our finish-charging-by approach. Rather than set the
>>> charge start time, you set the finish time, and the system works out how long
>>> it should take then adds on a 30-to-60 minute safety margin (which would also
>>> allow for battery balancing to occur).
>>> 
>>> Does this make sense? Or is Dan Myggen's advise wrong?
>>> 
>>> Regards, Mark
>>> 
>>> On 5 Apr, 2012, at 7:45 PM, Mark Webb-Johnson wrote:
>>> 
>>>> 
>>>> I'm now starting to think about the v1.3 firmware, which is intended to add
>>>> the following:
>>>> 
>>>> Log charge history
>>>> Log drive history
>>>> Sophisticated control of charge time
>>>> 
>>>> We don't really have TOU metering in Hong Kong, so not much use for me, but
>>>> part [3] would be fun nevertheless. Most charge control in EVs is pretty
>>>> basic, and it might be interesting to see how sophisticated this can be made
>>>> without complications.
>>>> 
>>>> I don't know if this is workable or not, so put my thoughts out into the
>>>> open for discussion.
>>>> 
>>>> For charge time, the consensus seems to be that people want to enter the
>>>> time to FINISH charge, vs the current time to START charge. To do that, we
>>>> need an estimate of how long the charge will take. For that, we either need
>>>> a sophisticated model or a collection of historical data we can lookup to
>>>> find something approximate. Hence item [1] on my list.
>>>> 
>>>> Elon talked about the car learning about you. Where you park. Where you
>>>> charge. etc. So, if always leave home at 7:00am to go to the office on
>>>> Mondays through Fridays, perhaps the car can learn? Or, at least suggest
>>>> based on what it has seen... Hence item [2] on my list.
>>>> 
>>>> For [1], we would store such things as temperatures, SOC start, SOC end,
>>>> charge mode, charge current, charge voltage and duration. The can bus charge
>>>> message seem to include this information.
>>>> 
>>>> For [2], we would store such things as date/time of drive, duration (time,
>>>> distance, and elevation change), battery usage. We seem limited in this from
>>>> what we have decoded on the can bus so far.
>>>> 
>>>> Regardless of the above, [1] and [2] would be useful information for any
>>>> owner, anyway.
>>>> 
>>>> Privacy is an issue. Two problems - (a) protection of my charge/drive
>>>> history, (b) the use of 'shared' charge history for [3]. My suggestion is to
>>>> keep drive and charge history private. Perhaps it could just be stored as
>>>> paranoid mode blobs. But, there should be an option to allow anonymised
>>>> sharing of charge history for the use of [3]. My thinking is that if you
>>>> share your data anonymously, then your lookup includes the pool of others
>>>> anonymous charge history. if you choose not to share, then your lookup is
>>>> only against your own charge history.
>>>> 
>>>> I did toy with the idea of using the server to control this. So, at 3am the
>>>> server sends a command to the car to start the charge, etc. That would
>>>> simplify the firmware in the car, but has a major problem of GPRS
>>>> connectivity - if the cellular signal was lost the charge wouldn't start.
>>>> Bad. So, I think it best to have the historical database in the server, the
>>>> calculations in the App, and the settings downloaded to the car while it has
>>>> cellular signal (after which it just follows them autonomously).
>>>> 
>>>> The Tesla Roadster currently offers you a choice of charge on plug-in, or
>>>> start charge at a particular time. It also allows you to limit charge
>>>> current and set charge mode. My thinking is to extend this by making it per
>>>> day-of-the-week for a few defined locations, and to provide an override for
>>>> the 'current' day/night. If the override is not set, and you are in one of
>>>> the defined locations, then the system looks up the day of the week and
>>>> controls charge based on what you have set. The UI for this is quite simple
>>>> - presumably a screen with tabs/selector for day or the week, and then
>>>> controls to set charge mode, current limit, and time to start/complete by.
>>>> One developer also had the good idea that a charge SOC limit would be useful
>>>> (e.g.; please stop charge when it gets to 70% / 220km ideal).
>>>> 
>>>> How do we handle night vs day charging? Is this only for overnight, or do we
>>>> base it on when you plugin?
>>>> 
>>>> Is this workable? Useful?
>>>> 
>>>> Really interested in people's feedback on this.
>>>> 
>>>> Mark.
>>>> 
>>>> _______________________________________________
>>>> 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