[Ovmsdev] RFC: Battery status MSG protocol

[Mark Webb-Johnson]

Ok.

But, lets keep the *- prefix for generic. Easier to split the fields later in the database, and only 2 bytes extra per record.

I'll try to get the server side of this done today.

Regards, Mark

On 15 Dec, 2012, at 7:19 PM, Michael Balzer <dexter at expeedo.de> wrote:

> Too fast... regarding the class definitions, to achieve readability here as well I would then suggest using a 3 letter abbreviation.
> 
> ...main classes:
>     
>     Power                PWR
>     Engine                ENG
>     Transmission        TRX
>     Chassis                CHS
>     Body                BDY
>     Electrics            ELC
>     
> ...auxiliary classes?
>     
>     Safety                SAF        (Chassis, Body, Electrics)
>     Security            SEC        (Power?, Body, Electrics)
>     Comfort                CMF        (Chassis, Body, Electrics)
>     Entertainment        ENT        (Body, Electrics)
>     Communication        COM        (Body, Electrics)
>     
> 
> Also I would prefer "-" as a separator over ".".
> 
> For my current application (battery pack + cell data), that would result in type codes...
> 
>     RT-PWR-BattPack
>     RT-PWR-BattCell
> 
> ...or general form
> 
>     *-PWR-BattPack
>     *-PWR-BattCell
> 
> Btw: general purpose codes could be written without "*-" prefix as well? That would be...
> 
>     PWR-BattPack
>     PWR-BattCell
> 
> Regards,
> Michael
> 
> 
> Am 15.12.2012 12:01, schrieb Michael Balzer:
>> Silly me just assumed you'd prefer integer... I'm using text codes in my own DB designs whenever possible due to readability.
>> 
>> In other words: of course! :-)
>> 
>> I'll modify my code now accordingly.
>> 
>> 
>> Am 15.12.2012 11:48, schrieb Mark Webb-Johnson:
>>> The coding looks good, and sensible.
>>> 
>>> How about we just make it a text string, rather than integer. Much clearer to read, and almost no impact on size.
>>> 
>>> VV.C.P
>>> 
>>> VV the normal vehicle types, or '*' for generic.
>>> C your class
>>> P your property
>>> 
>>> On 15 Dec, 2012, at 6:53 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>> 
>>>> Mark, List,
>>>> 
>>>> Am 04.12.2012 20:43, schrieb Michael Balzer:
>>>>> type (integer type code)
>>>>> For general purpose type codes, maybe some classification scheme would make sense? Maybe adopt some standard scheme already defined for automotive data? ...if there is one...
>>>> 
>>>> It seems there is none suitable, so here's my attempt at defining one. Please comment.
>>>> 
>>>> Regards,
>>>> Michael
>>>> 
>>>> 
>>>> Type classification scheme:
>>>>     id size: 32 bit integer
>>>> 
>>>> Generic / standard props:
>>>> 
>>>>     0x 0000 C PPP
>>>> 
>>>> Vehicle specific props:
>>>> 
>>>>     0x VVVV C PPP
>>>> 
>>>>     VVVV = Vehicle ID
>>>>         0001 = Tesla Roadster
>>>>         0002 = Tesla Model S
>>>>         0003 = GM Volt / Opel Ampera
>>>>         0004 = Renault Twizy
>>>>         ...
>>>> 
>>>> C = Class:
>>>> 
>>>> ...main classes:
>>>>     
>>>>     0 = Power                
>>>>     1 = Engine                
>>>>     2 = Transmission        
>>>>     3 = Chassis                
>>>>     4 = Body                
>>>>     5 = Electrics            
>>>>     
>>>> ...auxiliary classes?
>>>>     
>>>>     6 = Safety                (Chassis, Body, Electrics)
>>>>     7 = Security            (Power?, Body, Electrics)
>>>>     8 = Comfort                (Chassis, Body, Electrics)
>>>>     9 = Entertainment        (Body, Electrics)
>>>>     a = Communication        (Body, Electrics)
>>>>     
>>>>     
>>>>     b = reserved
>>>>     c = reserved
>>>>     d = reserved
>>>>     e = reserved
>>>>     f = reserved
>>>>     
>>>> 
>>>> PPP = Property
>>>>     ...allowing for 4096 properties per class.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> 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
>>>> 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
>> 
>> 
>> _______________________________________________
>> 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
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121216/5346e854/attachment.htm>