[Ovmsdev] Charging and Driving Logs

[Tom Saxton]

Mark,

This will be a great feature!

Cathy and I have logged every charge and drive on all three of our EVs since
2008. Our goal with logging is to enable us to use historical data to answer
the question: how much charge do I need to drive from point A to B in these
conditions? We're also interested in how the performance of each car changes
through seasons and over the years. I've even written an iPhone app just for
the manual logging we do.

The data you propose seems good. I have two suggestions:

1. I think it's more important to track charge depletion than kWh used. If
you're driving hard, either high speed or up elevation, you'll get more
voltage sag and thus less power per amp-hour than you would with more
nominal driving. In these cases, kWh out of the pack understates how much of
the pack's charge you used. So, I'd rather know how much the SOC changed on
a drive or charge segment, preferably in energy units if available.

    Tesla Roadster: ideal mi|km
    Tesla Model S: ideal or rated mi|km
    LEAF: Gids

On cars that don't have an energy unit SOC measurement, then SOC % would
work.

On drive records, if there's isn't enough room for kWh and change in SOC,
I'd prefer change in SOC. I even prefer computing miles per ideal mile (or
miles per charge %) to know Wh per mile.

On charges, the kWh drawn from the wall is useful data, but I'd also like to
know how the SOC changed.

2. On the charge record, what do you mean by current used? Peak current or
average current? With tapering near the top of a charge, they can be quite
different. I'd suggest peak current. You could even get rid of it if you
need the space for something else. You can determine peak power from the
available voltage and current (plus knowing the car's limit), and you can
calculate average power from energy and duration.

    Tom

on 3/10/13 7:42 AM, Mark Webb-Johnson wrote:

> I have wanted to implement charging and driving logs, for some time now. The
> idea is the car will record 'drives' and 'charges' and report them back as
> historical records. This will be independent of the vehicle module, so should
> work for all supported vehicles.
> 
> For each drive, we need:
> 
> End time [4 bytes]
> Duration (seconds) [2 bytes]
> Drive mode [1 byte]
> Start location [8 bytes]
> End location [8 bytes]
> Distance driven [2 bytes]
> kWh used [2 bytes]
> 
> For each charge, we need:
> 
> End time [4 bytes]
> Duration (seconds) [2 bytes]
> Charge mode [1 byte]
> Charge location [8 bytes]
> Current available [1 byte]
> Current used [1 byte]
> Voltage [2 bytes]
> Result (completed, stopped, failed) [1 byte]
> kWh used [1 byte]
> 
> That is 27 bytes per drive, or 21 bytes per charge.
> 
> The problem is that GPRS connectivity may not be there at the end of the drive
> or charge, so we need to store these records. RAM would be good, but we only
> have 429 bytes left (and I think 256 bytes of that may be stack). EEPROM is
> also possible, but full of parameters at the moment.
> 
> I'm thinking of using the top 4 parameters (#20 through #23) - these appear to
> be free at the moment, and would give us 128 bytes of permanent storage.
> Easiest would be 32 bytes for each record.
> 
> This would be turned on with a FEATURE_CARBITS (suggestion: 0x80), so it would
> default off (for privacy).
> 
> Comments / suggestions?
> 
> Regards, Mark.
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev