[Ovmsdev] v2.6.7

[Tom Saxton]

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.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20141207/be91faeb/attachment.html>