[aprssig] question on aprs data routing
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Mon Sep 24 13:52:46 CDT 2012
You really didn't provide enough information to get an answer to your
What is "my station"? Is it on RF or Internet?
What is "another station"? What is a "self contained tracking device"?
Is that even related to APRS or is it something else?
What APRS software are you trying to use? Where is it getting its data
What follows is my whirlwind tour of APRS. I've never tried writing
this all down in one place, so please bear with me.
APRS is different things to different people. It ranges from
APRS-capable radios from different manufacturers and/or custom TNC
hardware connected to radios on the RF side, through RF Infrastructure
components like digipeaters and IGates, to the APRS-IS (Internet Side?)
where you find global packet distribution via servers as well as display
client applications and/or web sites like aprs.fi. Oh, and throw into
the mix the fact that some APRS client software can directly interface
to the APRS-IS stream as well as interfacing to RF via TNCs and radios
and you've got a seemingly unlimited number of options.
The Internet side of APRS is IMHO the side that most people see,
primarily because it is accessible to hams and non-hams alike (at least
for viewing) and with zero up-front investment. Sites like aprs.fi
provide instant visibility to many observers whether or not they
actually participate in APRS by bringing up a station. But aprs.fi would
display an empty map without everything that follows.
The various APRS web sites have one thing in common: they draw their
information from the global APRS-IS transport infrastructure. As I
understand it (this pre-dates my involvement), the APRS-IS
infrastructure was originally conceived to, and still has an advertised
primary purpose of, joining localized APRS RF environments together into
a global network. The APRS-IS does that quite well, but unlike may
people's understanding, the APRS-IS is NOT "the APRS". It's literally
just a series of servers that transport APRS packets in near real-time
across the planet. Where those packets come from and what is done with
them after delivery is not up to the APRS-IS. It simply makes every
injected packet available at every global APRS-IS server in a near
You can't "see" the APRS-IS unless you use something that can interpret,
visualize, and display the information those packets contain. The
APRS-IS also has no memory (with the exception of a 30 minute (typical)
"history" port). Web sites that show you where stations have been in
the past do this by taking a packet feed from the APRS-IS and storing
the information in a database for later display.
Enter now the concept of an Internet-connected APRS client application.
These applications, like APRSISCE/32, UI-View, xastir, APRSdroid, IBCNU,
and others), connect to the APRS-IS infrastructure to receive,
interpret, and display information from the transported APRS packets.
Some of these applications also support creating and injecting their own
packets directly into the APRS-IS for global transport. Packet creators
cannot "force" their information to go anywhere, but simply put the
packet into the stream and let it fly.
Some of these APRS client applications also supporting transmitting
their generated APRS packets to RF via special hardware (TNCs) or
additional software (soundcard modems), but in every case, the APRS
client application will need a radio transceiver somewhere down the line
to actually put the packet out via RF. I personally think of the
APRS-compatible radios (Kenwood's D7/D72/D700/D710 and Yaesu's
VX-8/FTM-350) as being firmware-coded APRS client applications directly
embedded in the radios. The functionality of RF-connected APRS client
applications is up to the application designer. Some are transmit-only,
some can receive, some do both, some have maps, and some are only
textual displays. And as mentioned above, some can do both RF and -IS
either independently or concurrently (more on that below).
Now that we're on the RF side, we need a way to get packets to go
further than a simplex link from a transmitter to a receiver. Enter the
digipeater. With a suitable path in an APRS packet, suitably configured
APRS receivers may receive and re-transmit that packet, not concurrently
like most voice repeaters, but in a receive and re-transmit fashion. A
digipeater is just a digital repeater, receiving packets, inspecting the
path, and retransmitting that packet if everything matches up. The only
control a transmitter has over a digipeater is based on the path
specification in the transmitted packets, and obviously needing to be
within simplex range of the digipeater. Packets do not need to go
through a digipeater to be received by another RF station. If the two
stations are within simplex range of each other, they can see each
other's APRS packets without an intermediary.
So, now we have RF stations communicating, sometimes using digipeaters
and we have Internet stations communicating via the APRS-IS, what joins
them together? Enter the IGate. An IGate is simply a piece of software
(or embedded hardware) that has both RF and -IS connectivity.
RF-received packets can be injected into the APRS-IS for global
transport, and selected packets received from the APRS-IS may be
forwarded over the local RF link. That's really all there is to it.
The IGate isn't anything "special", it's just software to connect the RF
and -IS APRS transport environments.
How do digipeaters fit in with IGates? Remember, an IGate is just
another APRS RF station. It can request the support of a digipeater by
putting the right components in the path of the packets it transmits.
On the receiving side, the IGate doesn't care if it copied a packet
direct from the originating station (simplex) or if it was copied via a
digipeater. As long as the IGate receives a packet, it can act on that
So, how do you get an IGate to route a packet from the -IS to RF? You
don't. Every IGate makes that decision on its own, based on its
software and configuration. There is no inter-IGate communications.
There is no IGate routing protocol. Each IGate operates as an island
decided on a packet-by-packet basis what it's going to do. For
instance, the most popular packet types to be forwarded from the
Internet (APRS-IS) to a local RF environment are messages. The decision
here is simple. Most IGates will transmit messages heard via the
APRS-IS to the local RF if the target station was heard on the RF
"recently" "local" where the definitions of those two terms are
typically 30 minutes and based on the number of used hops or distance
between the intended recipient station and the IGate itself. It's that
simple. If an IGate hasn't heard the recipient recently local, it's not
likely to gate a message to that recipient from -IS to RF. The
exception to this is that some IGate software supports additional
configuration options to allow other packets to be forwarded from -IS to
RF. But that goes beyond this attempt at explaining the basic
components and concepts of "APRS".
Hope this helps. If not, try restating your question more precisely and
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
PS. For an additional discussion of APRS Messaging in particular, see
On 9/24/2012 1:58 PM, Mike Goldweber wrote:
> I have a little bit of confusion about how APRS tracking data gets
> routed. I made an assumption that my station could directly receive
> APRS data from another station or from a self contained tracking
> device. I could then use my APRS software to view the data. It was
> suggested to me that all of the data gets routed to a digipeater
> before coming to my station.
> I'm thinking that both possibilities are true, but I would like to be
> sure. Could someone please clarify this?
> Mike Goldweber
> aprssig mailing list
> aprssig at tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig