<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Michael,</div><div><br></div><div>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.</div><div><br></div><div>I'll have a look at the GPS logger. It sounds useful.</div><div><br></div><div>Regards, Mark<br><br>On 3 Jan, 2013, at 3:18 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
Mark,<br>
<br>
master merge done. Hm... maybe I should have increased the firmware
version on this... as we've got new functionality, to 2.2.1?<br>
<br>
Following your suggestion I changed the DebugCrash msg to a more
generic and extendable format including the version information.
Example entry:<br>
<br>
MP-0 c32,0,6,6,*-OVM-DebugCrash,2013-01-02
18:33:48,0,2.1.1/RT2.5/V2,0,0000,20<br>
<br>
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.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 02.01.2013 02:19, schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote cite="mid:DC759931-11E2-479A-93B4-E3052434CBC5@webb-johnson.net" type="cite">Michael,
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>It looks good for a master merge.</div>
<div><br>
</div>
<div>Regards, Mark</div>
<div><br>
<div>
<div>On 2 Jan, 2013, at 4:37 AM, Michael Balzer wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> Mark,<br>
<br>
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.<br>
<br>
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.<br>
<br>
@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.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 31.12.2012 16:23, schrieb
Michael Balzer:<br>
</div>
<blockquote cite="mid:50E1AE0F.1050304@expeedo.de" type="cite">Mark, <br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
Regards, <br>
Michael <br>
<br>
<br>
Am 30.12.2012 15:42, schrieb Michael Balzer: <br>
<blockquote type="cite">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? <br>
</blockquote>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
</div>
<span><dexter.vcf></span>_______________________________________________<br>
OvmsDev mailing list<br>
<a moz-do-not-send="true" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
</div></blockquote><blockquote type="cite"><div><dexter.vcf></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OvmsDev mailing list</span><br><span><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a></span><br><span><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a></span><br></div></blockquote></body></html>