[Ovmsdev] OvmsDev Digest, Vol 17, Issue 7
Bennett Leeds
bennettleeds at gmail.com
Sun Jun 2 23:30:37 HKT 2013
I would say to keep things simpler that if you're doing a standard charge,
always optimize for cost (since a full standard charge isn't bad for the
battery at all), but if the car is set for Range Charge, then do the
"finish by" thing.
My (Nor Cal PGE) TOU periods are:
Summer M-F Summer Weekends Summer Rates
Peak: 2pm-9pm None $0.30-$0.54/kWh
Part-Peak: 7am-2pm & 9pm-mid 5pm-9pm $0.09-$0.34/kWh
Off-Peak: mid-7am 9pm-mid & mid-5pm $0.04-$0.28/kWh
Winter M-F Winter Weekends Winter Rates
Peak: None None None
Part-Peak: 7am-mid 5pm-9pm $0.09-$0.34/kWh
Off-Peak: mid-7am 9pm-mid & mid-5pm $0.04-$0.30/kWh
The new Nor Cal PGE TOU periods get rid of summer/winter time differences
and will be:
M-F Weekends Rates
Peak: 2pm-9pm 3pm-7pm summer:$0.36
winter:$0.27
Part-Peak: 7am-2pm & 9pm-11pm None summer:$0.20
winter:$0.16
Off-Peak: 11pm-mid & mid-7am 7pm-mid & mid-3pm summer:$0.10
winter:$0.10
I'm attaching PGE's letter on TOU periods.
Note that we could just leave the off-peak entries off, since even PGE says
"Off-peak is all other times." Just enter peak and part-peak and whatever's
left is off-peak.
Probably the cases I'm worried about are edge cases, where the charging
amperage is so low that it won't get to full at the next upcoming off-peak
period, and so don't really matter. Since the Off-Peaks are always followed
by a Part-Peak, there would be no reason not to wait until the Off-Peak to
start any charging, since any time overflow would be in the next lowest
tier anyway.
For Range charging on trips, I would suggest that if charging time permits,
it would be better to do a cost-optimized Standard charge, followed by a
time-optimized Range charge. That's what I do manually today - charge
Standard overnight and then when I wake up the next morning, switch to
Range and charge again. By the time I'm showered, fed, and packed, the car
is Range charge full.
As long as you can calculate the time from Standard Full to Range Full you
can work out when to start the Range to be Range full in time. I also
suggest this saves energy, as there's less aggressive battery cooling in
standard charge. Of course, some people might be battery coolness freaks
and want to range charge all the time but with stopping the charge early
(eg, at the same SOC as a standard full). That would keep the battery from
getting too full while keeping the battery very cool. However, I think
there are issues with performance and even battery life trying to pull a
lot of power out of a too-cool battery. Range Mode charge leaves you in
Range mode driving, which reduces power. I think that's not only to help
your charge go faster, but to reduce the strain on a too-cool battery.
- Bennett
On Sun, Jun 2, 2013 at 6:05 AM, <ovmsdev-request at lists.teslaclub.hk> wrote:
> Send OvmsDev mailing list submissions to
> ovmsdev at lists.teslaclub.hk
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> or, via email, send a message with subject or body 'help' to
> ovmsdev-request at lists.teslaclub.hk
>
> You can reach the person managing the list at
> ovmsdev-owner at lists.teslaclub.hk
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OvmsDev digest..."
>
>
> Today's Topics:
>
> 1. Re: Advanced Charge Control (ACC) (Mark Webb-Johnson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 2 Jun 2013 21:05:12 +0800
> From: Mark Webb-Johnson <mark at webb-johnson.net>
> Subject: Re: [Ovmsdev] Advanced Charge Control (ACC)
> To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
> Message-ID: <943A7C26-8D84-4086-9FEF-37DB7B42233B at webb-johnson.net>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Bennett,
>
> I'm a little confused on why we need this.
>
> Say you have three TOU rates:
> (a) 6am->6pm the most expensive
> (b) 6pm->2am the middle rate
> (c) 2am-6am the cheapest
>
> Now, you leave for work at 8am.
>
> Assume a charge requires 5 hours to complete.
>
> You could put in 8am as the departure time, in which case you would get 3
> hours in rate (c) and 2 hours in rate (a).
>
> Or you could just put in the end of the most cheap rate, in which case the
> charge would be 1 hour in rate (b) and 4 hours in rate (c).
>
> Surely when you are doing a complete-charge-by-time style of charge, you
> could either put in the time you leave (to optimise for battery lifetime)
> or the end of the cheap rate band (to reduce charge cost)?
>
> My concern is because of (a) complicating the setup and configuration (in
> particular where user has to choose been optimising his battery lifetime or
> electricity bill), and (b) complicating the code (eeprom, ram and flash
> storage are very very tight).
>
> Could you provide some examples for your electricity provider? What are
> the current rate bands, and what time are they for weekdays and weekends?
>
> Regards, Mark.
>
> On 2 Jun, 2013, at 12:22 PM, Bennett Leeds <bennettleeds at gmail.com> wrote:
>
> > This is really exciting. I would request that the Charge Timer should be
> based on Time Of Use periods, in order to automatically have the lowest
> charging costs while still having a full vehicle when you need it.
> >
> > Here in the states, many EV owners are on time of use meters. The
> cheapest period times very not only by day of the week, but also by season.
> I'd like to be able "teach" the car what the TOU periods are, tell it what
> time I leave each morning, and then have the car figure out the cheapest
> way to get me a full charge by the time I need it given the upcoming TOU
> periods between plug-in and when I need to leave.
> >
> > The TOU periods could be specified in 3 levels per weekday and 3 levels
> per weekend. With 2 seasons, that would be 12 fields to be entered. Time
> Needed could be specified per weekday and per weekend - so 14 time fields
> total for this to work.
> >
> > The logic is pretty straightforward. When the car is off and plugged in,
> look to see when the full charge is needed by. Either know the amperage
> available, or use the cooldown to get a pilot signal. Obey any lower
> current limits set by owners (which might be done due to old breakers,
> etc.). Then figure out if the cheapest time period is long enough to fully
> charge the car. If not, then do just enough charging in the second cheapest
> time period to result is a full charge, and if that won't be enough, then
> do just enough charging in the most expensive time period to result in a
> full charge after the upcoming second cheapest and most cheapest periods.
> >
> > I'd be happy to be a tester for whatever you come up with.
> >
> > thanks
> > - Bennett
> >
> >
> >
> >
> >
> > On Sat, Jun 1, 2013 at 9:00 PM, <ovmsdev-request at lists.teslaclub.hk>
> wrote:
> > Send OvmsDev mailing list submissions to
> > ovmsdev at lists.teslaclub.hk
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> > or, via email, send a message with subject or body 'help' to
> > ovmsdev-request at lists.teslaclub.hk
> >
> > You can reach the person managing the list at
> > ovmsdev-owner at lists.teslaclub.hk
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of OvmsDev digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: Advanced Charge Control (ACC) (Tom Saxton)
> > 2. Re: Advanced Charge Control (ACC) (Mark Webb-Johnson)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Sat, 01 Jun 2013 12:02:41 -0700
> > From: Tom Saxton <tom at idleloop.com>
> > Subject: Re: [Ovmsdev] Advanced Charge Control (ACC)
> > To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
> > Message-ID: <CDCF9361.804A3%tom at idleloop.com>
> > Content-Type: text/plain; charset="US-ASCII"
> >
> > Mark,
> >
> > This all sounds great. It covers everything I want, and more.
> Personally, I
> > think three zones is plenty if you want to save some parameter space.
> >
> > Tom
> >
> > on 5/31/13 6:56 AM, Mark Webb-Johnson wrote:
> >
> > > I've spent some time planning this, and now have the time to try to
> get it
> > > done. The observant will have noticed a new branch ACC just appeared
> in the
> > > github repository.
> > >
> > > This is primarily for Tesla Roadster owners, but once we work out how
> to do
> > > charge control in other cars, it will have use for them.
> > >
> > > The premise of what I'm thinking is a replacement for the limited
> charge
> > > control in the car, to make an Advanced Charge Control:
> > >
> > > We have the concept of a 'charge location'. This is an area (square,
> because
> > > it is easiest) around a GPS location. An area of 200m x 200m, centred
> on the
> > > charge location, should be sufficient for gps inaccuracies. Up to 5
> such
> > > charge locations can be defined (I'm thinking home, work, and one
> other).
> > > Once the car enters a charge location, an action can be triggered. At
> the
> > > moment, I'm only thinking of automatic home link activation, but
> others are
> > > possible.
> > > When a car is turned off, while in a charge location, acc is enabled
> and
> > > current charge settings are saved.
> > > When a car is turned on, while in a charge location, acc is disabled
> and
> > > previous charge settings are restored.
> > > Features that acc should support include:
> > > Homelink activation.
> > > Cooldown (cool the car using a sequence of low amperage range mode
> charges) -
> > > this would need a minimum temperature (don't cool down unless ESS
> temperature
> > > is above this), a desired temperature (cool down until the ESS reaches
> this
> > > temperature),and a time limit (stop cooling down if we've been trying
> for too
> > > long).
> > > Charge mode (standard, storage, range, performance).
> > > Charge current limit.
> > > Various charge types, including:
> > > Charge on plug-in
> > > Start charge at specific time
> > > Complete charge by specific time
> > > Desired charge limit (SOC%, ideal miles/kilometers, or full)
> > > In addition to the charge locations, acc should be able to be turned
> on,
> > > one-off, for the current location. This should be done after the car
> is turned
> > > off, before plugging in. It will be effective until the car is turned
> on
> > > again.
> > > It should also be possible to use this one-off acc to override the
> charge
> > > control for the current location. This will be effective until the car
> is
> > > turned on again.
> > > Control, and status, is possible by SMS commands.
> > > Control is also possible by a new tab added to the apps. I'm going to
> do
> > > iPhone first, with the existing charge control moved to a new "Charge"
> tab.
> > >
> > > I'm not sure how to do the 'specific time'. This could be
> > > simple-to-ludicrously-complex. My inclination is to just put a
> day-of-week
> > > filter on each charge location - with acc only being enabled if the day
> > > matches. More than one location could be created for each physical gps
> > > location, with different day matches, to control how that would behave.
> > >
> > > Changes to be made include:
> > >
> > > Move the roadster digital speedo experimental feature to a fully
> supported
> > > features, and give it a permanent feature storage number.
> > > Assign five new permanent parameters, one each for five charge
> locations
> > > (home, work, other, or whatever they want to be known as - we just
> call them
> > > #1, #2, #3, #4 and #5).
> > > The parameter storage for these new locations includes the charging
> > > preferences for each location.
> > > We would also need a parameter for time zone.
> > > Add a new module called "acc".
> > > If "acc" detects we are at a known charge location, it will take over
> the
> > > charge control from the car.
> > > The "acc" will also support commands for the current location, and
> will be
> > > able to take over charge control from now until the car is next driven.
> > >
> > > Please let me have your comments / suggestions. I'll handle the
> coding, but
> > > I'll need lots of help testing.
> > >
> > > Regards, Mark.
> > >
> > > _______________________________________________
> > > OvmsDev mailing list
> > > OvmsDev at lists.teslaclub.hk
> > > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Sun, 2 Jun 2013 09:29:37 +0800
> > From: Mark Webb-Johnson <mark at webb-johnson.net>
> > Subject: Re: [Ovmsdev] Advanced Charge Control (ACC)
> > To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
> > Message-ID: <AF3A64D7-E806-4CF3-94A8-360D170626C4 at webb-johnson.net>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Tom,
> >
> > My original design was 3 (home, work, other). I increased to 5 to allow
> for different schedules weekday / weekend, etc.
> >
> > Lets see how it works out. More would be good.
> >
> > Regards, Mark
> >
> > On 2 Jun, 2013, at 3:02 AM, Tom Saxton <tom at idleloop.com> wrote:
> >
> > > Mark,
> > >
> > > This all sounds great. It covers everything I want, and more.
> Personally, I
> > > think three zones is plenty if you want to save some parameter space.
> > >
> > > Tom
> > >
> > > on 5/31/13 6:56 AM, Mark Webb-Johnson wrote:
> > >
> > >> I've spent some time planning this, and now have the time to try to
> get it
> > >> done. The observant will have noticed a new branch ACC just appeared
> in the
> > >> github repository.
> > >>
> > >> This is primarily for Tesla Roadster owners, but once we work out how
> to do
> > >> charge control in other cars, it will have use for them.
> > >>
> > >> The premise of what I'm thinking is a replacement for the limited
> charge
> > >> control in the car, to make an Advanced Charge Control:
> > >>
> > >> We have the concept of a 'charge location'. This is an area (square,
> because
> > >> it is easiest) around a GPS location. An area of 200m x 200m, centred
> on the
> > >> charge location, should be sufficient for gps inaccuracies. Up to 5
> such
> > >> charge locations can be defined (I'm thinking home, work, and one
> other).
> > >> Once the car enters a charge location, an action can be triggered. At
> the
> > >> moment, I'm only thinking of automatic home link activation, but
> others are
> > >> possible.
> > >> When a car is turned off, while in a charge location, acc is enabled
> and
> > >> current charge settings are saved.
> > >> When a car is turned on, while in a charge location, acc is disabled
> and
> > >> previous charge settings are restored.
> > >> Features that acc should support include:
> > >> Homelink activation.
> > >> Cooldown (cool the car using a sequence of low amperage range mode
> charges) -
> > >> this would need a minimum temperature (don't cool down unless ESS
> temperature
> > >> is above this), a desired temperature (cool down until the ESS
> reaches this
> > >> temperature),and a time limit (stop cooling down if we've been trying
> for too
> > >> long).
> > >> Charge mode (standard, storage, range, performance).
> > >> Charge current limit.
> > >> Various charge types, including:
> > >> Charge on plug-in
> > >> Start charge at specific time
> > >> Complete charge by specific time
> > >> Desired charge limit (SOC%, ideal miles/kilometers, or full)
> > >> In addition to the charge locations, acc should be able to be turned
> on,
> > >> one-off, for the current location. This should be done after the car
> is turned
> > >> off, before plugging in. It will be effective until the car is turned
> on
> > >> again.
> > >> It should also be possible to use this one-off acc to override the
> charge
> > >> control for the current location. This will be effective until the
> car is
> > >> turned on again.
> > >> Control, and status, is possible by SMS commands.
> > >> Control is also possible by a new tab added to the apps. I'm going to
> do
> > >> iPhone first, with the existing charge control moved to a new
> "Charge" tab.
> > >>
> > >> I'm not sure how to do the 'specific time'. This could be
> > >> simple-to-ludicrously-complex. My inclination is to just put a
> day-of-week
> > >> filter on each charge location - with acc only being enabled if the
> day
> > >> matches. More than one location could be created for each physical gps
> > >> location, with different day matches, to control how that would
> behave.
> > >>
> > >> Changes to be made include:
> > >>
> > >> Move the roadster digital speedo experimental feature to a fully
> supported
> > >> features, and give it a permanent feature storage number.
> > >> Assign five new permanent parameters, one each for five charge
> locations
> > >> (home, work, other, or whatever they want to be known as - we just
> call them
> > >> #1, #2, #3, #4 and #5).
> > >> The parameter storage for these new locations includes the charging
> > >> preferences for each location.
> > >> We would also need a parameter for time zone.
> > >> Add a new module called "acc".
> > >> If "acc" detects we are at a known charge location, it will take over
> the
> > >> charge control from the car.
> > >> The "acc" will also support commands for the current location, and
> will be
> > >> able to take over charge control from now until the car is next
> driven.
> > >>
> > >> Please let me have your comments / suggestions. I'll handle the
> coding, but
> > >> I'll need lots of help testing.
> > >>
> > >> Regards, 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
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.teslaclub.hk
> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> >
> >
> > End of OvmsDev Digest, Vol 17, Issue 5
> > **************************************
> >
> > _______________________________________________
> > 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/20130602/887d633b/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
> End of OvmsDev Digest, Vol 17, Issue 7
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130602/275ee1a9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: E-4508 Final Resolution (PG&E AL3910-E,3910-E-A).pdf
Type: application/pdf
Size: 596941 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130602/275ee1a9/attachment-0002.pdf>
More information about the OvmsDev
mailing list