[aprssig] Fillin digi experiment

Bob Bruninga bruninga at usna.edu
Sun Jan 17 10:14:16 EST 2010


> I think there was some discussion about this 
> "vicious" type of digipeating here a couple 
> of months ago...

This algorithm, though it sounds nice and logical will *ADD* congestion and dupes to the channel because it overlooks one simple but very important concept of the APRS network.

>> If the same beacon is heard being digipeated 
>> by one of the wide area digipeaters within 
>> the 15 second period, the buffer is erased 
>> and the frame is not digipeated.  If no 
>> digipeat is heard, the frame is digipeated...

THe key failure is the first line:
"if the beacon is heard..."

And THAT IS A FALSE TEST and IMPOSSIBLE to assure.  A very large portion of APRS packets (if not HALF or more) that are SUCCESSFULLY transmitted and digipeated on the channel are NOT HEARD at any given receiver due to the fact that all digi's are suposed to digipeat the same packet at the same time (in one slot time).  Hence, any station or digi that hears these two packets at the same time with approximately equal strength will NOT DECODE them.

A FIll-in digi that can hear two other digis will by definition, *not-hear* most packets digipeated by those two digis because those digipeats will happen at the same time and collide at this fill-in's receiver.  Thus, letting this fill-in digi delay any amount of time, and then digipeat this 3rd copy of the packet can only ADD congestion to the channel.

If you do not believe this, go visit a DIGI site or a FILL-IN site and LISTEN to the channel and WATCH the monitored packts on the serial port.  You will see that far more than half of the time that the channel is "busy" (Squelch open) there are no packets decoded due to collisions, yet the channel is IN USE and is CARRYING VALID packets for others somewhere else.

The LAST thing we need in this situation is a digipeater on such an antenna at this location adding duplicate packets becaue it THINKS no one else heard the packet, when in fact it was only itself at its exact antenna location that did not hear it and everyone else did.

There are only TWO cases where fill-ins should digipeat:

1) If the packet is a FIRST HOP WIDE1-1 direct-from-the-user.  Then it should transmit it IMMEDIATELY just like all other digipeaters.  If they heard it first also, they will also digipeat it at the same time and eveyrone else will hear those high-advantaged sites.  If they did not, they will hear the one from this FILL-IN digi site.  This is why FILL-IN's as originally designed, work just fine and do not impact loading on the channel.

2) A listen-first-hold-off-if-heard algorithm CAN ONLY BE USED if *extreme care* is used in setting up the FILL-IN digi antenna so that it hears EACH digipeatr it can hear with at least 13 dB or more signal difference between every one.  This is the ONLY way to assure that this fill-in can resolve ALL collisions on the channel and not be fooled into thinking that it did not hear something.   -AND- this RF LEVEL BALANCE must be managed on a continuing basis and performed each time ANY of the surrounding digi's makes ANY change to its RF system.

In otherwords, #2 is so impossible and fragile to manage, and has such negative consequences when not "tuned for imbalance" that by definition, in many install-and-forget digi's it will guarantee to eventually be a net QRM generator with worse consequences to the region than any short-term benefit.

In fact EVERY station, home, digi, IGate or otherwise can greatlly improve its own performance if it uses the "IMBALANCE TECHNIQUE" in placing its antenna.  Place your antenna low, behind something, on one side of the house,  or near a reflector, etc to make sure that every digi you can hear has at least 13 dB signal difference from the others.  DO that, and you should begin to decode ALL packets during collisions, rather than getting nothing.

I know this is counter-intuitive, but remember in packet, MAX or EQUAL is not better.  Avoiding collisions by RF imbalance is a great improvement technique.

Bob, Wb4APR




More information about the aprssig mailing list