[Ovmsdev] RFC: Battery status MSG protocol

[Michael Balzer]

Hi Mark,

this is my first draft of a battery data protocol as implemented in the 
Twizy module 2.0 (see vehicle_twizy_battstatus_msgp()).

For each battery pack (min 1), a message of type "B" transports the 
current state and collected min/max values:

     // Output pack status:
     // MP-0 B,<packnr>,<nr_of_cells>
     //  ,<volt_alertstatus>,<temp_alertstatus>
     //  ,<soc>,<soc_min>,<soc_max>
     //  ,<volt_act>,<volt_act_cellnom>
     //  ,<volt_min>,<volt_min_cellnom>
     //  ,<volt_max>,<volt_max_cellnom>
     //  ,<temp_act>,<temp_min>,<temp_max>

The units now are 1/100 % for the SOCs, 1/100 V for the voltages and 1 
°C for the temperatures. Maybe floats are more readable / standard for 
SOC & V?

Alert status are enums of...
     0 = unknown
     1 = nominal
     2 = suspicious
     3 = alert
     4 = fail

For each cell in each pack, a message of type "H" transports the cell 
details accordingly:

         // Output cell status:
         // MP-0 H,<packnr>,<cellnr>
         //  ,<volt_alertstatus>,<temp_alertstatus>,
         // ,<volt_act>,<volt_min>,<volt_max>,<volt_maxdev>
         // ,<temp_act>,<temp_min>,<temp_max>,<temp_maxdev>

Numbering of packs and cells begins at "1" to reserve "0" for an "all" 
selector.
Alert status uses the same enum scheme as on the pack level.
Voltages on the cell level are in unit mV, temperatures in °C. The 
maximum deviations are signed to reflect the direction of the deviation.

Of course, a cell need not be a physical cell, it's just the smallest 
monitorable unit in a pack. Monitoring huge packs will not be possible 
with the current OVMS hardware, unless we consider streaming all sensor 
data to the server.

I thought about how much could be stored in the server now and had a 
first look at the current server implementation. The primary key of 
table "ovms_carmessages" would need to be changed, as it currently is 
bound to just the message type character (and also case insensitive, 
reducing the number of possible message types). The key would need to be 
extended by the packnr on "B" messages and the pack + cellnr on "H" 
messages.

So, generally speaking, we could introduce 2-3 key extension columns 
that can be used dynamically based on the message type. That would also 
enable storing of other historical records. To keep the database clean, 
an expire mechanism could drop all rows older than e.g. 24 hours.

Please comment.

Regards,
Michael

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

-------------- 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/20121201/46b395fd/attachment-0002.vcf>