[aprssig] A few clarifications for a club APRS presentation, Please
Stephen H. Smith wa8lmf2 at aol.comSat May 24 08:22:36 UTC 2008
- Previous message: [aprssig] A few clarifications for a club APRS presentation, Please
- Next message: [aprssig] A few clarifications for a club APRS presentation, Please
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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:
- Previous message: [aprssig] A few clarifications for a club APRS presentation, Please
- Next message: [aprssig] A few clarifications for a club APRS presentation, Please
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
