<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Looks good. But I do see some compilation issues regarding flash space now.<div class=""><br class=""></div><div class="">Regarding the voltage drop, that is strange. We did test the hell out of this, back-in-the-day, but that was without GPS. Scoped it, and everything seems very smooth even under COPS searching for cellular towers. We have a big capacitor on the 12V side (before the power regulator). Maybe we’re hitting a limit on the power regulator and need extra smoothing on the 3.3V side?<br class=""><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""></div><div class="">On 2 Jan 2017, at 7:44 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Happy new year everyone :)<br class="">
<br class="">
As you may have seen, I submitted a rework of the network framework
yesterday.<br class="">
<br class="">
My goals were to a) eliminate hard coded delays as far as possible
to get faster command responses, b) more stable/reliable tickers and
c) higher frequency logging.<br class="">
<br class="">
I've managed to achieve goals a & b. Commands are now processed
in around one second instead of three, and logging is now very
stable, for example GPS streaming will be very close to one entry
every three seconds.<br class="">
<br class="">
Higher frequency logging would be possible, but I've run into a
hardware issue with this: the modem (both 908 and 808 versions) runs
into under voltage problems if GPRS sends occur faster than once
every three seconds on average. This will even work when the GSM
cell does not change, but if the modem also needs to switch cells on
the road, it occasionally just powers down without warning. This may
also happen when the modem needs very high send power levels, i.e.
if the next GSM tower is far away.<br class="">
<br class="">
The hardware design document says:<br class="">
<i class="">"The transmitting burst will cause voltage drop and the power
supply must be able to provide sufficient current up to 2A. For
the VBAT</i><i class=""><br class="">
</i><i class="">input, a decoupling capacitor (low ESR) such as a 100 μF is
strongly recommended."</i><i class=""><br class="">
</i><br class="">
...and the same problem could be solved here by adding a 10 µF
buffer capacitor to the power supply line:<br class="">
<a class="moz-txt-link-freetext" href="https://forums.tessel.io/t/gprs-module-turns-off-randomly/250/7">https://forums.tessel.io/t/gprs-module-turns-off-randomly/250/7</a><br class="">
<br class="">
So higher frequency logging may be possible when the modem does not
need to power up its own GPS circuit, i.e. when the car supplies GPS
coordinates.<br class="">
<br class="">
One GPS (speed) mark every three seconds is still sufficient, now
it's stable.<br class="">
<br class="">
Btw, I also think I fixed the buffer overrun issue. I could
reproduce the bug by timing a command send to arrive at the module
at the moment the module starts a send itself. I then found some
potential buffer problems with this case in the net_poll() code.
Since fixing them I had no more events and can no longer trigger the
bug with that command timing.<br class="">
<br class="">
Please let me know if you run into new issues with this rework.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></div></body></html>