[Ovmsdev] Release Firmware

[Tom Saxton]

Mark,

I think the CAC code is ready for release. I am continuing to work on a
method to detect precisely when CAC changes but that's not as important as
getting the already excellent CAC support out there.

I've largely confirmed that CAC updates happen along with the SOC settling
that occurs typically about 10 minutes after a charge or drive event, and at
no other time. That seemed to be the case in my manual checking over the
last couple of months and has held up since I've started doing careful
monitoring and logging.

For testing, I have created custom firmware that checks the CAC value
according to your code, plus on the charge settle after a drive or charge,
and also every five minutes. It records timestamps for these various events,
including when it gets a changed CAC value. So far, all four of my recent
CAC updates have fit this model.

I may be the only Roadster owner on the planet who cares about knowing
exactly when the CAC changes, because I'm correlating that with data in the
VMS log file. I think what you have now is ready for the 2.3.1 release, and
is a big win for people contributing to the Roadster battery survey where I
don't care about the small day-to-day variations in CAC.

I may eventually propose a change to when OVMS queries the CAC, assuming the
data continues to hold up.

I'd also like to test on a v2.x Roadster to make sure they behave the same
way.

In case anyone else cares, below is a log of my test results so far.

    Tom

-------

April 8:

17:46:50 drive ended, car turned off
17:56:53 SOC updated (triggers a CAC request)
17:56:53 CAC updated from 149.62 to 149.60

23:01:09 drive ended, car turned off
23:10:52 CAC updated to 149.57 (note: about 10 minutes after drive end)
23:49:51 SOC updated

The CAC happened about 10 minutes after the charge ended. I suspect there
was an SOC update at that point, otherwise the CAC update would not have
been noticed until the second 5-minute update after the drive end at
23:11:11 (periodic updates happen every 5:01). I believe another SOC adjust
happened and got recorded over the timestamp of the first.

April 9:

05:07:40 charge ended (according to VMS log)
05:17:50 CAC value updated to 149.82
05:22:11 SOC update (probably a second update after the charge)

The charge end time was not recorded due to a bug, but I pulled the charge
end time from the VMS log and confirmed that the CAC update happened about
10 minutes after the charge end. Again, the SOC update time probably got
clobbered by second update.

At this point, I fixed the code to record only the first SOC update after a
charge or drive, and fixed the bug that prevented the end-of-charge from
being recorded.

April 10:

When I actually recorded the end-of-charge event, it overflowed the
160-character SMS message limit on the status message, so I couldn't
retrieve the data. Fortunately, the CAC apparently didn't change with the
overnight charge. I created a new CAC command to give me enough room to show
all of the recorded events.

16:27:20 charge ended
16:37:23 SOC updated (triggers a CAC request)
16:37:23 CAC value updated to 149.86

on 4/11/13 7:41 AM, Mark Webb-Johnson wrote:

> 
> China is bugging me for final firmware for the next batch of hardware. I need
> to get them this early next week.
> 
> I've committed what I need for the Tesla Roadster (and framework). Last
> outstanding small change to make is to send CAC as 999.99, rather than the
> current 99999, using Tom's new library function.
> 
> Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is
> ok with current firmware or there is anything you need changed?
> 
> I plan to cut release candidate for 2.3.1 on Sunday.
> 
> Regards, Mark.
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>