[Ovmsdev] Charge Control

[Tom Saxton]

Mark - those sound like cool features.

When I log drives manually, I also record the trip meter energy use,
efficiency and drive time numbers. That lets me compare energy from the wall
to energy from the battery pack.

For charge logging, I log the energy use reported by the car and compare
that to the energy use reported by the wall meter so I can see how accurate
the car is.

I would be great to be able to charge to a lower SOC, since 180 miles of
range is just ridiculous for my daily driving. On the other hand, doing that
regularly might mess up brick balancing.

There's a bunch of info on charge rate here:

http://www.saxton.org/tom_saxton/2010/07/tesla-roadster-charging-rates.html

I collected that data in early 2010, just before the firmware update that
changed how the Roadster calculates battery capacity, which may have also
changed charging profiles. All of my data was taken in moderate
temperatures, so it needs to be augmented with data on how ambient
temperature affects charge rate.

Still, I've been using this data to calculate charge times and I do pretty
well, both at setting the charge start time to get a range mode charge to
end in a certain time window and also to know how long I should charge in
the middle of a road trip to maximize charge rate. (For example, if you're
at a 70A charging station and your next charge is a 40A outlet, it's a waste
of time to keep charging past the point where current tapering is below
40A.)

    Tom

on 4/5/12 4:45 AM, 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