Re: Blocking a digipeater from digi'ing my beacon
That’s a loaded question as you can see from Arnold’s reply.toggle quoted messageShow quoted text
How do you define proper? Is proper what the original intent was, or is it what people have decided the intent should have been, or what people have done because others don’t know what the original intent was, and still others have tried to correct the mess by doing something else to make it “proper”?
APRS has always been a hodge-podge of “kludges”. Bob Bruninga built a concept and protocol on top of hardware and routines that were never meant to do what he implemented. I love it. He took what was available and made it do something totally different.
Packet digipeaters all had unique callsigns and aliases, and the packet radio operator had to explicitly define a route to send packets from point a to point b.
Bob came up with the idea of using the same alias in all digipeaters which would allow a flood of packets outwards from the source in all directions. In the early days, a path of WIDE,WIDE,WIDE was proper, when all digipeaters responded to the alias WIDE.
When UIFLOOD and UITRACE routines came along, WIDE3-3 or TRACE3-3 were proper paths to use.
In the Pacific Northwest, a bunch of us started playing with UIFLOOD WIDE,30,ID as a setting which made the WIDE3-3 path a traceable path. It ended up becoming the defacto standard APRS proper digipeater setting across the continent.
Around that time the concept of setting home stations up to act on only WIDE1-1 was promoted so that low powered stations could get a helping hand to get into the main digipeaters. The main digipeaters were not that plentiful, and could be a fair distance away.
The popularity of APRS increased a whole bunch, which brought more users, and more digipeaters. People started having problems getting heard by the digipeaters, so as a solution, many people set up digipeaters closer to where the users were located. Others resorted to using high power to get heard. The noise floor on 144.390 in some areas became so high it was almost impossible to be heard.
APRS runs on a simplex channel, and uses a store and forward concept to move packets around. Every station on the channel has a unique coverage area that it can hear. When your station wants to send a packet, it listens for a clear channel. It then sends a packet which takes up x amount of airtime. If a digipeater is able to successfully decode the entire packet, it should immediately resend the packet into its coverage area. The digipeater may not be able to successfully decode the packet because of a collision with another packet. This collision is caused by what is known as the hidden station issue. Your station and the colliding station cannot hear each other, but the digipeater can hear both stations.
People see their station transmit, which can only happen when the channel is “clear”, but they don’t get digipeated. Obviously the problem was that the digipeater didn’t hear their station, so the solution is to increase the TX power. In fact, if the problem was a hidden station collision, the answer isn’t more power, but rather retry later and hope for no collision.
Many people opt for the more power solution. Also adding digipeaters within the coverage area of other digipeaters fixes the “problem” of being heard for those close by, due to FM capture effect, but overall it increases the hidden station issue, and crowds the channel by having multiple digipeaters that cover the same area all needing to digipeat the packet all on the same channel.
In some instances, the WIDE1-1 alias was acted upon by a different routine than the WIDEn-N alias, which then meant a digipeater could act upon the same packet twice.
A way to combat that issue was to reduce the maximum number of hops used. Around this time a suggestion to use a path of WIDE2-2 was put out there. With a large digipeater network out there, and lots of I-gates around, 2 hops was deemed more than sufficient. Those low powered stations needing help and then one more hop were asked to use WIDE1-1, WIDE2-1 for a total of 2 hops.
In severely overloaded areas where big digipeaters covered too much area, and dozens of smaller digipeaters were set up inside the large digipeater coverage areas, with far too much overlap with each other, and too many stations using too much power and sending too many packets per hour existed, digipeater operators started implementing bastardized rules in their digipeaters to force users to use non-standard paths in an effort to combat the poor infrastructure implementation, and poor user practices.
Fractured APRS networks abound where the mobile APRS user has to change settings in their station to match local settings. This breaks the fundamental underlying concept of APRS where the end user can set up their station and go where ever and it just works.
So, what is “proper”? WIDE1-1 was defined to be used by low powered stations that could not get to the main digipeaters directly. Every home station should be set up to act on the WIDE1-1 alias. Because the only stations using WIDE1-1 as a hop request, there isn’t any problem with having a lot of stations respond to the digipeat request. If however high powered stations use WIDE1-1, there’s a potential for many home stations to hear the request and act upon it, causing lots of potential noise on the channel. The solution the is to shut down the home WIDE1-1 digioeaters, thereby removing the ability for low powered stations to get help from a nearby home station.
Which is the proper implementation?
Sometimes being the old curmudgeon that’s been around since the beginning of time is a curse. What the heck do I know about APRS implementation? The PNWAPRS Group was on the forefront of experimenting with APRS digipeater implementations before 99% of the current APRS users were even on APRS.
I set up a network of 5 APRS digipeaters in my shack one day with the brand new WIDEn-N configuration, and fired packets into it and recorded what happened. I sent an email to Bob Bruninga asking him if what I was seeing was what was to be expected. His response was “I don’t know, I’ve never seen a properly implemented APRS network at work. “ At that time the APRS network in Maryland was a mish-mash of random digipeater rules, each digipeater doing things a little differently.
I was able to build a fairly large homogenous APRS network in northern Alberta. All digipeaters programmed identically, using the “proper” settings. We have a low user count, the network isn’t overloaded, and we see excellent reliability and can send packets over multiple hops with high reliability.
Your mileage may vary.
On Oct 24, 2019, at 10:34 PM, K3RWN <rwnewbould@...> wrote: