[aprssig] A few clarifications for a club APRS presentation, Please

Stephen H. Smith wa8lmf2 at aol.com
Sat May 24 04:22:36 EDT 2008


Steve Noskowicz wrote:
>   Whomever wants to answer...
>
> I'm giving an APRS overview at the local club and want to test my understanding
> of a few things and get some clarifications.  The AX.25 specs go to the bit
> level and it isn't a good tool to provide an understanding of the higher
> layer(s).  I don't need a ultra detailed, in depth explanation of all the
> specifics.  I just need simplified fundamentals of the higher layers of the
> protocol, in the areas I am asking about.
>
>   I have, and will use, Bob's PowerPoint.  
>
> PLEASE keep answers short.  If I don't understand or want more, I'll ask for
> it.  Its an overview.
>
> I'm sure there are many exceptions or additional important details, but I'm
> just looking for the "first approximation" or the "high level" of what's going
> on in APRS.
>
> I also want to give some comparisons of "standard Packet" and APRS and I know
> very little about standard Packet, but have semi-indirectly absorbed some
> concepts over time. 
>
> SO... Correct me if any of this is grossly wrong.
>
> Regular Packet:
> 1 - Must address specific stations.
> 2 – Must also specify specific digis.
> 3 – Must specify the complete path (*all* station/digi names) to reach a
> distant station.
> 4 – Must "connect" (verify with a two way exchange) with a station to transfer
> traffic.
>
> APRS:
> 1 – Transmits (generally) to any APRS station  (but can address specific
> stations  - including EMAIL and WHO-IS & WHO-15).  An address gets you to
> anyone (everyone) with that address.
>
>   

Correct. I always describe the difference as:

ClassicPacket: 1-on-1 two-way communications with a specific station 
with full error detection/handshaking/ACK/NAK.

APRS: One-to-many broadcast transmission. No handshaking or ACK/NAK -- 
just blast out packets and "pray" that other (often unknown) stations 
receive them successfully.


> 2 – Uses what can be thought of as generic digi names, called aliases.  This
> allows a packet to go through any digi since 'all' digis have the same name
> (call sign), right?  
>
>   
Yes. Classic packet also had aliases in addition to specific callsigns. 
(It was easier for users trying to connect through long strings of digis 
to remember truncated place names rather than specific callsigns.) 
That's why the command "MYA" (MY Alias) exists in TNCs that predated 
APRS. APRS just uses aliases far more intensively; indeed almost 
exclusively.

> Going a little deeper, we can actually specify several station names (aliases)
> to allow for Fill (WIDE1-1) and Wide area (WIDE2-2) digis.
> This is sort of a  "Flex-path", since the Fill sends to the Wide – but the Wide
> also has a Fill alias, in case you get to him first.
>
> 2A – Read this whole section before answering parts...  Is it specific to APRS
> software that allows me to receive anyone's Beacon?  
>   

No. The beacons in classic packet work the same way. The difference is 
that APRS *ALWAYS* uses the UI (Unconnected Information) frames for 
everything while classic packet only uses them for beacons for stations 
to announce their presence to others. Or to conduct net-type one-to-many 
communications in which case you loose the errror correction/ACK/NAK 
that you get with a connection to a single station.

[APRS simply exploited the existing UI frame (beacon) format used by 
classic packet and vastly expanded its usefulness. ]


> After all, it isn't
> addressed to me.  OR is the concept of a Beacon also in Packet (like a
> broadcast bulletin addressed to anyone)?  
> I know I can listen to a packet cluster station without being connected – all
> "I" have to do is decode the packets and the cluster doesn't need to know I am
> listening.  [[It seems that I could also do this to a standard Packet system,
> given capable software]]   My D700 has a place to put which of these general
> purpose messages I will receive, Right?  This appears to be the "Unprotocol"
> parameter...and... the "APxxx" appears to be what allows me to decode and
> display any other "APxxx" group packet.  I think this can be interpreted as
> putting MY RADIO in the "AP" Group and, thus, allows me to receive all other
> "AP" packets.    Does AP stand for anything?
>
>   

In the AX25 foundation, every packet has to be addressed to SOMETHING, 
even if it's just a "bit bucket". In classic packet, you normally 
addressed non-connected beacon packets to "BEACON", but it could 
actually be anything. People often addressed unconnected frames to "CQ" 
or other such fake "callsigns". APxxxx stood for APrs UI frames 
specifically. [In the early days, UI-frame APRS activity often shared a 
channel with connected packet. APRS-specific software would ignore all 
packets except for ones addressed to a destination beginning with 
"APnnnn". This way, the APRS software wouldn't show or respond to the 
unconnected beacons set by classic packet stations. )



