The most frequent mistake RF APRS operators make involves setting up the N-path on their station. It may seem a bit arcane to those new to APRS, and the guidance offered in some clients is vague. For example, I was horrified to discover that the Microsat software allowed a user to set up a WIDE7-7 N-path. Sites such as aprs.fi will flag any N-path that uses 3 or above as abusive, and that will clue in some of the most egregious cases.
The N-path instructs the network how to handle your RF packet -- specifically how digipeaters should handle your packet. For example, a WIDE2-2 path means that your transmitted packet will be re-transmitted twice. If it doesn't reach a gateway by then, it will not be re-transmitted again. Of course, other digipeaters in a different area may pick up your digipeated packet after the first "hop" and re-transmit it, unaware that it has already been digipeated somewhere else.
"It's only TWO hops!"
Here's one example. You make a left turn, and your SmartBeacon-enabled client transmits a new location over RF using WIDE2-2.
That packet is heard by the Medina digi (W0PZT-1), which sends it out again to be re-transmitted by the Little Falls digipeater (W0REA-11). It ends up being gated by W0YJC in Pequot Lakes (well north of Brainerd). That's two "hops". Of course, that first "hop" from the Medina digipeater is heard by the Granite Falls digi (NY0I-2), which re-transmits it to a gateway in South Dakota (KE0WPC-10). That's also two hops.
At the same time, the Robbinsdale digipeater (K0YTH-13) has also picked up your original left-turn packet, and it re-transmits that packet to the Askov digipeater (KD9EJA-6). The Askov digi re-transmits it far and wide, and it ends up being gated by KNFRVR (south of Two Harbors). That's two "hops".
But wait! There's more! The Faribault digi (N0QVC-1) has also heard that original left-turn packet, and has re-transmitted it. That digipeated packet is then heard by W0NE-4 outside of Winona, which re-transmits it to a gateway in Wisconsin (KB9WGP-10). That's two "hops". Of course, that first hop from Faribault will also be heard by the Mankato digipeater (N0PBA-1). From Mankato, it will be sent to the gateway in Mountain Lake (MTLAKE) roughly near Windom.
There are multiple other scenarios that could be laid out, too. The point here is that your WIDE2-2 packet triggered by making a left turn into a Walmart parking lot will be heard in three states, and across most of Minnesota.
But it's "just" two hops.
Of course, that packet will only be gated once. Whichever gateway sends it to the -IS servers first will be the one on record as the destination. But that WIDE2-2 packet you sent will still be heard by all of the other gateways listed in that scenario, and many others. The servers will simply reject that packet as a "dupe" or duplicate.
What's a responsible N-path?
Like most complicated questions, the answer is "it depends". If you are in a remote area and can't reach a digipeater with your station, increasing the "hops" in your N-path is sheer folly. If you are in the metro, one hop (e.g. WIDE 2-1 or WIDE1-1) will certainly be good enough to reach a gateway.
There are cases when you might actually want to reach a very wide area. For example, in a disaster you might need to send a bulletin or QST message to as many operators as possible. I would still question how many digipeaters across the state would be functional in such a disaster, but sending a WIDE2-2 packet might be a valid way to find out.
In any case, it should be clear that a WIDE3-3 N-path would be excessive, and anything more than that is deserving of ridicule.
What about WIDE1-1?
The APRS protocol establishes a concept of a "fill-in digipeater", but that is mostly ignored these days. A fill-in digipeater uses a WIDE1-1 N-path, but virtually all digipeaters ignore that and treat such a path as WIDE2-1 or just as another extra hop on a WIDE2-1. Ideally, a fill-in digi would be sited in a valley or around some obstacle, and it would be used to move traffic outside of that valley or obstacle, to be handled as a typical packet by the rest of the network.
Most digipeaters can be configured to only handle WIDE1-1 traffic and act as a fill-in digi. Almost none around the state actually do, however. The Robbinsdale digipeater (K0YTH-13) transmits a WIDE1-1,WIDE2-1 N-path, which makes one wonder.
The vast majority of mobile stations in the metro use WIDE1-1, but in addition to a WIDE2-1 or even WIDE2-2 path. The fault lies with those who operate digipeaters and fail to make proper use of the WIDE1-1 N-path. Ideally, those who run local-coverage hybrid gateway/digi stations should configure their digipeater settings to only respond to a WIDE1-1 N-path. The wider paths should be domain of stations specifically configured for RF transit -- i.e. moving traffic in or out of the metro.
To be clear, a WIDE1-1,WIDE2-1 N-path is, in practical terms, no different than a WIDE2-2 path. And we've seen that a WIDE2-2 path is quite powerful.
When I configured KD0TLS-4 in the new Microsat device, I set the digipeater function to only respond to WIDE1-1 traffic, and only if it hadn't been digipeated before. This was because I am situated midway between two powerful, wide-coverage digipeaters (K0YTH-13 and W0PZT-1). My station is also on relatively high ground overlooking a low-elevation area -- and a particularly low section of I-169. If there were stations that failed to reach the established digipeater network due to terrain, KD0TLS-4 would give them a boost to the wider network. There would be little point in trying to duplicate the coverage of the two larger digipeaters. Instead, I set up a specific niche that my station could fill.
Since APRS is essentially anarchy, with no co-ordination, amateurs are free to set up digipeaters with zero thought as to the role that station should play in the existing network. This situation is exacerbated by individual operators who are indifferent to the impact of their use of a shared simplex frequency. If beaconing every twenty minutes is good, it would seem to them that beaconing every three minutes is even better.
N-path alternatives
There are other alternatives to the standard WIDEN-n format, though this gets into even more more arcane and highly-specific realms.
NULL can replace any N-path. Officially, NULL means "don't send a position" or "ignore any position sent". In practical terms, however, it means "don't digipeat this packet". For an example of this, look at the raw packets sent by N0BPA-1. The problems in this specific case arise from an incorrectly-configured timestamp, and the failure to distinguish between the repeater object sent and the location of the actual station itself.
NULL can be used for strictly simplex operation, or to test simplex coverage. NULL packets are gated, but not digipeated, so a record exists of which stations heard your transmission.
If you want to keep your RF operation local for some reason, NULL is the way to go. A digipeater might be a nice application for NULL, as only those within simplex range of the digipeater need to be aware of its existence.
NOGATE or RFONLY is kind of the opposite. Generally, this is added on the end of a stated N-path -- such as WIDE1-1,WIDE2-1,NOGATE. A packet with this N-path will be digipeated, but not gated. I've always been puzzled as to why someone would use this, but some operators have different notions of what APRS is used for than I do. Some see the use of NOGATE or RFONLY as a way to maintain their privacy, or to outwit "smart" digipeaters that refuse to re-transmit traffic that's already been gated. Still others see any use of the internet as being profane for amateur radio purposes.
One common problem is that people add RFONLY to their path, and then still try to use APRS messaging to reach services or distant stations. Another potential issue is that those who use this option don't contribute to VHF propagation data or to coverage stats for the surrounding infrastructure.
Using NOGATE on a digipeater's beacon ID would result in the APRS-IS servers being unaware of that station's existence, but the digipeater would still re-transmit packets from other stations to be gated -- unless those other operators are using NOGATE too, of course. Also, using NOGATE on your home or mobile station will greatly diminish RF messaging for your station, because the network uses the TX gateway that last heard your ID to send any replies. If a gateway hasn't handled your station in the last two hours or so, the servers won't use it. You could still make RF messaging work, however.
Imagine that you sent a message to an RF operator in Brainerd from the metro, for example. The Medina digi would pass it on to the Little Falls digi, and operator in Brainerd would still (probably) get the message. Their reply would (in theory) follow the same path, and nothing would have been gated at all in the exchange. While your comms would be at the whim of packet collisions, there would no record of the exchange on the -IS. Of course, any station using "RF Eavesdrop" would note that exchange, even if they were in a very different area -- since the Medina digipeater reaches so many other different digipeaters. Yet, such an application would grant some measure of 'privacy'.
The most common justification for using NOGATE/RFONLY also involves 'privacy'. In this scenario, an operator wants no record of their daily travels, usually for security reasons. To my mind, I would suggest simply refraining from using APRS when mobile to someone with these concerns. A home station with a beacon would lead any nefarious person with enough time to follow your activities to believe you are always home.
The deeper issue
Virtually all APRS clients, and certainly all trackers, make it difficult for an RF operator to modify their N-path and adapt to changing circumstances. Mobile operators (myself included) tend to settle on a one-size-fits-all N-path setting. While clients such as APRSDroid are relatively simple to make these changes, a mobile operator would still need to pull over and consciously make the appropriate adjustments. And, in the case of most trackers, an operator would need to connect the device to a computer and alter the configuration.
What is needed is something like SmartBeacon that would be a SmartPath function. If a device hadn't heard a digipeater in a set amount of time, it would increase the N-n path.
Unfortunately, there is nothing in the APRS protocol that allows digipeaters and gateways to identify themselves, beyond the (very) unreliable SSID designation of a station. A query of the -IS would provide that info, but the simple reception of a packet would not. In the same way that some digital mode rigs (DStar, DMR, YSF) contain a database of repeaters and compare that against the GPS location data to provide the most likely repeater connection, the same could be done (in theory) for APRS. But it would merely be a baseline function that would create more trouble than it's worth.
Summary
While any RF APRS operator should evaluate their N-path based on what they need to reach a gateway, there are obstacles for even the most conscientious ham to do so.
While most digipeaters aren't configured to take advantage of the WIDE1-1 path, most could be modified to do so.
In high-traffic areas, the use of "dumb" (non-networked, or not connected to the -IS) digipeaters can turn a sensible transmission into an unreasonably wide one.
No comments:
Post a Comment