[Ovmsdev] ACC and others

[Mark Webb-Johnson]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130815/39e2b7c1/attachment.htm>