[Ovmsdev] Charge Control

Mark Webb-Johnson mark at webb-johnson.net
Thu Apr 5 21:05:31 HKT 2012


David,

I think the balance would be ok if we do all the UI and calculations in the App. Then have the server as a data repository (while capability to get a query like 'I need to charge at 29celcius range mode SOC from 30% to 80% at 220v up to 70amp' and get back an approximate charge duration (based on similar charges the server has sen). The car firmware would just have a lookup table to follow and would issue the appropriate commands at the appropriate times.

I kind of like the idea that when the car sees park in its defined location, it sends the commands to the VDS to arrange charging. For example, say it needs 3 hours and you scheduled to leave by 7am, when you plug in the VDS will say 'Charging at 4:00am'. That said, I'm not sure if we can do it that way, but it seems the neatest.

This can always be overridden in the car by hitting the "Charge Now" button on the VDS.

That said, the firmware should have fallback arrangements. It can also try to alert if it can't do what it is told (for example, the car is not plugged in, but it is in a location where it should be).

Regards, Mark.

On 5 Apr, 2012, at 7:56 PM, David Morse wrote:

> Great idea.  I'm just an end user but
> 
> for #7: Could you have a backup setting that if the car is plugged in and if the charge is less than a set % SOC, but there is no signal, that it defaults to a standard user defined charge time?
> 
> Dave
> 
> On Apr 5, 2012, at 6: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
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20120405/3b8108ad/attachment.html>


More information about the OvmsDev mailing list