[Ovmsdev] ACC and others

[Tom Saxton]

Hi Mark,

I have a theory...

Earlier in the day, I did a manual cool down by charging in Range mode at
12A, which I set directly on the touch screen. After the battery pack had
cooled, I used the OVMS app to switch to Standard mode at 40A.

It stayed at the 40A limit through the rest of the charge, which I
interrupted for another drive. When we got home, it apparently switched back
to 12A before I started the cool down via the new OVMS feature.

So, I wonder if changing the current limit via OVMS doesn't register the
same way that doing it on the touch screen does, leaving the car thinking
that the earlier change on the touch screen should remain the default for
that location?

    Tom

on 8/17/13 6:16 AM, Mark Webb-Johnson wrote:

> Tom,
> 
> Here are the server logs (nothing very confidential in the 'S' and 'D'
> messages [I've removed odometer, etc, after temperatures], so hope ok to post
> here):
> 
> 2013-08-17 00:56:14.477118 -0400 info  main: #69 C SAX217 rx msg S
> 71,M,-1,0,stopped,standard,132,139,40,226,100,27,7,21,0,0,0,-1,151.91,17,-1,0,
> 0,0,0,0
> 2013-08-17 00:56:14.480328 -0400 info  main: #69 C SAX217 rx msg D
> 128,32,3,38,68,30,...
> 2013-08-17 01:06:09.329374 -0400 info  main: #69 C SAX217 rx msg S
> 68,M,-1,0,stopped,standard,126,140,40,226,100,27,7,21,0,0,0,-1,151.91,17,-1,0,
> 0,0,0,0
> 2013-08-17 01:06:09.333821 -0400 info  main: #69 C SAX217 rx msg D
> 128,32,3,41,75,30,...
> 2013-08-17 01:09:57.185946 -0400 info  main: #69 C SAX217 rx msg S
> 68,M,-1,0,stopped,standard,126,140,12,0,100,27,7,21,0,0,0,-1,151.91,17,-1,0,0,
> 0,0,0
> 2013-08-17 01:09:57.189470 -0400 info  main: #69 C SAX217 rx msg D
> 100,0,3,35,60,30,...
> 2013-08-17 01:10:01.765659 -0400 info  main: #69 C SAX217 rx msg S
> 68,M,-1,0,prepare,standard,126,140,12,0,100,0,7,13,0,0,0,-1,151.91,17,-1,0,0,0
> ,0,0
> 2013-08-17 01:10:13.107763 -0400 info  main: #69 C SAX217 rx msg S
> 68,M,1,0,stopped,standard,126,140,12,0,100,0,2,14,0,0,0,-1,151.91,17,-1,0,0,0,
> 0,0
> 2013-08-17 01:10:17.925488 -0400 info  main: #69 C SAX217 rx msg S
> 68,M,1,0,stopped,standard,126,140,12,0,100,0,2,14,0,0,0,-1,151.91,17,-1,0,0,0,
> 0,0
> 2013-08-17 01:10:17.928642 -0400 info  main: #69 C SAX217 rx msg D
> 108,0,3,35,60,30,...
> 2013-08-17 01:10:42.844896 -0400 info  main: #69 C SAX217 rx msg S
> 68,M,1,0,stopped,standard,126,140,12,0,100,0,2,14,0,0,0,-1,151.91,17,-1,0,0,0,
> 0,0
> 2013-08-17 01:10:42.849100 -0400 info  main: #69 C SAX217 rx msg D
> 108,0,3,34,59,30,...
> 2013-08-17 01:12:31.604588 -0400 info  main: #24 C SAX217 rx msg S
> 64,M,239,16,charging,range,151,168,16,1,100,0,5,1,3,0,0,-1,151.91,367,-1,0,0,1
> ,27,42
> 2013-08-17 01:12:35.524060 -0400 info  main: #24 C SAX217 rx msg D
> 124,0,3,36,57,30,...
> 2013-08-17 01:12:44.965847 -0400 info  main: #24 C SAX217 rx msg D
> 124,0,3,36,57,30,...
> 2013-08-17 01:16:31.640460 -0400 info  main: #24 C SAX217 rx msg S
> 68,M,1,0,stopped,standard,127,141,12,5,100,0,3,21,0,0,0,-1,151.91,381,-1,0,0,0
> ,27,38
> 2013-08-17 01:20:24.337827 -0400 info  main: #24 C SAX217 rx msg S
> 68,M,1,0,stopped,standard,127,141,12,5,100,0,3,21,0,0,0,-1,151.91,381,-1,0,0,0
> ,27,38
> 2013-08-17 01:20:24.345774 -0400 info  main: #24 C SAX217 rx msg D
> 108,0,3,34,59,28,...
> 2013-08-17 01:20:50.817512 -0400 info  main: #24 C SAX217 rx msg D
> 108,0,3,34,59,28,...
> 2013-08-17 01:21:31.476733 -0400 info  main: #24 C SAX217 rx msg D
> 100,0,3,33,59,28,...
> 2013-08-17 01:21:31.479403 -0400 info  main: #24 C SAX217 rx msg S
> 68,M,-1,127,stopped,standard,127,141,12,-1,100,0,3,21,0,0,0,-1,151.91,381,-1,0
> ,0,0,27,38
> 2013-08-17 01:28:00.151699 -0400 info  main: #24 C SAX217 rx msg S
> 67,M,-1,127,stopped,standard,125,139,12,-1,100,0,3,21,0,0,0,-1,151.91,381,-1,0
> ,0,0,27,38
> 2013-08-17 01:28:00.156752 -0400 info  main: #24 C SAX217 rx msg D
> 100,0,3,33,59,28,...
> 2013-08-17 01:28:40.931885 -0400 info  main: #24 C SAX217 rx msg D
> 100,0,3,33,59,28,...
> 
> Time zone is EDT.
> 
> The "S" message fields are:
> SOC
> Units ("M" for miles, "K" for kilometres)
> Line voltage
> Charge current (amps)
> Charge state (charging, topoff, done, prepare, heating, stopped)
> Charge mode (standard, storage, range, performance)
> Ideal range
> Estimated range
> Charge limit (amps)
> Charge duration (minutes)
> Charger B4 byte (tba)Charge KWH consumed
> Charge sub-state
> Charge state (as a number)
> Charge mode (as a number)
> Charge Timer mode (0=onplugin, 1=timer)
> Charge Timer start time
> Charge timer stale (-1=none, 0=stale, >0 ok)
> Vehicle CAC100 value
> ACC: Mins remaining until car will be full
> ACC: Mins remaining until car reaches charge limit
> ACC: Configured range limit
> ACC: Configured SOC limit
> Cooldown: Car is cooling down (0=no, 1=yes)
> Cooldown: Lower limit for battery temperature
> Cooldown: Time limit (minutes) for cooldown
> 
> The "D" message fields are:
> Door state #1
> Door state #2
> Lock/Unlock state 4 = car is locked
> Temperature of the PEM (celcius)
> Temperature of the Motor (celcius)
> Temperature of the Battery (celcius)
> 
> From what I can see, earlier (01:06:09) you had current limit at 40A, but at
> 01:09:57 it was reported as having dropped to 12A. The cool down charge
> started at 01:12:31 (switching to range mode and 16A) and stopped at 01:16:31
> (switching back to standard mode and 12A). The cool down only ran for 4 mins,
> to bring battery temperature down from 30Celcius to 28Celcius. I guess it hit
> 27Celcius (your requested limit temperature) quite quickly, then went up 1
> more degree after the stop.
> 
> The strange thing is why the drop in current limit from 40A at 01:06:09 to 12A
> at 01:09:57. It seems that at 40A the car was driving, but at 12A the car was
> parked with the charge port open.
> 
> Do you have the roadster set to save a charge limit of 12A at that location?
> From what I can see with the 2.x cars, the charge limit based on location is
> set immediately the charge port is opened (which is why my ACC stuff delays a
> few seconds before setting what it wants).
> 
> Regards, Mark.
> 
> P.S. Thanks for jumping on and helping test this. I've done quite a few cool
> downs in my 2.5 car, but it is good to see it work in a 1.5.
> P.P.S. If you look closely, you'll see your hard work on charge time
> prediction show up. An estimate of 367 minutes from SOC 64% to full range
> mode, at 16A, changing to 381 minutes in standard mode at 12A. Nice.
> 
> On 17 Aug, 2013, at 1:35 PM, Tom Saxton <tom at idleloop.com> wrote:
> 
>> I tried the cooldown feature with the right firmware installed this time.
>> 
>> It worked as expected, charging in Range mode at 240V/16A.
>> 
>> After the cooldown, it restored the charge mode to Standard, as expected,
>> but the OVMS app reported that the charge current was restored to 12A
>> instead of 40A as it was when I started cooldown.
>> 
>>    Tom
>> 
>> on 8/16/13 3:17 PM, Tom Saxton wrote:
>> 
>>> Nevermin. The build worked, the download didn't.
>>> 
>>> Now I have the correct software on the module, which reports "2.5.1/TR/V1".
>>> 
>>> I may get another chance to try cooldown tonight.
>>> 
>>>    Tom
>>> 
>>> on 8/16/13 1:42 PM, Tom Saxton wrote:
>>> 
>>>> Mark,
>>>> 
>>>> Wow, great stuff. Can't wait to have this all working!
>>>> 
>>>> I built and installed the latest version and tried to do a cooldown, but
>>>> couldn't get it to work.
>>>> 
>>>> I arrived home with the batteries at 98F (37C), flashed the OVMS device,
>>>> and
>>>> sent a cooldown command. Nothing.
>>>> 
>>>> I set feature #13 to 255 and sent cooldown again. Nothing.
>>>> 
>>>> I took a look at the code, set param 15 to "27,45", sent cooldown again.
>>>> Nothing.
>>>> 
>>>> I look at the code some more, so that the car had to be "on" for cooldown
>>>> to
>>>> work, so I went out and opened the driver's door to wake the car up.
>>>> Battery
>>>> pack still at 98F. Sent cooldown again. Nothing.
>>>> 
>>>> I do have feature 15 (CAN Write) set to 1. The OVMS app lists the firmware
>>>> version as "2.3.3/TR/V1".
>>>> 
>>>> As I wanted to cool the batteries and then do a change, I manually kicked
>>>> off a 12A Range mode charge.
>>>> 
>>>> What should I try next time the batteries are hot?
>>>> 
>>>>    Tom
>>>> 
>>>> 
>>>> on 8/15/13 6:55 AM, Mark Webb-Johnson wrote:
>>>> 
>>>>> Wow, let's not do that again.
>>>>> 
>>>>> I just spent the past two weeks trying to debug a problem where my car
>>>>> module
>>>>> kept rebooting. The debug crash log showed it seemed to be identical to a
>>>>> normal power-on start. Seems like the module rebooted itself a dozen times
>>>>> a
>>>>> day. After trying everything - more than a dozen firmware changes
>>>>> painfully
>>>>> loaded into the car module, I finally found the problem:  the module was
>>>>> rebooting, it was just incorrectly reporting a reboot every time the
>>>>> cellular
>>>>> signal recovered. Good grief.
>>>>> 
>>>>> Anyway, back on track again now.
>>>>> 
>>>>> Today, I've pushed to github my backlog of 36 commits, totalling 1.5MB!
>>>>> This
>>>>> makes the first 'alpha' release of v2.5 code. A summary of the (extensive)
>>>>> changes:
>>>>> 
>>>>> Tesla Roadster Experimental Speedo
>>>>> 
>>>>> No longer experimental. Now on bit#0 of permanent feature #13. Old feature
>>>>> #0
>>>>> no longer used.
>>>>> 
>>>>> Drive and Charge logging
>>>>> 
>>>>> Server as well as vehicle changes made to support this. Setting bit#1 of
>>>>> permanent feature #13 will turn on logging of drives. Setting bit#2 of
>>>>> permanent feature #13 will turn on logging of charges. If enabled, at the
>>>>> end
>>>>> of each drive/charge the logging system will attempt to upload a
>>>>> *-Log-Drive
>>>>> or *-Log-Charge record with details on the drive/charge. It can store up
>>>>> to
>>>>> 6
>>>>> such records without server connectivity. The records themselves can be
>>>>> downloaded as historical data using either the HTTP or OVMS protocol APIs.
>>>>> To
>>>>> implement this, a new 'h' style of historical data submission has been
>>>>> supported by the server - this allows for acknowledgement of successful
>>>>> data
>>>>> reception by the server, as well as a time offset for cases where the data
>>>>> cannot be immediately transmitted.
>>>>> 
>>>>> Cooldown
>>>>> 
>>>>> Core support has been added for 'cool down' charges, and implemented in
>>>>> the
>>>>> Tesla Roadster module. Cooldowns can be initiated by the 'COOLDOWN' SMS
>>>>> message, or by server command #25.
>>>>> 
>>>>> Tesla Roadster event notification
>>>>> 
>>>>> A few changes have been made to the Tesla Roadster module to try to make
>>>>> it
>>>>> notify the server of major events immediately (such as charge mode
>>>>> changes,
>>>>> charge limit changes, etc).
>>>>> 
>>>>> Server support for Authentication failures
>>>>> 
>>>>> The server code has been extended to send a PUSH notification in the event
>>>>> a
>>>>> vehicle authentication fails. The server will also send another PUSH
>>>>> notification if the vehicle subsequently authenticates successfully.
>>>>> 
>>>>> Distance utility function
>>>>> 
>>>>> Courtesy of Tom, a distance utility function to calculate the distance
>>>>> between
>>>>> two GPS locations and tell if they are closer than a pre-set limit.
>>>>> 
>>>>> NET fixes
>>>>> 
>>>>> Added a few more checkpoints and sanity checks for NET layer data, to try
>>>>> to
>>>>> avoid crashes and overflows.
>>>>> 
>>>>> Debug Crash Reason reporting
>>>>> 
>>>>> Bug fix to avoid duplicate reports of debug crashes every time the server
>>>>> connection is made. As a side-effect, normal first-time boot-ups will no
>>>>> longer be reported (by design).
>>>>> 
>>>>> Stub ACC implementation
>>>>> 
>>>>> I've done a lot of work on ACC in my own branch, but not committed to
>>>>> head,
>>>>> yet. I need some more time to do further testing before I'm ready to
>>>>> release.
>>>>> For the moment, there is a minimal implementation the does the ACC
>>>>> location
>>>>> mapping, and is capable of seeing if the car is within range of an ACC
>>>>> location. You can also configure the ACC locations and parameters. More on
>>>>> this will come with v2.5.2.
>>>>> 
>>>>> Documentation
>>>>> 
>>>>> I've updated the Tesla Roadster user guide, as well as OVMS Protocol
>>>>> guide,
>>>>> for the above.
>>>>> 
>>>>> I haven't built binary firmware for this yet, as it is so new and raw. It
>>>>> is
>>>>> running in my car, and now seems stable, but needs more testing before
>>>>> prime-time release. If you want to try it, you'll need to build from
>>>>> source.
>>>>> Then, set feature #13 to 255 (to enable all opt-in features) and you
>>>>> should
>>>>> get a digital speedo (Tesla Roadster v2.x cars only) as well as logging to
>>>>> the
>>>>> server of both drives and charges.
>>>>> 
>>>>> I'm over the hump now, and hopefully v2.5.2 can come within the next week.
>>>>> 
>>>>> Regards, Mark.
>>>>> 
>>>>> On 5 Aug, 2013, at 12:38 PM, Mark Webb-Johnson <mark at webb-johnson.net>
>>>>> wrote:
>>>>> 
>>>>>> 
>>>>>> Just a short note on progress.
>>>>>> 
>>>>>> I managed to get a lot done over the weekend. Working with Tom on some
>>>>>> misc
>>>>>> functions for ACC, and all looks good so far. Basic ACC location
>>>>>> management
>>>>>> is done, and I've worked out a way of using base64 to encode the ACC
>>>>>> structures into our limited 32byte parameters. Seems to work quite well -
>>>>>> very lightweight (we already have base64 for the comms protocol), and
>>>>>> very
>>>>>> expandable.
>>>>>> 
>>>>>> I'm now just trying to pull everything together to get cooldown working.
>>>>>> Once
>>>>>> that is working, I'll commit (even in that unfinished form). Logging
>>>>>> (drive
>>>>>> and charge) is already done, and part of this. Flash space is getting
>>>>>> concerning (approaching 95% now, for experimental with all vehicles), so
>>>>>> we'll have to address that once ACC is out.
>>>>>> 
>>>>>> I'm getting a rather large backlog of other requests now (put aside due
>>>>>> to
>>>>>> ACC work, trip to USA for TESLIVE, and horrendous day job hours). Once
>>>>>> the
>>>>>> basic ACC is committed, I'll be able to spend some time to try to work
>>>>>> through that. Apologies for the delays (to anyone waiting for me).
>>>>>> 
>>>>>> 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
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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