On 10/2/2011 11:59 AM, Arnie Shore wrote:
> Re "What ya trying to achieve" I want to get an APRS data stream from some
> arbitrary station onto our CAD's MySQL db.
>> Currently, we pull a given station's data from aprs.fi <http://rs.fi> 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!)
>
Wow! That is really the long way around!
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.
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.
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.)
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.
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.
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.
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.)
I have personally had a copy of UIivew with it's local server running supply
TCP/IP data to:
o Two other copies of UIview (so I could have simultaneous multiple mapping
views going)
o APRSpoint (MapPoint-based APRS client)
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.)
o UI-Instant Messager (APRS text-messaging-only client patterned after AOL
Instant Messenger)
o Two more copies of UIview running on two other machines on my LAN (one a
WiFi-connected netbook).
All at the same time, with only one TNC and one Internet connection.
-------------------------------------------------------------------------------
--
Stephen H. Smith wa8lmf (at) aol.com
=== Now relocated from Pasadena, CA back to 8-land (East Lansing, MI) ===
Skype: WA8LMF
Home Page: http://wa8lmf.net
===== Vista & Win7 Install Issues for UI-View and Precision Mapping =====
http://wa8lmf.net/aprs/UIview_Notes.htm#VistaWin7
*** HF APRS over PSK63 ***
http://wa8lmf.net/APRS_PSK63/index.htm
"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20111002/08c2bd11/attachment.htm>