[Ovmsdev] ACC and others

Tom Saxton tom at idleloop.com
Sat Aug 17 06:17:12 HKT 2013

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.


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

More information about the OvmsDev mailing list