<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">You really didn't provide enough
information to get an answer to your question.<br>
<br>
What is "my station"? Is it on RF or Internet? <br>
<br>
What is "another station"? What is a "self contained tracking
device"? Is that even related to APRS or is it something else?<br>
<br>
What APRS software are you trying to use? Where is it getting its
data for display?<br>
<br>
What follows is my whirlwind tour of APRS. I've never tried
writing this all down in one place, so please bear with me.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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".<br>
<br>
Hope this helps. If not, try restating your question more
precisely and specifically.<br>
<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
Win32<br>
<br>
PS. For an additional discussion of APRS Messaging in particular,
see<br>
<br>
<a class="moz-txt-link-freetext" href="http://aprsisce.wikidot.com/doc:aprs-messaging-explained">http://aprsisce.wikidot.com/doc:aprs-messaging-explained</a><br>
<br>
On 9/24/2012 1:58 PM, Mike Goldweber wrote:<br>
</div>
<blockquote
cite="mid:20120924105821.6285e77fd289b2245967c6ea4157de00.9610e45985.wbe@email09.secureserver.net"
type="cite"><span style="font-family:Verdana; color:#000000;
font-size:10pt;">
<div>Hi,</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>I'm thinking that both possibilities are true, but I would
like to be sure. Could someone please clarify this?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Mike Goldweber</div>
<div>KB3IXO<br>
</div>
<div><br>
</div>
<div><br>
</div>
</span>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<br>
</body>
</html>