> Reading the D700 Special Comm Manual says that there are "group Codes" as well
> as some "Others", such as "CQ", "QST", and "Beacon", but I suspect that these
> are handled the same and therefore are just other Groups.  All Group members
> can receive messages to the group.  
> It this a good interpretation?
>
> One confusion is that (on the D700) there are also a "Group Code" and "BNL
> (bulletin) Code" parameters.   Is the Unproto group sort of an APRS Super Group
> and the others sub groups, within APRS? 
>
> Unnumbered Information (UI) frames and unproto seem to refer to the same thing.
>   I believe standard Packet packets are numbered since a message may require
> more than one packet.   Is this correct?  Since I suspect APRS is all single
> packets  we use Unnumbered frames, because they are more flexible (have fewer
> restrictions), so to speak...?
>
> Does "Unnumbered" actually mean "unconnected".
>
>   
YES. The "UI" in UI-Frame is commonly said to mean "Unconnected" when it 
actually means "Unnumbered".


>
>
> 3 – The actual "Path" in APRS is "determined by" the network (the old saw:
> don't need knowledge of the network).  That is, digis aren't needed, but the
> Digis re-send and others pick up and re-send (to the hop limit), hopefully, up
> to the iGate.  
>
>   

Actually not. Other than the distinction between low-level home WIDE1-1 
fill-ins and WIDEn-N high-level digpeaters, all APRS digipeaters blindly 
respond to the same generic "callsigns" so there no network intelligence 
in the sense of routing tables, etc exists.

The only network control is actually in the hands of the end-users who 
make the decision how many digi hops to set into their device or 
software path settings; ie. do you use "WIDE1-1,WIDE2-1" for two hops, 
or "WIDE1-1,WIDE2-2" for three hops, or (God forbid) WIDE7-7 for too 
many hops, etc.

> An iGate may or may not be a digi, Right?
>
>   

Yes but not commonly. A digipeater wants a high location like a mountain 
top or tall building (i.e. the same kind of place you would place a 
voice repeater), while an igate needs always-on Internet access. Since 
Internet access is often hard to come by in the best digi locations, the 
two are usually separate except possibly for a low-level home fill-in 
digi. As long as the home (igate) station on low ground can reliably 
hear the digi on the high ground, there is no need for them to be 
co-located.


> 4 – APRS doesn't "connect".  It just transmits and crosses its fingers (lets
> ignore a directed message ACK.)
>
>   

Exactly! This is what I mentioned above about "blasting out packets and 
praying that other stations get them". Even the directed message doesn't 
connect in APRS. It's basically a kludge with the message contained in 
one UI-frame, and the ACK in a second UI-frame sent from the other end. 
The significance of this is that the message may go through successfully 
but the sender may not get an ACK back (due to packet collisions, etc), 
and thus never knows for sure that the message was indeed received. 
Since APRS, like classic packet responds to a lack of an ACK by 
repeatedly resending the message, lack of an ack back can cause a large 
number of retransmissions of a successfully sent message.

> I think that's it.
>
> One more.   If my packet makes it to two iGates, the APRS-IS sorts out dups?
>
>   

Yes --- At least if one of the igates don't mangle or modify the packet 
somehow and make it look different to the IS. Or if one igate waits a 
long time (more than 30 secs or a minute) before injecting the packet 
into the IS. [This problem of long delayed packets has been observed in 
the real world, causing a mobile in motion to periodically "hiccup" 
backwards, when a long-delayed earlier packet arrives after a later one 
has been received by another igate.]
>
>
>
>
>   




--

Stephen H. Smith wa8lmf (at) aol.com
EchoLink Node: 14400 [Think bottom of the 2M band]
Home Page: http://wa8lmf.com --OR-- http://wa8lmf.net

NEW! World Digipeater Map
http://wa8lmf.net/APRSmaps

JavAPRS Filter Port 14580 Guide
http://wa8lmf.net/aprs/JAVaprsFilters.htm

"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths

Updated "Rev H" APRS http://wa8lmf.net/aprs
Symbols Set for UI-View,
UIpoint and APRSplus:






More information about the aprssig mailing list