[Ovmsdev] Estimating charge duration (complete charge by Š time)
Tom Saxton
tom at idleloop.com
Fri Aug 24 00:42:50 HKT 2012
This seems like a great data set, and will get more helpful as it gets
larger.
One question about the data summary: is the kWh the same as what's shown on
the touchscreen after a charge? If so, that the energy pulled from the wall,
not the energy added to the battery. From a quick look at the data summary,
that seems like what it is.
To be useful to timing the charges I care the most about, the model needs to
take into account the tapering that occurs near the top of the charge, which
is especially critical for range mode charges.
If you look at the graph "Current vs SOC" on my blog about Roadster charging
rates and efficiency, you can see the shape of the envelope that limits the
current draw as a function of SOC.
http://www.saxton.org/tom_saxton/2010/07/tesla-roadster-charging-rates.html
That graph isn't quite right; what we really want is maximum charge rate as
a function of SOC, but I think we can get that pretty easily.
So, I think the right model is to parameterize energy loss to overhead and
cooling as a function of ambient temperature (and perhaps battery
temperature), reduce the available power by that amount, to get the maximum
available charge rate, then cap that charge rate by the Roadster's maximum
charge rate envelope.
There are a few things that make this more complex.
1. How does reduced battery capacity affect the charge rate envelope? At the
very least, OVMS will need to have an idea the car's capacity.
2. Range mode prioritizes cooling the battery pack, which affects the
charging overhead.
3. Do we care about Performance mode charging? I haven't studied that at
all.
4. It seems to me that cooling is reduced when charging at 120V, so that may
also require some special handling.
Recently, Rod (of Rod and Barbara on TMC) pointed out that the spreadsheet
on JB's blog about Roadster efficiency and range implies that JB models the
usable capacity of a new Roadster battery pack as 55 kWh.
http://www.teslamotors.com/blog/roadster-efficiency-and-range
This implies that 244 ideal miles = 55 kWh. This agrees very closely with
what Rod had calculated empirically from reported energy use via the trip
meter. So, that's when I've been using lately to convert between ideal miles
and energy.
I'm very interested in getting the charge end time feature so I can time
range mode charges to end very close to my planned departure time on road
trips, but it will be at least a week before I can devote time to working on
the data set.
Tom
on 8/23/12 6:30 AM, Mark Webb-Johnson wrote:
> In order to provide a feature 'complete charge by time', we need to be able to
> estimate how long the charge will take.
>
> Looking at anonymised historical logs from ovms, we have records for a few
> hundred completed charges, over a range of temperatures and current/voltage
> conditions. The ovms logs are not perfect, but they do cover a large variety
> of conditions. Paranoid mode cars are excluded from the results (or, perhaps
> better written as can't be included because we can't see the data). I have
> cleaned them to remove overtly wrong data (-1Amp charges, aborted charges,
> etc). What remains are the records for 360 charges.
>
> For privacy reasons, we've been dumping these logs after a couple of days, so
> I only have the last few days from TMC and then a several month batch from a
> few cars early on in the days of OVMS (from the www.openvehicles.com
> development server). I am going to make arrangements to keep an anonymised
> form of this (basically the charges.csv format) in future, even from TMC, in
> order to get as much historical data as possible. I'm guessing that the more
> data, the better and more accurate model we can build.
>
> I've attached to this eMail a csv containing the data, and a simple perl
> program I knocked up to display it in various ways. It would probably be
> better to do this in excel, but I haven't had time to do that yet.
>
> The fields in the charges.csv are:
>
> $key - A unique key for the charge record (assuming no-one starts a charge in
> the same microsecond :-)
> $mode - The charge mode
> $wmax - The maximum Watts (current x voltage) seen as used during the charge
> $s_tambient - The ambient temperature (celcius) at the start of the charge
> $s_tbattery - The battery (ESS) temperature (celcius) at the start of the
> charge
> $e_tambient - The ambient temperature (celcius) at the end of the charge
> $e_tbattery - The battery (ESS) temperature (celcius) at the end of the charge
> $s_soc - The SOC% (varies by mode) at the start of the charge
> $e_soc - The SOC% (varies by mode) at the end of the charge
> $soc = $e_soc-$s_soc - The increase in SOC%
> $s_kmi - The ideal kilometers at the start of the charge
> $e_kmi - The ideal kilometers at the end of the charge
> $kmi = $e_kmi - $s_kmi - The increase in ideal kilometers as a result of the
> charge
> $duration - The duration (in minutes) of the charge, as indicated by the car
> $kwh - The kWh put into the battery (ESS), for the charge, as indicated by the
> car
>
> eg; 20120220062307.716156,standard,5980,4,32,10,21,6,97,91,18,301,283,529,52
> 5.9kW charge, 4C ambient at start of charge, SOC 6% -> 97% (= +91% SOC), 18kmi
> -> 301kmi (= +283kmi), 529 minutes, 52kWh
>
> My chargetables.pl code tries to crunch this data in a few ways. Here is the
> output from the small set we have:
>
> NUMBER OF SAMPLES:
> kWh,Temp 0 1 2 3 4 5 6 7 8 9 10
> 11 13 14 16 17 TOTAL
> 0 0 0 5 0 0 0 0 2 0 1 0
> 0 0 0 0 0 8
> 10 0 0 12 5 0 5 0 2 0 1 0
> 0 0 0 0 0 25
> 15 2 0 24 7 6 14 1 6 0 0 0
> 1 0 0 0 0 61
> 20 4 4 23 12 4 12 2 7 2 1 3
> 3 1 0 0 0 78
> 25 3 5 27 6 1 16 5 7 0 3 12
> 2 1 0 0 0 88
> 30 2 2 6 4 2 5 1 4 1 6 1
> 0 1 1 0 0 36
> 35 0 2 1 1 0 5 1 3 0 21 7
> 0 2 0 5 0 48
> 40 0 0 1 1 0 1 0 1 2 4 1
> 0 0 0 4 1 16
>
> KM(IDEAL)/MINUTE:
> kWh,Temp 0 1 2 3 4 5 6 7 8 9 10
> 11 13 14 16 17
> 0 ----- ----- 0.19 ----- ----- ----- ----- 0.71 ----- 0.45 -----
> ----- ----- ----- ----- -----
> 10 ----- ----- 0.20 0.32 ----- 0.49 ----- 0.63 ----- 0.78 -----
> ----- ----- ----- ----- -----
> 15 0.33 ----- 0.18 0.26 0.40 0.60 0.67 0.54 ----- ----- -----
> 0.39 ----- ----- ----- -----
> 20 0.18 0.11 0.20 0.25 0.44 0.48 0.37 0.63 0.51 0.91 0.78
> 0.55 0.86 ----- ----- -----
> 25 0.12 0.06 0.18 0.29 0.67 0.46 0.52 0.51 ----- 0.68 0.82
> 0.82 0.99 ----- ----- -----
> 30 2.84 0.04 0.20 0.23 0.42 0.51 0.57 0.60 0.56 0.75 0.88
> ----- 1.06 1.01 ----- -----
> 35 ----- 0.08 0.20 0.19 ----- 0.45 0.28 0.41 ----- 0.78 0.79
> ----- 1.11 ----- 0.69 -----
> 40 ----- ----- 0.19 0.27 ----- 0.39 ----- 0.59 0.58 0.83 0.62
> ----- ----- ----- 1.07 0.37
>
> EFFICIENCY:
> kWh,Temp 0 1 2 3 4 5 6 7 8 9 10
> 11 13 14 16 17
> 0 ----- ----- 74.6 ----- ----- ----- ----- 103.9 ----- 91.5 -----
> ----- ----- ----- ----- -----
> 10 ----- ----- 78.1 81.9 ----- 90.4 ----- 80.8 ----- 97.2 -----
> ----- ----- ----- ----- -----
> 15 ----- ----- 70.3 78.7 81.5 95.4 ----- 90.0 ----- ----- -----
> 66.2 ----- ----- ----- -----
> 20 106.0 79.5 76.7 84.5 ----- 93.1 68.9 91.1 79.5 98.4 95.0
> 87.3 98.4 ----- ----- -----
> 25 0.0 37.5 71.1 86.2 ----- 87.2 72.9 90.4 ----- 80.3 89.2
> 74.5 90.4 ----- ----- -----
> 30 340.7 26.5 79.3 85.3 87.7 87.0 74.0 87.4 79.5 81.7 94.6
> ----- 96.4 89.3 ----- -----
> 35 ----- 50.4 68.6 69.6 ----- 87.2 71.5 84.1 ----- 89.5 85.0
> ----- 94.6 ----- 90.4 -----
> 40 ----- ----- 68.4 79.5 ----- 74.8 ----- 89.5 88.3 91.1 53.0
> ----- ----- ----- 96.0 86.7
>
> It produces three tables. The axes on all are the same - kW along the top, and
> battery temperature down the side. The idea is to extract the charge records
> and put them in the matching bucket based on the rounded-down kW for maximum
> charge wattage seen, and rounded-down 5Celcius for battery temperature at the
> start of the charge.
>
> The first table (NUMBER OF SAMPLES) just shows the number of charge records
> seen for each bucket.
>
> The second table (KM(IDEAL)/MINUTE) shows how many ideal kilometers were
> added, an average, for each bucket.
>
> The third table (EFFICIENCY) tries to calculate an efficiency by assuming a
> 53kWh battery (ESS) would be 100% SOC, and then looking at the change in SOC%
> over the charge to calculate how much was put into the battery (ESS), and
> comparing that to what the car says was taken from the wall (to the nearest
> kWh).
>
> The numbers are all over the place in some areas (e.g.; 30C, 0..1kW, where
> there are only 2 samples).
>
> The hypothesis is that charging efficiency depends primarily on
> battery/ambient temperature and kW available at the wall.
>
> If we can store such a small table in the OVMS module in the car, when OVMS
> needs to complete a charge by say 5am, it can plug in the current temperature
> and available current/voltage and get out a charging efficiency (perhaps how
> many minutes for each extra 1% of SOC). Then, knowing that it needs
> 100-currentSOC% to charge, it can work out how many minutes that would be, add
> on say 1/2 hour for safety, and start the charge at the appropriate time.
> Neat, and no server connection required.
>
> Thoughts? Anyone good at number crunching to play with this?
>
> Regards, Mark.
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
More information about the OvmsDev
mailing list