[Ovmsdev] RFC: Battery status MSG protocol
mark at webb-johnson.net
Sat Dec 15 18:48:25 HKT 2012
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 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.
> 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
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev