[Ovmsdev] ACC and others

Tom Saxton tom at idleloop.com
Sat Aug 17 13:35:51 HKT 2013 

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
>

More information about the OvmsDev mailing list