Vehicle firmware v2.5.5 has been pushed to github. It is tagged (as v2.5.5) and we have uploaded pre-built .hex files in the vehicle/firmware directory.
2013-11-28 2.5.5 Firmware 2.5.5 # Fix mode numnbers for display of range and performance charge modes # V1_TeslaRoadster config: include logging, but no room for ACC # TeslaRoadster: CTP prediction based on charge limit, not current current # ACC: Use car_chargesubstate!=0x07 instead of pilot signal # Add TEMPS SMS command for temperatures # ACC: Delay CTP calculations until acc charge mode is stable # ACC: Remove 30 minute safety margin for CHARGEBY # Config changes to optimise what is in each config 2013-10-11 2.5.4 Firmware 2.5.4 # Make MINSOC drive NET_NOTIFY_CHARGE (rather than NET_NOTIFY_STAT) # Input GPIO control for input RA2..RA5, and output RC0..RC3 # ThinkCity: Updates to Think City support # iMiev: Updates to Mitsubishi vehicle support # Think City: Added support for switching on/off external heater/auxilary via Valet Mode button # ACC: Aggressively stop charge if cooldown is done # ACC: If we are waiting for a charge, but the charge is started, then stop it # Range and SOC limits stop exactly ON the limit # Think City: car_parktime added # Fix for command handler with net_msg_cmd_msg # Tesla Roadster: fix for mins remain estimate if SOC limit but no RANGE limit # Use 0 ## Merge thinkcity changes: Think City AC-line voltage/current in SMS STAT SMS migrated from standard handler to vehicle_thinkcity.c ## 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 cycles ## Range and charge limits handled by ACC ## Basic ACC implementation, but without timed charges 2013-08-16 2.5.1 Firmware 2.5.1 ## Framework to build logging module in experimental modes ## FIsLatLongClose utiliy function (courtesy of Tom Saxton) ## Twizy: Mi/Km conversions updated to new functions ## Switch to use macros, for clarity and maintainability ## 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 changed ## Tesla Roadster: Notify server if charge mode is changed ## v2.5.1 protocol guide ## Add core support for cooldown ## Tesla Roadster support for cooldown ## Stub implementation, with basic functionality, for ACC ## Zero logging records on init, plus other safety checks ## 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 miles) ## Remove dr++ and cr++ sequence numbers, as not required ## 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:
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.
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 purposes.
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 should).
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 location.
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 current status off ACC with “ACC STAT”.
You can show the ACC details for the current location by sms "ACC PARAMS?" (or for a particular location by "ACC PARAMS? 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:
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 "ACC DISABLE" (or "ACC DISABLE n").
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, CHARGEAT, COOLDOWN, LIMIT, MODE, STOPRANGE and STOPSOC - hopefully those are ok now, but the control logic does need wider testing. The CHARGEBY option is still giving me random problems, related to the charge time estimated - I am still working on that. I've also been unable to test HOMELINK and would be very interested to see if that works.
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.