[Ovmsdev] v2.5.3 Call for Testing

911carrera4 911carrera4 at bluewin.ch
Wed Sep 25 04:43:51 HKT 2013

Sorry Mark


I found  and read your "notes on cool down on TR" an now I understand .J


Sorry & Greets, Piotr



Von: ovmsdev-bounces at lists.teslaclub.hk
[mailto:ovmsdev-bounces at lists.teslaclub.hk] Im Auftrag von 911carrera4
Gesendet: Dienstag, 24. September 2013 22:32
An: 'OVMS Developers'
Betreff: Re: [Ovmsdev] v2.5.3 Call for Testing


Hi Mark


Just flashed my OVMS v2 with the new  2.5.3 firmware. And. Something strange

After connecting the OWMS box I set the feature 13 to 255 and speedo to 5.

The car was already in the mode "charging" then (standard 10 A)

After connecting the box it swifted to "performance", than to "range" by

I tried to change the mode via App. That went well, but after 5 secs it
changed to performance again, than range. 

I tried several times, I also reset the box, but the problem wasn't to

Now I'm back to version 2.3.2.

Any idea what happened?





Von: ovmsdev-bounces at lists.teslaclub.hk
[mailto:ovmsdev-bounces at lists.teslaclub.hk] Im Auftrag von Mark Webb-Johnson
Gesendet: Mittwoch, 18. September 2013 15:39
An: OVMS Developers
Betreff: [Ovmsdev] v2.5.3 Call for Testing



OK. I've just committed v2.5.3 and pushed to github. I've also tagged it (as
v2.5.3) and upload pre-built .hex files in the vehicle/firmware directory.


Short story: v2.5.3 is unlikely to blow up your car, but has probably got
lots of bugs, and I need your help testing to find those bugs and fix them.


Big caveat: this is testing code, please don't use ACC if you _really_ need
that charge to get to work / school / the beach / wherever. Don't blame me
if your car doesn't start the charge as scheduled.


Warning: this is a long mail.


Firstly, the v2.5.x change log:


2013-09-18 2.5.3       Firmware 2.5.3

                       ## Updates to thinkcity

                       ## Remove DIAG and add ACC to V1_Production build

                       ## Remove InternalGPS from V2_TR_Production build
config, as not required

                       ## Cooldown: safety check (only recycle if charging),
and revise cooldown current to 13A

                       ## Support definition of location in SMS commands

                       ## Tesla Roadster: HVAC#1 should be 0x8F not 0x87

                       ## Logging: Don't reserve a log slot if the
respective logging option is disabled

                       ## Improve cooldown status reporting on SMS STAT

                       ## Tidy-up of minSOC

                       ## Move chargelimit charge stop to common vehicle.c
function (not acc)

                       ## Tesla Roadster: Updates to Tom's
charge-time-predictor, with thanks

                       ## Log cooldown charges as mode=5, and fix
excessive-logging-bug related to cooldown cycles

                       ## Logging: Send log messages one-by-one, to avoid
buffer overflows

                       ## ACC: Number homelinks from 1..3

                       ## Tesla Roadster: support for chargelimits

                       ## Make SMS "RESET" reset the module completely

                       ## Complete rework and expansion of checkpoint

                       ## Stop charge after cooldown, if no subsequent
charge requested

                       ## Report CAC as part of charge log record

                       ## Typos in acc for net_state_enter

                       ## Show debug checkpoint, for DIAG SMS with

                       ## Support vehicle_fn_minutestocharge

                       ## Add a timezone parameter (-)HH:MM

                       ## ACC: Support timed charges

                       ## Move car_cooldown_wascharging to global, and make
use of it in ACC

                       ## Introduce some delays to allow car to wake up


2013-08-27 2.5.2       Firmware 2.5.2

                       ## Updates to vehicle_thinkcity.c (getting to a
pretty usable vehicle module)

                       ## Make car_tbattery signed integer, and integrate
thinkcity changes

                       ## Only report range and soc limits if >0

                       ## Merge thinkcity changes:   Think City AC-line
voltage/current in SMS STAT   SMS migrated from standard handler to

                       ## Tesla Roadster: Don't stop charge after cooldown,
if previously the car was already charging

                       ## Log cooldown charges that become normal charges as
two separate charges

                       ## Tidy up diag, by removing temp test code T1 T2 T3

                       ## Create individual configs for TeslaRoadster and
