[Ovmsdev] Charge Control

Mark Webb-Johnson mark at webb-johnson.net
Thu Apr 5 19:45:17 HKT 2012

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120405/b67f3ad1/attachment.htm>

More information about the OvmsDev mailing list