The new CTP command gives users full access to the charge time predictor. Currently only the Roadster has the necessary charge time predictor code, but the CTP command is general so it will work for other vehicles that add the required algorithm.
There are a few ways to call it:
- If the car is charging, just send CTP to get the current estimate (1-minute resolution) and the charge target.
- If the car isn't charging, you have to tell is the power level to use, either in watts or volts and amps, e.g. "CTP 9600W" or "CTP 240V 40A".
- You can also specify the charge mode (S, R, P), start, stop and CAC values. For example, "CTP 9600w 100s 150e 152c 25d" says "use 152 as the CAC value, then calculate the time needed to go from 100 ideal miles to 150 ideal miles charging at 9.6 kW in a 25C environment." You can also specify the end percent target as: "CTP 9600w 90%".
For example, send:
CTP R 240v 40a 100s 152c 25d
receive:
100 to 232 ideal miles
4:53
Which means charging in Range mode from 100 ideal miles to full (calculated to be 232 ideal miles for a Roadster with a CAC of 152 Ah) at 240V/40A is estimated to take 4 hours and 53 minutes.
Many factors can influence the actual charge time, so don't expect to-the-minute accuracy, more like plus or minus the larger of 30 minutes and 10%.
Next up is teaching it to convert to and from km.
I'm interested in implementing the Leaf charge time predictor once we start getting some Leaf charge data. I'm also happy to help with other vehicles.
Tom
Quite a few updates have just been pushed, and may have broken things, but so far seem ok to me.
Tom’s changes are:
- add params to vehicle_minutestocharge
- add #define for charge voltage assumed by ACC
- add CTP SMS command
- add timestamp to STAT SMS command
- generalize timestring_to_mins
- TR: CTP uses CAC100 for better resolution
- TR: move MinutesToChargeCAC code into vehicle_teslaroadster_minutestocharge
- TR: separate taper profiles for each charge mode
My changes are:
- Add new polling framework to vehicle.{h,c}
- Use new polling framework to implement vehicle_obdII
- Extend polling framework for extended (mode 0x22) pid requests
- Extend polling framework for Nissan Leaf style multi-frame requests
- Change crypt_md5 to try to reduce ram usage (particular initialised ram)
I’ve also extended CAN-RE-TOOL to build a simulation framework, to help test the above and to act as a framework for future work.
I haven’t changed the VoltAmpera to use the new framework yet.
Now, the framework is stable, I can finalise the Nissan leaf polling code.
Regards, Mark.