[Ovmsdev] CTP: Charge Time Predictor or Chocolate Tea Pot?

[Mark Webb-Johnson]

Michael,

I like the idea of the two numbers. Makes sense for the roadster as well. I'll add the protocol support (and documents) this weekend.

The bigger picture here is sophisticated charge control (including setting things like desired end SOC%/IdealMiles). I'll be working on creating a draft specification for this over the weekend.

For the Tesla Roadster, I've seen requests for:

Cool down - when the car arrives at a specific location do a series of low-power range mode charges until battery temperature falls below a specified level.
More sophisticated TOU charging.
Complete-charging-by-time TOU charges (where car starts charging early enough to complete by a preset time).
Top-off - top of the charge just before I leave.
Freeloader - temporarily change to range mode for the duration of this one charge, then switch back to whatever mode we were in before when charge completes/stops  (to make the most of free electrons).
Charge limit SOC% or Ideal Miles - only charge to the specified limit.
others...

I suspect that these are all variants (and there could be many more) of a parametric-based system that we could implement relatively easily. We don't need to know all the variants - just follow some simple instructions.

P.S. I realise the Twizy can't stop/start the charge (yet - Nikki), but it can notify when these events happen (as you seem to be doing already).

Regards, Mark.

On 17 Apr, 2013, at 9:27 PM, Michael Balzer wrote:

> Mark, Tom,
> 
> nice to see you're including this now in the standard.
> 
> Please reserve two time values (vars and fields for the protocol) to also cover my charge time prediction for the Twizy.
> 
> I've got two times on the Twizy because I calculate the estimation for both a desired SOC (set by the user via the "CA" command) and for 100%.
> 
> I think this should be OK for all vehicles, as many drivers do partial charges intentionally. If a desired SOC cannot yet be set, the estimation could use 80% as a default, as this is normally the end SOC for fast charging.
> 
> The protocol should also include the desired SOC in percent so the App does not need to query other data to interpret the value.
> 
> Regards,
> Michael
> 
> 
> Am 17.04.2013 13:31, schrieb Mark Webb-Johnson:
>> 
>> Tom's CTP algorithm is in my Tesla Roadster, and I've just started the first charge with it:
>> 
>> 2013-04-17 06:59:39.975150 -0400 info  main: #71 C EV915 rx msg S 79,K,3,0,prepare,standard,246,222,56,0,100,0,7,13,0,0,0,-1,156.78,-1
>> 2013-04-17 07:04:32.207360 -0400 info  main: #71 C EV915 rx msg S 79,K,220,0,charging,standard,246,222,56,0,100,0,5,1,0,0,0,-1,156.78,-1
>> 2013-04-17 07:04:32.208899 -0400 info  main: #71 C EV915 rx msg S 79,K,220,0,charging,standard,248,224,56,0,100,0,5,1,0,0,0,-1,156.78,-1
>> 2013-04-17 07:09:10.003015 -0400 info  main: #71 C EV915 rx msg S 82,K,218,56,charging,standard,258,232,56,9,100,2,5,1,0,0,0,-1,156.78,38
>> 2013-04-17 07:19:08.396430 -0400 info  main: #71 C EV915 rx msg S 86,K,218,56,charging,standard,269,243,56,19,100,4,5,1,0,0,0,-1,156.78,27
>> 
>> Prediction is the last column: 38 minutes given 56 amps @ 220 volts, 24 - 27 celcius ambient, with about 80km (50 miles) to put into the pack.
>> 
>> Exciting times ahead, with alternative charge control mechanisms.
>> 
>> Regards, Mark.
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> -- 
> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
> <dexter.vcf>_______________________________________________
> 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.openvehicles.com/pipermail/ovmsdev/attachments/20130419/eda0cafa/attachment.htm>