[Ovmsdev] ACC and others

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.

    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
> 