FOR a general APRS overview see APRS.HTM.
FOR MOBILE Operations, see MOBILE.HTM
FOR HF Operations, see HF.HTM
FOR an APRS command summary see HELP.HTM
OVERVIEW: This OPERATIONS file may help you to understand the finer points of operating an APRS net both ROUTINE and SPECIAL EVENT. Since APRS was designed to facilitate real-time tactical communications, operating APRS on a routine basis is sometimes like watching the grass grow! The reason for building a routine APRS net is primarily for operator training and familiarity. If your operators are not familiar with APRS in a benign environment, then they will not be able to use it under stress!
Do NOT think that you need GPS for tracking special events. It is so easy to update your vehicle's position just by moving the cursor and hitting the INPUT-MY command, that the only stations that need GPS are the ones that are lost!
DIGIPEATER RULES: The advantages of APRS are many, but there is a price. Since APRS uses a fixed digipeater path sometimes different for different stations depending on geographic location, there is a duplication of on the air packets. This assures that all stations in the net are maintained up to date, but also proves to be less efficient during intense operator-to- operator QSO's where this point-to-point traffic is also being unnecessarily broadcast to all stations in the net. In such cases ALWAYS CHOOSE THE MINIMUM PATH TO THAT ONE STATION. You will be amazed at the improvement in throughput! Watch the DIGI page, and if you can work him direct, DO SO!
WIDE-RELAYS AND MOBILES: The greatest contribution of APRS is the use of generic alias callsigns for digipeaters so that mobiles do not have to change their paths as they move from area to area. Since WIDES are widely separated and are made for WIDE area and LONGHAUL comms, many mobiles cannot hit them reliably. For this reason, all WIDE area digipeaters should have a SECOND alias of RELAY. This makes EVERY station INCLUDING digi's act as a RELAY. This permits mobiles to send their packets VIA RELAY,WIDE no matter where they are. This allows the WIDES to remain WIDELY separated and local gap-filler digis (as RELAY only) to be placed wherever needed to provide good mobile coverage everywhere. See DIGIS.HTM. FIXED stations should NOT use RELAY generic paths except under the most unusual circumstances. Or in brand new nets with no WIDES and no one knows who is on the air or who has great coverage.
ROUTINE OPERATIONS: The APRS default digipeater path of RELAY is ok for a few users starting up an APRS net, but you will soon need to focus on a few good stations to serve as WIDE area digipeaters. The reason for this is obvious. As soon as you get 3 or more local stations on APRS, any station living equi-distant (RF wise) from any two other stations will ALWAYS hear a collision of EVERY packet digipeated by both of those stations. That is why, once your network begins to grow, you need to designate your path by specific callsign and designate certain high stations as permanent digipeaters. If you put up a few good wide area digipeaters with the generic ALIAS of WIDE, the coverage of the network can be extended significantly. It is important to keep generic WIDEs well separated (40 miles or more over smooth terrain) to minimize duplicate repeats (or you end up with the same collison problem but on a larger scale). Most users should be able to hit at least one of these WIDEs. Just like with the RELAY's, however, users should use the specific digipeater call instead of the generic WIDE in routine cases to minimize collisions. You may store up to 12 different, frequently used DIGI paths using the OPS-DIGI command for instant recall to tailor your DIGI path for the exact calls and path for each QSO. Proper use of this capability can significantly improve APRS effeciency and reduce the use of the WIDE,WIDE generic path!
The following paths are reasonable and are used under the circumstances shown:
| RELAY | Default. Good starting place to see whats out there |
| WIDE | Covers your local area if there is a WIDE |
| RELAY,WIDE | Can link you into a WIDE but only if you cannot figure out the call of your neighbor that is RELAYing you |
| WIDE,WIDE | Gets you out 2 hops in all directions with minimal foldback |
| WIDE,WIDE,W3XYZ,W4XYZ | Gets out 2 hops in all directions and 4 hops in the direction towards W4XYZ |
The following paths are NOT considered good practice and should not normally be used... and if you do, some Do-gooder will fuss at you...
| RELAY,RELAY | Some RELAY stations will never hear you due to colisions but his may be ok if there are NO WIDES and no single station has any better HAAT than any other key up on your every packet! |
| WIDE,WIDE,WIDE | Gets you out 3 hops in all directions but also results in as many as 27 duplicate packets plus 30 seconds of airtime. Dont DO THIS! No one will get through... |
| WIDE,GATE | You are QRMing the HF net which you cannot hear! |
| WIDE,GATE,GATE,WIDE | You are QRMing every APRS net in the country! |
ALTERNATE PATHS: If you live in the middle of a network going both directions, then you should consider saving one or more paths using the OPS-DIGI-SAVE command. Save one as WIDE,WIDE,NORTH1,NORTH2 and save the other as WIDE,WIDE,SOUTH1,SOUTH2. Then use the OPS-DIGI-ALT command to specify them as alternate paths some percent of the time. These percentages subtract from your normal path and beacon rate, so understand that your main path will be used less often.
All users must understand that they are responsible for setting their outgoing VIA path so that their packets hit the intended area of interest. Unlike normal CONNECTED protocols which automatically return ACKS via the reverse path of incomming packets, APRS is an unconnected broadcast protocol only and each station's packets will only go via the outgoing path set up by that station. If your station receives a duplicate APRS MSG packet more than twice, it gives you a beep and an alert that your ACK's are probably not being heard by the other station and that you should check your outgoing VIA path.
APRS has a very useful feature for determining the best path between stations. The Power-Height-Gain reporting capability lets APRS plot range contours around all stations that have included the P-H-G data in their position reports. For maximum effectiveness, every station should use the INPUT-PWR command to enter his transmitter power, antenna Height Above Average Terrain (HAAT), and antenna gain. Also APRS permanent digipeaters should include this info in their position beacons. Do NOT use height above sealevel or tower height! You may live at 1000 feet above sea level and have a 100 foot tower, but if the land around you is 100 feet higher than you, then your HAAT is ZERO or NEGATIVE! See DIGIS.HTM and PROTOCOL.HTM for the exact formats.
Those stations between WIDE area digipeaters only need to use the single hop of WIDE and their packets will go in both directions. Stations that can only hit one WIDE area station may set the path of WIDE,WIDE without any conflicts. Paths of WIDE,WIDE,WIDE should be avoided because it folds back on itself. The same area can be covered by using WIDE,WIDE,W3XYZ where the unique call of the third digipeater is specifically specified. If you think about it, stations at the end of an area can specify a pretty long string of digipeaters since the path is linear. Stations in the middle can only specify a symetrical double hop with WIDE,WIDE before they have to begin favoring one direction or another with unique calls.
CAUTIONS ABOUT APRS MESSAGES: Remember that the general condemnation of multiple digipeater hops in the packet community applies only to connected protocols. This is because the probability of success goes down drastically because all ACKS must be successfully returned or all packets are repeated. This is generally NOT a problem with most APRS operations which use UI frames without acks. HOWEVER, APRS one-line MSGS are ACKED, and the inefficiency of digipeaters DOES APPLY! If you do a lot of one-line messages between operators, you will experience the same hopeless probabilities of success as with conventional packet. (As noted above, APRS doubles up on ACKS on a poor channel and helps this situation somewhat.) But, in general, NEVER expect an APRS MSG to be successful beyond 2 digi's except if everyone else is DEAD. Operator messages are a secondary function of APRS, and should not be used as a primary means of passing traffic! One further caution, since APRS suspends all packet processing while waiting for the operator with a BOXED prompt, never linger in a prompt. The SEND command is a BOXED prompt and should not be left un-completed!
ACKS THAT DONT MAKE IT: Just like connected packet, the chance of a message packet getting through is usually the same as the chance that the ACK will get back. If the radio path is only 50%, that means that the receiver will probably get the message by the second transmission, but that the sender may not get an ACK until after his 4th! This is because the sender had to send 4 packets to get two through and the receiver then ACKed twice in order to get one through. You see this effect frequently on APRS, when you are talking with a station over a long poor path. You will notice that the person at the other end has already responded to your message even before you get an ack from your outgoing message. BUT your next line will never go out UNTIL it gets that ACK. The reason that you will probably get his response message before your ack, is because his response message is being repeated over and over in the usual APRS decayed algorithm, but his ACK is ONLY transmitted once each time he gets a dupe of your message line to him.
What this means is that whenever it is obvious that the other station has responded to your message line, you should ERASE it so that APRS will move on to the next line. Sometimes if you know that the other station is probably hearing the digi better than the digi is hearing him, and you are not getting ACKS, then simply send him messages in the blind. Let each line will be transmitted for 6 minutes and then you can erase it. APRS will then move on to the next line. Remember that APRS will have transmitted 6 times in the first 6 minutes, but that it will then be over 3 minutes, then 6 and then 12 minutes for further transmissions.
To improve on this effect of lost ACK responses (which I see a lot on HF), APRS recognizes a duplicate message, and not only sends out the usual ACK, but stores a copy for transmisssion in the blind 30 seconds later. The 30 second delay is to avoid cluttering up the frequency if the path is good, since the sending station will have sent the message at least twice in the first 30 seconds. After the third transmission, it is clear that the ACKs are getting lost and it is time to double up. This algorithm has the potential of doubling throughput on a poor channel!
SHORT MESSAGES: As with any packet, especially on HF, the shorter the packet the better the chance of getting through. With 25 characters of overhead, however, there is not much sense in making the message part much shorter than a half line (40 characters). The chance of a 40 character line getting clobbered compared to a 75 character line is 65%. On HF keep 'em short. A trick that I frequently use whenever I know that a station is not currently on the air, or the path is not currently good, is to send the first message line with only the word "test" followed by additional lines with the body of the message. This way, only the very short "test" line is transmitted (often for hours on HF) until the band opens, and then once the station ACKs that line, the remaining lines are transmitted.
BULLETINS: To send a bulletin to all stations, simply SEND a message to BLN# where # is a line number from 1 to 9. Like any other message, these BULLETIN lines will be transmitted on the decaying time period and will soon fade out of the system. If you want the bulletin to remain at about a 15 minute rate, then instead of using numerals in the BLN# mesage, use a LETTER. This way, new stations joining the net will quickly pick up the BULLETINS. Since lines are sorted onto the receiver's BULLETIN page, a new BLNx line will overwrite any previous BLNx at all stations making changes and corrections easy. If your bulletin is time sensitive, be sure to include the TIME in the text, since BULLETINS are not time- stamped. When your BULLETIN is no longer needed, simply ERASE your outgoing BLN#. This will stop your transmission of the BULLETIN lines. Receiving stations can erase all old bulletins by using the ALT-E command.
GATEWAY RULES: I have interjected this paragraph because of the large number of APRS HF to VHF gateways now in operation. First, it is very important that users understand that GATEWAYS ARE ONLY INTENDED TO LINK HF ACTIVITY INTO LOCAL VHF NETS. IT IS INNEFFICIENT, DISCOURTEOUS, AND MAYBE ILLEGAL TO LINK from VHF to HF. Linking HF operations into every local VHF APRS net in the country is not a problem, because the slow 300 baud data rate could never saturate ANY 1200 baud local net. HOWEVER, linking just ONE active VHF net ANYWHERE in the country out onto HF WOULD CERTAINLY BLOCK ALL HF OPERATIONS NATIONWIDE! The capability is there for linking special events or cross country travelers on VHF out for the entertainment of all HF listeners, but DO NOT ABUSE IT, OR WE WILL LOOSE IT! See HF.HTM.
GATE SUMMARY: On HF, use the path of GATE,WIDE and everyone in the country within one WIDE hop of a GATE will likely see you. *Never* use GATE,WIDE,WIDE because your packets will now go 2 hops on VHF and be seen MULTIPLE times from multiple gates! No one can tell where the GATE is and it is just a BIG MESS. Believe me!
Second, never routinely go through a GATE on VHF.
USING THE OPS-COMM-TNC dumb terminal mode. This mode works OK for using your TNC normally, but it doesnt have any file transfer capabilities. You might try to find a small .EXE comm program that you can FILES-SHELL out of APRS, do your COMM thing, and then EXIT back into APRS.... YAPP and PACCTERM both work, but be careful of how these programs change your TNC parameters...
OBJECTS: As noted previously, anyone may place an object on the map and all other stations will see it. On their P-list, the object will be marked with the last three letters of the originating station. Any other station that has more current information on that object can also update its position by hooking, moving the cursor, and then hitting the insert key. His station will begin uplinking the new posit, and all stations, will update their P-list entry for that object INCLUDING THE ORIGINAL UPLINK STATION! Since the new position overwrites the old one, the original originating station will now no longer uplink it. This comes in handy during hurricane tracking. Who ever has information on the latest HURICANE posit uplinks it and everyone then always sees the latest storm track without anyone in the net being dependent on any one station for updates!
Once objects are transmitted on to other station map screens, they will remain there until that operator deletes them, even if the originator stops transmitting them. It will, however, fade to dark gray after 2 hours to show it as an old report. You can use the CONTROLS-FADE command to bring them back to bright colors, or use the J command to see JUST-the-LATEST symbols. The KILL function permits the originator of an OBJECT KILL it from all displays on the net. His station will continue to uplink the object, but tagged with a special KILL flag to suppress its display on all screens. It remains in everyone's P-lists, though, so they can refer back to it if needed. They must still manually DELete it from their P-list as needed. Once the originator has KILLED an object, he should let it remain on his P-list for at least 6 minutes to be sure everyone has received the KILL indicator; then he can delete it from his list.
| CONTROLS MENU: | You can set filters and how you want packets displayed. |
| MAPS: | Turn on or off most map features plus overlay data files on the maps such as DIGIS, Radio Shacks, etc |
| RADAR ALARMS: | Use OPS-SETradar to alarm if anyone enters your"airspace". |
| POSIT ALARMS: | Set ALARMS on any mobile which will alarm if he moves. |
| WX ALARMS: | Set Weather alarms on temps, winds or rain... |
| TRACK MODE: | Lock on to one station and keep map centered |
SPECIAL EVENTS: The Cycle Across Maryland (CAM) bike tour is a good example of a special event using APRS. We had two of three relief vehicles with GPS trackers. These were assembled in cake pan enclosures duct-taped to the roof with a small power cable extended down the windshield and clipped directly to the battery. These packages could be moved among vehicles in about five minutes. Some other packet mobiles ran APRS without GPS units by just using the INPUT-MyPOS command to update their positions. In this manner, my normal APRS/GPS combo can be split into TWO separate tracked vehicles for an event. The GPS/TNC combo acts as a stand-alone tracker, and my laptop and another TNC keep my vehicle on the map manually.
Since we only have two WIDE-RELAY APRS digipeaters in the state, and the CAM tour never went near them, we were dependent on home stations all across the state to serve as digipeaters for the event. The GPS packages were set to digipeat via the RELAY,WIDE path. Even without lots of APRS stations (RELAYs) we got as many conventional packeteers to tune to our frequency for the event and set their TNC aliases to RELAY for that day. This way, the mobiles were never beyond range of at least one RELAY station. Due to the short range of our simple 1 watt units, we needed home stations about every 5 to 10 miles.
We also set up both GPS units with the alias of RELAY so that they would also help digipreat each other along the trail. The disdavantage of this technique however, was evident as both vehicles returned to the evenings command post (also RELAY) and you had three RELAYS in 100 yards of each other! It was noisy within local simplex range of that site, but stations all over the state still saw the packets via the permanent WIDE digipeaters.
SYMBOLS: Recent changes now permit HUNDREDS of different mobile symbols by using the NUMERIC OVERLAY capability. This makes it easy to distinguish mobiles even with CALLSIGNS off to reduce clutter!
EMISSION CONTROL: If there are only a few APRS stations involved in an event but there are lots of APRS observers on frequency, then the observers can set their transmitter off using the CONTROLS-X command to minimize QRM on channel. They can still transmit under manual control by using the X key.
LOAD SHARING: Since any station can take over reporting of any objects, one approach is to let only one station hook every symbol that comes in and then he becomes the reporting repsonsibility. The original station that uplinked the report in the first place will fall silent when it sees the report comming from the designated Net Control station. This way all positions are reported by only one station on frequency, although all other stations can still update the positions as needed. Remember that the last station to report the position of an object will be the one that continues to report it!
MARINE CORPS MARATHON: See MARATHON.HTM for the lessons learned using APRS at the Marine Corps Marathon for the last 3 years in Washington DC.
SLAVE MODE AND EMERGENCY OPERATIONS CENTERS: Dont overlook the fact, that a handful of separate PC computers can ALL BE CONNECTED TO A SINGLE TNC AND RADIO! This fact can be used to create quite an impressive multi-station tactcal communications system that will rival some 911 consoles! By having each PC operating under the SAME callsign, the TNC will not know or care which PC is sending data, and all monitored data will be fed in parallel to all consoles at the same time! The slave consoles will see the MASTER console data after it is digipeated. To make this work, you must set the PC's in the MASTER and SLAVE modes using the alt-SETUP-MODES commands. In these modes, APRS will accept digipeated packets from itself (in this case, other PCs sharing the same TNC) and will see any objects, posted by the other SLAVE consoles. The MASTER remains fully functional, but the slaves act as follows:
This way ALL consoles see the tactical picture, and these SLAVE PC's are at the individual operator's disposal to zoom in, and hop from screen to screen to give them access to what ever info they need! Do not think that a big screen display is better. A single big screen is impressive, but actually useless. Only the person at the KEYBOARD of an APRS system can actually get useful info from APRS. In our county, you need to be below the 8 mile scale to get an idea of what is going on at a crisis, and while you are zoomed in there, others need to be focusing on other parts of the county, or different screens.
At the master APRS PC, you may want to have ON/OFF switches for each of the SLAVE PC TXD lines so that you can control who is permitted to enter OBJECTS into the net. Even without TXD, all SLAVE APRS PC's still provide each individual operator the full APRS tactical picture! If you only need one console for entering data, then you can wire every PC in the building using cheap 2 conductor speaker ZIP cord! You can carry hundreds of feet of this stuff in the briefcase with your portable laptop!
This is a TREMENDOUS capability, since these days PC's are much more plentiful than TNC's and all available assets can be brought into the picture. Every SLAVE operator has his own INDEPENDENT access to all of the APRS info without bothering the APRS operator.