I have continued to see garbage on occasion in the slot for parameter 15.  I never use cool down so assume it is because of ACC.  I think it might have something to do with trying to set an ACC location when you are not there.  I have not been able to reproduce the problem reliably and at the moment my car is in need of repairs so I am unable to test.  This from version 2.6.5 so the trouble might not be because of the update.

Jack


On Dec 7, 2014, at 4:29 PM, Tom Saxton <tom@idleloop.com> wrote:

Hi Mark,

I upgraded to 2.6.7/TR/V2 and the car started charging immediately, Range mode at 13A, so a cool down. The car was cool, battery temp at 60F, 16C.

I sent a STAT message and got this reply:

12:42:00

 Cooldown: 16C/0C (0cycles, 53mins remain)Standard - Charging Stopped

 SOC: 96%

 Ideal Range: 179 mi

 Est. Range: 160 mi

 ODO: 42,935.8 mi

 CAC: 149.86


It looks like it's trying to cool the pack down to 0C.


So, I looked at the parameters via the iOS app and found what looks like an off-by-one bug on the parameters. I see "#15 Cooldown" and "#16: ACC #1" are both long strings of encoded text. I expected to see Cooldown at 27. I definitely have one ACC location, maybe two.


Also, it looks like there should be a line break before "Standard - Charging Stopped".


   Tom


On 10/20/14, 6:58 AM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:


Its been a while, and quite a bit has changed, so time for a new firmware.

Changes:

  • Twizy updates
  • Think city updates
  • TR VECE updates
  • Fix issue #135 (SMS response messed up for GPRS?, etc)
  • Fix for net_msg handling of SMS LOCK, UNLOCK, VALET, UNVALET (and others) in Tesla Roadster module
  • Make all SMS responses include the time (if possible), but add a carbits feature FEATURE_CB_SSMSTIME to allow this to be suppressed
  • Allow ACC acc_handle_msg to choose to handle a particular message
  • First implemention of net_fnbits NET_FN_CARTIME (as per http://lists.teslaclub.hk/pipermail/ovmsdev/2013-November/001819.html)

For the NET_FN_CARTIME, this is enabled in vehicle modules by setting net_fnbits |= NET_FN_CARTIME during initialisation (see vehicle_obdii.c for an example) and then not adjusting car_time at all. The car_parktime can be set as normal (using car_time as a reference). This is completely untested (I’ve somehow lost GSM connectivity to my workbench in the last week or two, so this is proving hard for me to test).

The logic for NET_FN_CARTIME is implemented in three places:

  1. The vehicle.c implements initialisation of car_time.
  2. The led.c implements an interrupt to increment car_time every second. As we treat 104.8576ms as 105ms, we are 0.1424ms inaccurate for each clock tick, which may build up over time (but is still more accurate than the previous approach).
  3. The net.c implements handling the response to +CCLK polls, and adjusts car_time and car_parktime if necessary.

I’d appreciate it if someone with better connectivity on their workbench could help test this, and fix as appropriate. Hopefully we can get any bugs in this worked out over the next few days and when it is working change the vehicle modules to use it and then cut a firmware v2.6.7.

Regards, Mark.

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev