<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Happy new year everyone :)<br>
    <br>
    As you may have seen, I submitted a rework of the network framework
    yesterday.<br>
    <br>
    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>
    <br>
    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>
    <br>
    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>
    <br>
    The hardware design document says:<br>
    <i>"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><br>
    </i><i>input, a decoupling capacitor (low ESR) such as a 100 μF is
      strongly recommended."</i><i><br>
    </i><br>
    ...and the same problem could be solved here by adding a 10 µF
    buffer capacitor to the power supply line:<br>
    <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>
    <br>
    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>
    <br>
    One GPS (speed) mark every three seconds is still sufficient, now
    it's stable.<br>
    <br>
    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>
    <br>
    Please let me know if you run into new issues with this rework.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>