RenaultTwizy (to allow all features for these cars)

                       ## Add TRACK (type XX) vehicle that just tracks GPS

                       ## string_to_mode utility function

                       ## Rework vehicle inclusions. Tesla Roadster, Renault
Twizy and Volt/Ampera are production. Everything else is experimental

                       ## Add experimental vehicle Kyburz DXP

                       ## Add HVAC message details

                       ## Support HVAC bit in car_doors5, and cooldown

                       ## Range and charge limits handled by ACC

                       ## Basic ACC implementation, but without timed


2013-08-16 2.5.1       Firmware 2.5.1

                       ## Framework to build logging module in experimental

                       ## FIsLatLongClose utiliy function (courtesy of Tom

                       ## Twizy: Mi/Km conversions updated to new functions

                       ## Switch to use macros, for clarity and

                       ## ACC integration to build environment

                       ## Parameter support for base64 encoded parameters

                       ## utils support for mode display

                       ## ACC support for net_sms

                       ## Switch logging system to use new "h" historical
data submission, with acknowledgement

                       ## Go from 4->6 log records, based on free space

                       ## Tesla Roadster: Notify server if charge limit is

                       ## Tesla Roadster: Notify server if charge mode is

                       ## v2.5.1 protocol guide

                       ## Add core support for cooldown

                       ## Tesla Roadster support for cooldown

                       ## Stub implementation, with basic functionality, for

                       ## Zero logging records on init, plus other safety

                       ## Only initialise logging on a normal power up

                       ## Standardise 3 diag tests: T1, T2 and T3

                       ## Only send logging msgs if link is connected

                       ## Fix logging prefix and some logging tests

                       ## Revisions to CAR_IS_CHARGING logic

                       ## Misc bug-fixes for logging

                       ## Report distance in miles (rather than 10ths of

                       ## Remove dr++ and cr++ sequence numbers, as not

                       ## Make ACC commands case insensitive

                       ## Fix bug acknowledging log record #0

                       ## Move digital speedo feature (Tesla Roadster) from
experimental to fully supported, and implement opt-in feature bits

                       ## Honour opt-in flags for logging

                       ## Only report debug crash reason if not normal power
up, and only report once


As you can see, a lot has changed. The key points are:


*	Some restructuring of the build targets:

*	V1_production.hex               V1 Hardware Module, production

*	V2_experimental.hex             V2 Hardware Module, experimental
*	V2_production.hex               V2 Hardware Module, production
*	V2_RT_production.hex            V2 Hardware Module, Renault Twizy
full firmware
*	V2_TR_production.hex            V2 Hardware Module, Tesla Roadster
full firmware

*	Support for LOGGING (charge and drive)
*	Support for ACC (Advanced Charge Control) - Tesla Roadster only at
the moment
*	Lots of other little nice fixes and enhancements


Apart from overall reliability testing (making sure it is stable in the
cars), the two things I need help with are the LOGGING and ACC functions.


[1] Logging


The logging code is enabled by setting opt-in feature (#13) bit 1 (to log
drives) and/or bit 2 (to log charges). Or, you can just set feature #13 to
255 and opt-in to everything :-)


Once you've opted in, whenever you complete a charge or drive, the car will
submit a summary record to be stored on the server. You can then use the
prototype HTTP API, or perl client, to retrieve those records for your own


Note that there is a privacy concern here, as both record types (drive and
charge) store GPS locations - this is the reason why it is opt-in.


