[Ovmsdev] RFC: Battery status MSG protocol
Michael Balzer
dexter at expeedo.de
Tue Dec 18 08:05:00 HKT 2012
Mark,
the client_app.pl hint was good, I had not recognized that as a server
query utility yet.
I removed the comma (misread the draft) and can now see my H entries.
However, that lead me back to my assumed connectivity issue:
MP-0 c31,0,2,6,RTPWR-BattCell,1,1,76,2012-12-17 23:18:43,2012-12-17
23:18:43
MP-0 c31,0,3,6,RT-PWR-BattCell,14,16,1215,2012-12-17 23:13:11,2012-12-17
23:18:43
MP-0 c31,0,4,6,RT-PWR-BattC?ll,1,1,65,2012-12-17 23:18:43,2012-12-17
23:18:43
MP-0 c31,0,5,6,RT-PWR-BattPack,1,2,202,2012-12-17 23:13:11,2012-12-17
23:18:43
MP-0 c31,0,6,6,RT-PWR-Usag,1,1,45,2012-12-17 23:13:11,2012-12-17 23:13:11
This C31 result shows all kinds of garbled chars in my module's
messages, and even a truncation on "RT-PWR-UsageStats" (also missing
parts on the data blob on that one).
Now that's a bit odd and most probably cannot be connected to a GPRS
link failure -- as that would not garble single bytes in a TCP connection.
I could fix some similar output problems in DIAG mode more than once by
reducing complex sprintf() calls, so I searched for C18 sprintf() stack
usage and found nothing concrete, but many warnings about very high
stack usage of the whole printf family, plus advice not to use them at
all on small embedded systems. One source mentioned sprintf() will need
70+ bytes stack for a simple integer template.
I also have read a bit into the C18 software stack management and found
my previous assumption to be correct: it's currently fixed to bank 12
(0xC00), so provides 256 bytes for any kind of parameter + local vars
combination. I think sprintf() on a 256 byte stack could well be a
source of problems... and stack overruns can produce weird effects, as
those above. I think about rewriting all my sprintf calls to
itoa/ltoa/ultoa, but find it strange they did no harm up to now, even
with complex templates as in net_msgp_environment(). Or maybe they did,
unrecognized?
Do you have some other info on C18 sprintf()? I'd rather avoid recoding
every output without sprintf(), but that's my best bet currently...
Regards,
Michael
Am 17.12.2012 07:37, schrieb Mark Webb-Johnson:
>
> This has been completed, and is now live on both tmc and development
> OVMS servers.
>
> Server identifies itself as 2.1.1-20121216.
>
> It was implemented in three places:
>
> 1. A new "H" record type - not stored in the carmessages table, but
> inserted with a timestamp into historicalmessages.
> 2. A new command 31 - retrieving a summary of what historical data
> the server has for the vehicle.
> 3. A new command 32 - retrieving detailed historical data records of
> the specified type.
>
>
> I haven't implement data expunging yet. It is actually a one-liner,
> but I've left it out on purpose, since I want to see what data is
> added to make sure everything works correctly.
>
> Michael: Can you try to send your battery data with this new "H" type,
> and let me know when done so I can check server storage.
>
> It is a pretty simple change to the sample client_app.pl code to
> retrieve the summary and/or detailed historical records, if you want
> to see for yourself.
>
> Regards, Mark.
>
> On 16 Dec, 2012, at 10:28 AM, Mark Webb-Johnson wrote:
>
>> 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
>> <mailto: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
>>>>> <mailto:dexter at expeedo.de>> wrote:
>>>>>
>>>>>> Mark, List,
>>>>>>
>>>>>> Am 04.12.2012 20:43, schrieb Michael Balzer:
>>>>>>>
>>>>>>> o 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 <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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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.teslaclub.hk/pipermail/ovmsdev/attachments/20121218/1fe0c852/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20121218/1fe0c852/attachment-0001.vcf>
More information about the OvmsDev
mailing list