[Ovmsdev] Twizy firmware image V2.3.6 / 2.6.5

[Michael Balzer]

Mark,

IF (!) my detailed stats approach makes sense for most users, variables 
would be...

typedef struct speedpwr // power usage statistics for accel/decel
{
   unsigned long dist; // distance sum in 1/10 m
   unsigned long use; // sum of power usedin 1/100 Ws = 1/360000 Wh
   unsigned long rec; // sum of power recovered (recuperation)in 1/100 Ws
} speedpwr;

typedef struct levelpwr // power usage statistics for level up/down
{
   unsigned long dist; // distance sum in 1 m
   unsigned int hsum; // height sum in 1 m
   unsigned long use; // sum of power usedin 1/100 Ws = 1/360000 Wh
   unsigned long rec; // sum of power recovered (recuperation)in 1/100 Ws
} levelpwr;

signed long car_power; // current power in W, negative=charging

speedpwr car_speedpwr[3]; // speed power usage statistics
#define CAN_SPEED_CONST         0           // constant speed
#define CAN_SPEED_ACCEL         1           // accelerating
#define CAN_SPEED_DECEL         2           // decelerating

levelpwr car_levelpwr[2]; // level power usage statistics
#define CAN_LEVEL_UP            0           // uphill
#define CAN_LEVEL_DOWN          1           // downhill


...that would be a total of 80 bytes (currently already allocated in the 
first vehicle overlay section, so should make no difference in total RAM 
usage).

I divide the counters into these sections as I think these are the 
sections of interest in energy use analysis. I consider this still 
experimental, I introduced it to see if the section ratios and sums can 
be used as an indicator for efficient driving style, but I cannot draw a 
conclusion yet from my observations.

The GPS log function really only needs the overall totals. So we could 
basically also reduce the common vars to just one speedpwr entry for the 
overall totals (+ car_power of course). Vehicle modules could still use 
this and add their own vars for accel/decel/up/down, so this would be no 
waste of RAM. Just the current power + overall sums would add 4*long = 
16 bytes to the common car model.

What do you think?

Regards,
Michael


Am 12.05.2013 14:30, schrieb Mark Webb-Johnson:
> Michael,
>
> Should be ok. I think even the Tesla has these.
>
> What variables do we need?
>
> Regards, Mark.
>
> On 11 May, 2013, at 10:52 PM, Michael Balzer <dexter at expeedo.de 
> <mailto:dexter at expeedo.de>> wrote:
>
>> Denis,
>>
>> thanks :-)
>>
>> The GPS logging feature and energy usage stats are currently Twizy 
>> specific.
>>
>> To move these into the framework, we need to make the energy usage 
>> variables part of the common car model. And of course we need to know 
>> how to get these values from other cars like Ampera...?
>>
>> Regards,
>> Michael
>>
>>
>> Am 11.05.2013 10:17, schrieb Denis KRAUTH:
>>>
>>> Wow, great !
>>>
>>> Can this be done on my Ampera too, or is it Twizy-specific ?
>>>
>>> Can FEATURE 8 2 also be applied on my 2.3.2 Ampera firmware?
>>>
>>> There is a Volt/Ampera ecodrive contest in a few days (June 1^st ) 
>>> and this would be really great to track the data.
>>>
>>> I just read your german guide, and it seems really not difficult.
>>>
>>> Hut ab!
>>>
>>> Denis.
>>>
>>> *De :*ovmsdev-bounces at lists.teslaclub.hk 
>>> [mailto:ovmsdev-bounces at lists.teslaclub.hk] *De la part de* Michael 
>>> Balzer
>>> *Envoyé :* vendredi 10 mai 2013 20:26
>>> *À :* 'OVMS Developers'
>>> *Objet :* [Ovmsdev] Twizy firmware image V2.3.6 / 2.6.5
>>>
>>> For those avoiding self-compiling (Nikki et al), here's the current 
>>> firmware image with Twizy extensions.
>>>
>>> It makes GPS logging (RT-GPS-Log) at 5 second intervals stable.
>>>
>>> To get max GPS precision be sure to activate only the GPS logging 
>>> (w/o location streaming) by setting feature #8 to 2.
>>>
>>> The ZIP also contains a guide and spreadsheet template for creating 
>>> energy use heatmap-style GPS tracks using gpsvisualizer.com 
>>> <http://gpsvisualizer.com> -- the guide text is in german now, I can 
>>> make an english version and add it to the repository if there is demand.
>>>
>>> Here's an example result:
>>>
>>> <Mail Attachment.png>
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> -- 
>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>> -- 
>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>> <dexter.vcf>_______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto: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

-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130512/593386eb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130512/593386eb/attachment-0002.vcf>