The testing I need done is just to ensure that this works for you, and that
the resulting logged drives/charges match what you are expecting. It would
also be useful to confirm if this works on all supported cars (which it


[2] Advanced Charge Control


The Advanced Charge Control system is designed to supplement the (aka take
over from) vehicle's own charge scheduling. It should support any vehicle
with charge control, but at the moment that means only Tesla Roadster. It
has some pretty sophisticated features. For the moment, it is setup via SMS,
but in future we will allow smartphone Apps to do this. Once setup, it runs
autonomously, and doesn't even require a cellular connection.


ACC works from the concept of a 'charge location'. This is a geofenced
location that is used for charging, and you can configure up to 4 of these
(numbered #1 through #4). To define the car's current location as a 'charge
location', sms "ACC HERE" to the car, and it will allocate a free slot and
reply to you with it. You can use "ACC NOTHERE" to clear the current


If you want to clear a particular ACC location, you can sms "ACC CLEAR n"
(to clear one location), or "ACC CLEAR" (to clear all locations).


You can show the ACC details for the current location by sms "ACC STAT" (or
for a particular location by "ACC STAT n" - which is very useful if you have
crappy cellular connectivity like I do).


The ACC parameters for a particular location are configured with the "ACC
PARAMS" SMS. You can list a location number (1, 2, 3 or 4) as the first
parameter - or don't specify location if you just want to configure the
current location the car is at. After 'ACC PARAMS", you can set the
parameters you would like, from the following:


*	COOLDOWN - perform a cooldown charge (13A range mode, with cooling
cycles) when the car is plugged in at this ACC location
*	NOCOOLDOWN - don't do a cooldown charge (default)
*	HOMELINK n - activate homelink when the vehicle drives to within
100m of an ACC location (the idea is to open our garage door / gate
automatically as you approach)
*	NOHOMELINK - don't activate homelink (default)
*	CHARGEPLUGIN - charge the car on plugin (but after cooldown, if
*	CHARGEAT HH:MM - schedule charge to start at the specified time
(hours:minutes, 24hour clock)
*	CHARGEBY HH:MM - schedule charge to complete by the specified time
(hours:minutes 24hour clock)
*	NOCHARGE - don't charge (default)
*	LIMIT n - limit charge current to n Amps - must be specified for all
CHARGE* actions
*	MODE m - set charge mode (where "m" is STA(NDARD), STO(RAGE),
RAN(GE) or PER(FORMANCE)) - must be specified for all CHARGE* actions
*	STOPRANGE r - stop charge when range "r" is reached (specified in
vehicle units, set to 0 (default) to not limit).
*	STOPSOC s - stop charge when SOC "s" is reached (specified as a
percentage, set to 0 (default) to not limit).


The actions to take at a particular ACC location must be enabled with "ACC
ENABLE" (or "ACC ENABLE n") before they will work. You can also disable with


If you are using CHARGEAT or CHARGEBY, you need to specify the timezone of
the vehicle. This is parameter #23 and is specified as HH:MM offset from GmT
(with an optional leading "-" if west of Greenwich).


The default temperature limit for cooldown is 31Celcius, and time limit is
60 minutes. If you want to change these, you can set parameter #15 to
templimit:timelimit (e.g.; "31:60").


Note that you can also cooldown manually, while charging, with the SMS
command "COOLDOWN", and see the status with SMS "STAT".


I've spent quite some time testing CHARGEPLUGIN, COOLDOWN, LIMIT, MODE,
STOPRANGE and STOPSOC - hopefully those are ok now, but the control logic
does need wider testing. I've spent almost no time testing CHARGEAT and
CHARGEBY. I've also been unable to test HOMELINK and would be very
interested to see if that works.


Some notes on cooldown on Tesla Roadster


The cooldown algorithm is to start a range mode charge at 13Amps, and to
monitor the HVAC system of the car. Once the HVAC starts, runs for some
time, then stops, we call it a 'cooling cycle'. We keep a record of how many
such cycles have occurred.


Once we detect that the HVAC has stopped, we try to start it again. The
logic at the moment is to switch to performance mode for ten seconds, then
back to range mode, once every minute until the HVAC starts again. The
_best_ way of starting the HVAC is to stop and start the charge, but that is
painful on the contactors, so we don't do it. Switching
Range->Performance->Range seems to be the second best, but I remain
unconvinced that it makes much difference. In Hong Kong summer weather, I
get one cooldown cycle every ten minutes or so. I can drop 6 to 8 celcius in
one hour.


The cooldown will stop after either the desired temperature is hit (based on
the temperature of the hottest brick in the battery) or the cooldown has
been ongoing for the time limit.




I'm happy that the code is reasonably stable now, but really need help
testing this in a larger number of cars. If you do see a problem, please get
me (by eMail to OVMS developers mailing list, or my personal address):


*	Output of "SMS STAT" for the specified location
*	Your vehicle id
*	Output of base64 parameter string (from the cellphone app) -
*	Date/Time you entered the ACC location (with timezone)
*	Date/Time you plugged in at the ACC location (with timezone)
*	In the smartphone app, call up the Features and Parameters screens
(so the server logs those, and I can check)
*	Description of the problem you have


Please also share success stories. It is good to know what works.


Regards, Mark.


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

More information about the OvmsDev mailing list