[Ovmsdev] v2.6.7

Tue Dec 9 02:54:41 HKT 2014

I just tried it and it works. Thanks!

   Tom

On 12/7/14, 9:12 PM, "Mark Webb-Johnson" <mark at webb-johnson.net> wrote:

I just committed, and pushed, the fix for this.

Regards, Mark.

On 8 Dec, 2014, at 1:00 pm, Tom Saxton <tom at idleloop.com> wrote:

> I got it: texting "ACC PARAMS" with no arguments corrupts the cooling
> parameter.
> 
> Thanks Jack and Mark!
> 
>     Tom
> 
> On Dec 7, 2014, at 6:38 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
>> Yes, I've seen this for a while. I assumed it was something to do with the
>> early versions, but perhaps it is still there somewhere.
>> 
>> Most likely cause is that the SMS interface uses 1..4 as ACC locations, using
>> n-1 as offset from parameter #16. If an ACC location of zero is somehow
>> getting through, then that would cause an offset of -1 and the problem.
>> 
>> I had a sniff in the code, and it seems acc_cmd_params() may be checking "if
>> (k<0)" when it should be "if (k<=0)".
>> 
>> Regards, Mark.
>> 
>> On 8 Dec, 2014, at 10:28 am, Jack West <jackduncanwest at gmail.com> wrote:
>> 
>>> 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 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:
>>>> 
>>>> 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 at lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsde>>>>
v
>>>> _______________________________________________
>>>> 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
>> 
>> _______________________________________________
>> 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

_______________________________________________ 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/20141208/e6699330/attachment.htm>