APRS setup information from http://www.billdiaz.dynip.com/aprs_info.htm
A number of APRS users frequently incorrectly configure their APRS trackers, fixed stations, digipeaters and client applications. Some well meaning users are compounding the problem by providing “expert” advice to newbies. This “expert” advice has caused trackers to become inoperative, and has clogged 144.39MHZ due to excessive and totally inappropriate paths. Poor APRS operating practices not only affect our local area, but adversely impact users hundreds of miles away. Poor operating practices can cause the network to fail when we need it most, during emergencies such as SkyWarn etc.
Official APRS information and documentation
General APRS information is available at http://web.usna.navy.mil/~bruninga/aprs.html and complete, authoritative APRS documentation is available at http://web.usna.navy.mil/~bruninga/APRS-docs/ . The documentation is for DOS-APRS but it contains a wealth of information about APRS operating practices. UPDATE see http://web.usna.navy.mil/~bruninga/aprs/fix14439.html for the latest info.
Users and potential users should understand what APRS is, and what it isn’t. http://web.usna.navy.mil/~bruninga/APRS-docs/APRS.TXT contains the following quote:
APRS is a real-time tactical digital communicatons protocol for exchanging information between a large number of stations covering a large (local) area.
Note the words “local” and “tactical”. Local as applied to Emergency Management and SkyWarn activities means your local area of responsibility. This could include a single county for Emergency Management or multiple counties in the case of SkyWarn. Individual spotters will generally be associated with a voice net control operator who will relay 2-way information as needed.
The APRS definition does not include using APRS for VHF DX or “Propagation studies”.
APRS Paths or Unproto settings and Digipeaters
Unproto or path settings vary depending on the type of APRS station and the accessibility of Digipeaters and IGATES. Mobile paths are different than home stations, and Digipeaters. One size does not fit all.
The Unproto setting should start with APRS. A typical mobile setting would be APRS,RELAY,WIDE. Trackers solely using a GPS and TNC will use something different but we are concerned here with typical setup procedures. If APRS is not the first element, it is likely your station will not show up in client applications. One local “expert” had a newbie use QRA,RELAY,WIDE3-3. The newbie’s tracker was no longer able to be seen by most APRS client applications.
UPDATE: RELAY,WIDE is no longer appropriate in many areas. See http://web.usna.navy.mil/~bruninga/aprs/fix14439.html for details.
APRS,RELAY,WIDE indicates the user wishes to be digipeated by any RELAY digipeater who hears the packet. Once a RELAY Digi digipeats the packet any WIDE digipeater who hears the packet may digipeat it. Note that RELAY should only be used ONCE in your Unproto setting and it should be the FIRST via in the path. APRS,RELAY,WIDE is proper but APRS,WIDE,RELAY is not!
A RELAY digipeater is generally a modest station such as those found in most shacks. It has limited coverage compared to a bona-fide WIDE digipeater. It’s PRIMARY purpose is to digipeat packets from nearby mobiles to permit access to WIDE digipeaters or IGATES. Too many RELAY’s in a given area is not a good thing, since they can cause excessive channel use when multiple RELAY’s digi the same mobile packet.
A WIDE digipeater is usually equipped with an antenna mounted several hundred feet above average terrain and is intended to cover a wide area which could normally include several counties. Having access to one or two WIDES is good, but too many WIDES in a given area will result in excessive use of air time and will usually result in lost packets due to collisions.
http://web.usna.navy.mil/~bruninga/APRS-docs/DIGIS.TXT includes the following:
APRS WIDE AREA DIGIPEATERS: Wide area APRS digipeaters in sparse areas should be widely separated to provide long distance coverage with the minimum of hops. If there is a need for interim digipeaters to fill in weak signal areas or valleys, then a local RELAY should be installed as
needed but ONLY with the RELAY alias.
………..
FEWER HOPS: Although you are tempted to set a LONG path so everyone can see you, remember that to them, you are just QRM. Especially since the amount of QRM you generate grows geometrically with the number of hops as shown in the following table. ALSO the probability of a successful packet also goes down greatly.
The following table shows the decreasing probability of a successful packet if we assume a 50% probability of collision and each WIDE can hit 4 other WIDES.
HOPS PROBABILITY #COPIES COMMENTS
—- ———– ——- ————————————–
1 50% 1 For local ops & special events
2 25% 5 Routine ops
3 12% 13 extended ops
4 6% 25 statewide ops Heavy QRM
5 3% 41 Nothing gets through. Too much QRM
6 1% 61 Useless AND totally boggs down network
PLEASE limit your hops to just your local region.
APRS *IS* designed to assure delivery to EVERYONE in a 1 or 2 hop area for REAL-TIME nets or events. It was NOT designed for large extended area nets with thousands on line… These days you CAN QSO great distances via the IGates, but this is still a LOCAL process with only enough hops to get to your IGate. As MORE people come to APRS, we must begin thinking SMALLER areas…
Mobile Unproto settings
As you can see in the above table in WB4APR’s documentation, excessive paths will likely result in the loss of packets (yours and others trying to use the channel) and can bring both the local and distant networks to their knees. In fact, experience has shown that you will still lose packets when trying to pass packets to a station you can hear direct, due to the “hidden station” problem.
A fixed station will always hear more stations than a mobile. If a mobile has a clear channel, there is no guarantee that the fixed station also has a clear channel at that instant. If the mobile happens to transmit when the fixed station is receiving another station, one or both packets will be lost. The problem is greatly magnified when the fixed station is a WIDE with extended coverage. Note: This is also the reason it is almost impossible to send APRS messages and receive ACKS via multiple hops.
The proper Unproto setting can vary with your location. If you are operating near home, experience may be the best teacher.
APRS,RELAY,WIDE will provide generally good coverage and access to one or more IGATE’s in your area.
When traveling, APRS, RELAY, WIDE, WIDE or APRS, RELAY, WIDE2-2 may provide good results as well.
Note that some areas, particularly California does not use RELAY at all. This is because an excessive number of RELAY’s digipeating the same packet caused excessive channel use.
UPDATE: RELAY,WIDE is no longer appropriate in many areas. Using WIDE1-1,WIDE2-2 is recommended instead.
See http://web.usna.navy.mil/~bruninga/aprs/fix14439.html for details.
Fixed station Unproto settings
Fixed stations should NEVER use RELAY unless they cannot hear any WIDE’s. Generally, a fixed station can hear multiple RELAY’s. If he sets his path to APRS,RELAY,WIDE, multiple packets may be digipeated by RELAY’s in range. If a local WIDE is set to digipeat both RELAY and WIDE, it is highly likely he will digipeat the packet heard direct as a RELAY and the same packet previously digipeated by a RELAY as a WIDE. This causes multiple transmissions of the same packet and uses excessive air time. We have some fixed users in our area who insist on using RELAY,WIDE and as a result many other users see 4 or 5 copies of EVERY packet they send.
Directed paths may provide better results in some applications. For example, if a given WIDE covers your area of responsibility, and it has proven reliable in the past, use the actual callsign rather than WIDE. APRS,W9AZ-15 will cause your packets to be digipeated only by W9AZ-15. It is also possible for Digi’s to set multiple Aliases. One of the ALIAS’s could be the county name, such as GRUNDY. APRS,GRUNDY will ensure that only digipeaters with an ALIAS of GRUNDY will digipeat these packets. This will drastically reduce the QRM caused to networks in other counties. Reduction of QRM during emergencies and SkyWarn activities is a worthwhile goal.
UPDATE: RELAY,WIDE is no longer appropriate in many areas. For fixed stations, WIDE2-2 is recommended instead.
See http://web.usna.navy.mil/~bruninga/aprs/fix14439.html for details.
Digipeater Unproto Settings
A path of APRS,WIDE is recommended for Digipeater beacons, both RELAY and WIDE digipeaters. WIDE digi’s can usually hear multiple WIDES, and using a longer path will only cause QRM to other networks. Same for RELAY’s who can hear multiple WIDE’s. A digipeater should NEVER use RELAY unless it cannot hear any WIDE’s.
UPDATE: RELAY,WIDE is no longer appropriate in many areas. WIDE1-1,WIDE2-2 is recommended instead.
See http://web.usna.navy.mil/~bruninga/aprs/fix14439.html for details.
APRS messaging
Unlike regular AX.25 packet, APRS does not use connected mode. Therefore, a position packet is only sent once rather than the normal TNC RETRY setting of 5. If the position packet is lost due to a collision APRS will not retry. However, APRS client applications (including Kenwood D7 and D700’s) will resend a message packet or an ACK multiple times before timing out. Experience has shown that APRS messaging beyond one hop results in excessive channel use and poor reliability. Best results can be obtained when messaging with a station you can hear direct. Due to the hidden station problem, it is likely that some packets will be lost, even when communicating directly.
Some APRS client applications (not Ui-View) may retry endlessly and clog a channel for hours or days with the same message or ACK’s.
If you have a reliable, alternative messaging solution, use it rather than APRS messaging. But, it you must use it, try to set your path to the absolute minimum needed to reliably communicate. If you are communicating directly with another station on a regular basis try using a unproto setting of APRS only. Not APRS,RELAY or APRS,WIDE etc, just APRS.
APRS Beacons and Status messages
How often should you beacon or send your position or a status message? It depends. A mobile should send position info more often than fixed stations. However, a stationary mobile sending packets once every minute is consuming resources without providing much benefit to anyone. Same for a fixed station since the fixed station never moves. Some of the smart trackers provide the ability for beacons to be sent at a variable rate depending on speed, or when you turn a corner (smart beaconing). If you have this capability, use it by setting your stationary rate to about once every 10 minutes, and your maximum rate at 60 miles an hour to once per minute.
Fixed stations and digipeaters should beacon about every 30 minutes or so. WB4APR has specific instructions for beacon rates which most applications do not follow. This is a decaying rate, depending on a number of factors. IMO, due to client application limitations a Fixed station should send a beacon about once every 30 minutes or so during normal operations. Some TNC’s support multiple rates etc.
APRS Internet Gateways
APRS Internet Gateways can transfer data between your local RF network and APRS Internet Servers. Your local APRS network operates at 1200 bps while your Internet connection may operate at several Megabits per second. Obviously, the amount of data transferred from the Internet to RF should be kept to a minimum. IGates can selectively gate packets to RF from the Internet. Local packets are often handled automatically. IOW, if a transient mobile station comes into your IGATE area, packets from and to him will be passed.
Too many IGATE’s in a local network is not a good thing, especially if each is gating multiple identical packets to RF. Duplicate gating of NWS watches, warnings, advisories, and other weather related data can overwhelm a network during severe weather outbreaks and preclude APRS spotters from exchanging information. Excessive paths are another pervasive problem. The gating of watches, warnings, and advisories into unaffected areas should not be done. For example, in Will County, we do not want to see watches, warnings, and advisories from Davenport, IA, or Lincoln, IL appearing on RF. Similarly, I see no need to intentionally send Will County’s WWA to those same areas. Obviously there will be some overlap, but we need to keep the local networks available for traffic of immediate concern to affected areas
