[aprssig] question on aprs data routing

[Lynn W. Deffenbaugh (Mr)]

You really didn't provide enough information to get an answer to your 
question.

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 
for display?

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 
instantaneous fashion.

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 
packet.

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 
specifically.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  For an additional discussion of APRS Messaging in particular, see

http://aprsisce.wikidot.com/doc:aprs-messaging-explained

On 9/24/2012 1:58 PM, Mike Goldweber wrote:
> Hi,
>
> 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?
>
> Thanks,
> Mike Goldweber
> KB3IXO
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20120924/4fefde1e/attachment.htm>