[Ovmsdev] v2.6.7

Jack West jackduncanwest at gmail.com
Mon Dec 8 10:28:09 HKT 2014

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.


> On Dec 7, 2014, at 4:29 PM, Tom Saxton <tom at 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 at 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:
> The vehicle.c implements initialisation of car_time.
> 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).
> 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20141207/861a5a4b/attachment.htm>

More information about the OvmsDev mailing list