[Ovmsdev] sprintf / crashes

Michael Balzer dexter at expeedo.de
Thu Jan 3 03:18:09 HKT 2013


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130102/55213eba/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/20130102/55213eba/attachment-0002.vcf>


More information about the OvmsDev mailing list