[Ovmsdev] sprintf / crashes

Thu Jan 3 07:57:21 HKT 2013

Mark,

bumped.

The time stamp is not mine, I just copied the C32 reply. The original 
msg format is simply...

MP-0 H*-OVM-DebugCrash,0,86400
,<firmware_version>/<vehicle_type><vehicle_version>/V<hardware_version>
   ,<crashcnt>,<crashreason>,<checkpoint>

The GPS log msg is...

MP-0 HRT-GPS-Log,<car_odometer>,86400
     ,<car_latitude>,<car_longitude>,<car_altitude>,<car_direction>
     ,<car_speed>,<car_gpslock>,<car_stale_gps>,<net_sq>

-- so, no Twizy specific data in there.

Regards,
Michael

Am 03.01.2013 00:43, schrieb Mark Webb-Johnson:
> Michael,
>
> Looks good. Not sure if we need date/time (the record is stamped when 
> we recieve it, but no harm if easy). You can bump version to 2.2.2.
>
> I'll have a look at the GPS logger. It sounds useful.
>
> Regards, Mark
>
> On 3 Jan, 2013, at 3:18 AM, Michael Balzer <dexter at expeedo.de 
> <mailto:dexter at expeedo.de>> wrote:
>
>> Mark,
>>
>> master merge done. Hm... maybe I should have increased the firmware 
>> version on this... as we've got new functionality, to 2.2.1?
>>
>> Following your suggestion I changed the DebugCrash msg to a more 
>> generic and extendable format including the version information. 
>> Example entry:
>>
>> MP-0 c32,0,6,6,*-OVM-DebugCrash,2013-01-02 
>> 18:33:48,0,2.1.1/RT2.5/V2,0,0000,20
>>
>> Btw: I think the GPS logger could also become a standard function. 
>> Besides producing nice tracks it's useful to test different antennas 
>> and antenna positioning. Maybe the send rate needs more 
>> configurability, it currently logs once per minute or every 5 seconds 
>> if streaming is enabled.
>>
>> Regards,
>> Michael
>>
>>
>> Am 02.01.2013 02:19, schrieb Mark Webb-Johnson:
>>> Michael,
>>>
>>> Not too surprising, and I think your approach is good. The main 
>>> limiting factor we have is RAM, and doing any sort of big buffering 
>>> at the framework level will be hard. I think it is better to limit 
>>> at the module level (as you have done).
>>>
>>> It looks good for a master merge.
>>>
>>> Regards, Mark
>>>
>>> On 2 Jan, 2013, at 4:37 AM, Michael Balzer wrote:
>>>
>>>> Mark,
>>>>
>>>> transparent chunk splitting seems to be non-trivial, so I split my 
>>>> data transfers. Everything's working fine again, so I'll merge into 
>>>> the master next if you don't object.
>>>>
>>>> Btw, AT+CIPSEND? gave me 1460 bytes, so that's supposed to be the 
>>>> size limit we should keep in mind until we find a better solution.
>>>>
>>>> @Nikolay: please note, that's the total size that can be sent 
>>>> within one net_msg_start() ... net_msg_send(), the buffer size 
>>>> (net_scratchpad) further limits a single MSG line to currently 199 
>>>> bytes max.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 31.12.2012 16:23, schrieb Michael Balzer:
>>>>> Mark,
>>>>>
>>>>> I think I found my link dropping problem: scanning a diag log I 
>>>>> took, I found out CIPSEND will fail with a plain "ERROR" if the 
>>>>> data size exceeds about 1500 bytes. I guess that's either the 
>>>>> SIM908 buffer size or the max network packet size. I thought the 
>>>>> SIM908 would handle dividing data into packets as needed. The 
>>>>> SIM908 manual mentions the max packet size depends on network 
>>>>> status and should be queried by "AT+CIPSEND?". After the overrun 
>>>>> net_state_activity() will not recognize "ERROR" to terminate the 
>>>>> pending msg, so will run into the timeout and start a network 
>>>>> re-init.
>>>>>
>>>>> My battery status data exceeds 1500 bytes on first run and later 
>>>>> on if enough cells need updates. I'll think about how to split up 
>>>>> data packets into multiple CIPSENDs. Would be nice if the net 
>>>>> functions take care of this transparently.
>>>>>
>>>>> A secondary issue turned up from the diag log: the SIM908 crashed 
>>>>> in the middle of a CIPSEND command while the module continued to 
>>>>> run normally. The module still thought it's in NET_STATE_READY, so 
>>>>> did not re-initalize the modem. The connection could then be 
>>>>> established on the next CIPSTART, but the complete INIT stuff had 
>>>>> not been done. So it seems independant SIM908 resets need to be 
>>>>> handled as well, and they can occur anytime. I'll see if I can 
>>>>> solve that too.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Am 30.12.2012 15:42, schrieb Michael Balzer:
>>>>>> I hesitate to merge into the master because I currently have link 
>>>>>> / connectivity problems, especially during driving. I introduced 
>>>>>> a GPS logging to optimize my antenna positions and managed to get 
>>>>>> some really nice tracks three days ago, so I don't think this is 
>>>>>> related to my changes... but I'm not 100% sure. I tried different 
>>>>>> antenna positions and another GSM network, but the connection 
>>>>>> keeps dropping when moving the car, and GPS position updates need 
>>>>>> minutes. Could be weather conditions ...or some tricky race 
>>>>>> condition bug?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>> <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/20130103/cdd112e2/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/20130103/cdd112e2/attachment-0002.vcf>