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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev