<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 10/2/2011 11:59 AM, Arnie Shore wrote:
    <blockquote
cite="mid:CAMN8bj=V2785U8J0jHy3XMkjgY9OJOTJMSqrBOKAQH1bo=rmzQ@mail.gmail.com"
      type="cite">Re "What ya trying to achieve"  I want to get an APRS
      data stream from some arbitrary station onto our CAD's MySQL db.<br>
      <br>
      Currently, we pull a given station's data from ap<a
        moz-do-not-send="true" href="http://rs.fi" target="_blank">rs.fi</a>
      despite that station's sitting maybe six feet away. An ARES/RACES
      team user has asked me to look into avoiding the latency and
      error-proneness inherent to the long path.  (Agreed that we shudda
      done that years ago!)<br>
      <br>
    </blockquote>
    <br>
    Wow!  That is really the long way around!     <br>
    <br>
    Local station heard off-air by nearby igate station --> igate
    passes packets to APRS-IS server --->APRS-IS server passes data
    to all other APRS-IS servers-->one of the APRS-IS servers passes
    data to aprs.FI (which is logged into an APRS-IS server just like
    any other end-user)-->end-user then pulls data off APRS-fi for
    local use.   <br>
    <br>
    At least, you could have an app logged directly into  APRS-IS
    server, with a filtered feed for specific stations.   This at least
    would eliminate the latency of APRS.fi batching up data for a
    specific station and then sending it to you on request, as well as
    numerous additional router hops.    The filtered feed would be
    continuous and immediate (i.e. you automatically get each
    transmission as it is sent), within a few seconds of the original RF
    transmission without having to keep requesting chunks of data from
    APRS-fi.     <br>
    <br>
    If you choose a relatively nearby (physically) APRS-IS server  to
    log  into, you can vastly reduce the number of router hops and
    potential delays/losses of packets, as well as cutting out the
    additional middleman of APRS.fi.  (All data heard by all igates is
    replicated on ALL APRS-IS servers within a second or two of the
    original transmisssion - it doesn't matter which APRS-IS server you
    use.)<br>
    <br>
    <br>
    <br>
    If the area of operations for the command post is such that it can
    hear everything of interest directly off-the-air (or via local
    digipeaters), you could bypass the Internet system entirely,
    assuming your CAD system can pull data from IP-based sources.   <br>
    <br>
    One of the features that is unique (as far as I know) to UIview is
    it's TCP/IP "local server".   Everything UIview hears from the
    attached radio/TNC --and/or-- it's Internet APRS-IS login is
    replicated at a local TCP/IP server port.  In turn, other APRS
    clients and applications on the same LAN can connect to to the local
    server in exactly the same way they would to the Internet APRS-IS. 
       This local server port is fully bi-directional.  Other users on
    the LAN can send messages either to RF (via the UIivew host's
    radio/TNC), --or-- to stations on the APRS-IS --or-- to other
    stations on the LAN.   <br>
    <br>
    The local server feature was specifically built into UIview for the
    kind of operation you are dealing with:  To allow multiple work
    stations in an EOC to share a single radio/TNC and a single Internet
    connection.    <br>
    <br>
    The local server can accommodate almost any number of TCP/IP-enabled
    APRS applications, either on the same machine, or on multiple
    machines on the same LAN.  (Or even from remote locations via the
    Internet, with appropriate port forwarding settings in your Internet
    router.)<br>
    <br>
    I have personally had a copy of UIivew with it's local server
    running supply TCP/IP data to: <br>
    o     Two other copies of UIview (so I could have simultaneous
    multiple mapping views going)<br>
    o     APRSpoint (MapPoint-based APRS client)<br>
    o     APRS Messenger (HF PSK63-based soundcard APRS client) - passes
    30-meter HF APRS activity to the Internet via the UIview host's
    Internet connection.) <br>
    o     UI-Instant Messager (APRS text-messaging-only client patterned
    after AOL Instant Messenger)<br>
    o     Two more copies of UIview running on two other machines on my
    LAN (one a WiFi-connected netbook).<br>
    <br>
    All at the same time, with only one TNC and one Internet connection.<br>
    <br>
    <hr size="2" width="100%"><br>
    --<br>
    <br>
    Stephen H. Smith    wa8lmf (at) aol.com <br>
    === Now relocated from Pasadena, CA back to 8-land (East Lansing,
    MI) ===<br>
    Skype:        WA8LMF<br>
    Home Page:          <a class="moz-txt-link-freetext" href="http://wa8lmf.net">http://wa8lmf.net</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>
    *** HF APRS over PSK63 ***<br>
       <a class="moz-txt-link-freetext" href="http://wa8lmf.net/APRS_PSK63/index.htm">http://wa8lmf.net/APRS_PSK63/index.htm</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>
    <br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>