<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 12/3/2012 12:35 PM, Jason Low wrote:<br>
    </div>
    <blockquote
cite="mid:CAN06BdvcP2iu9-Cg_bCSSaBVKmRSPZQ2vJUd9B+EUCTUenspAw@mail.gmail.com"
      type="cite"><span
        style="font-family:arial,sans-serif;font-size:13px">Take note of
        the raw packets KD8GBH posted. For some reason the altitude is
        occasionally being prepended with three zeroes, "pushing" the 3
        least significant digits out the other side. A=111405 becomes
        A=000111 in the next packet. That's why the altitude keeps
        dropping to 35 meters.</span>
      <div style="font-family:arial,sans-serif;font-size:13px">
        <br>
      </div>
      <div style="font-family:arial,sans-serif;font-size:13px">The
        position fix errors I'm not sure about. On the raw packets on <a
          moz-do-not-send="true" href="http://aprs.fi/" target="_blank">aprs.fi</a>,
        it looks like some digis/gates are trying to insert positions at
        a much later time than other gates have reported the balloon at
        that same location. Maybe because it's running WIDE2-1 as a
        path, causing digipeats from significantly long distances to
        muck up the works?</div>
      <div class="gmail_extra"><br>
      </div>
      <br>
    </blockquote>
     <br>
    RF distances are not the issue - the RF distance delays would be
    measured in miliseconds or microseconds.     Normally, the  APRS-IS
    will throw out duplicate packets reported by different igates within
    a window of 30 seconds or so.  <br>
    <br>
    This is more likely the infamous "delayed packet" bug in KPC3+ TNCs
    operated in KISS mode.   <br>
    <br>
    After a random period of operation, these TNCs start holding packets
    and not forwarding them to the attached PC for periods of a minute
    or more.  The result is that they arrive at the APRS-IS far beyond
    the usual 30-second dupe-checking window, and are accepted as "new"
    packets even though they are stale.<br>
    <br>
    Kantronicss has been stonewalling this issue for years, and the bug
    continues to exist even in the latest 9.x firmware.   The only known
    fix is to power-cycle or reboot the TNC every 12 to 24 hours.   <br>
    <br>
    <hr width="100%" size="2"><br>
    --<br>
    <br>
    Stephen H. Smith    wa8lmf (at) aol.com <br>
    Skype:        WA8LMF<br>
    Home Page:          <a class="moz-txt-link-freetext" href="http://wa8lmf.net">http://wa8lmf.net</a><br>
    <br>
    High Performance Sound Systems for Soundcard Apps<br>
       <a class="moz-txt-link-freetext" href="http://wa8lmf.net/ham/imic.htm">http://wa8lmf.net/ham/imic.htm</a><br>
       <a class="moz-txt-link-freetext" href="http://wa8lmf.net/ham/uca202.htm">http://wa8lmf.net/ham/uca202.htm</a><br>
     <br>
    Vista & Win7 Install Issues for UI-View and Precision Mapping<br>
        <a class="moz-txt-link-freetext" href="http://wa8lmf.net/aprs/UIview_Notes.htm#VistaWin7">http://wa8lmf.net/aprs/UIview_Notes.htm#VistaWin7</a><br>
    <br>
    "APRS 101"  Explanation of APRS Path Selection & Digipeating <br>
      <a class="moz-txt-link-freetext" href="http://wa8lmf.net/DigiPaths">http://wa8lmf.net/DigiPaths</a> <br>
    <br>
    <br>
    <br>
  </body>
</html>