[aprssig] Q: Vicious digipeater

Fri Oct 23 21:32:25 EDT 2009

> It is all matter of having the property of viscosity.
> 
> 1) A digi keeps heard packets in probation delay 
> pipe for a few seconds (4-8), and if during that 
> time the same packet is heard again, a viscous 
> digi will drop the packet from memory.  "Somebody 
> else did hear it, I do not need to repeat it."
>
> 2) If no other transmission of the packet is 
> heard during the probation delay, the packet 
> is viable for retransmit per normal digipeating rules.

Ah, but that is the fundamental error made by systems that try
to make decisins based on what their TNC "hears" on the APRS
channel.  The LACK of having decoded a packet tells one NOTHING
about whether it existed or not.  The APRS channel is COLLISION
limited, and TNC's do NOT detect collisions.  Thus, taking
action on that LACK of being heard is an erroneous process, and
adding another duplicate packet to an already collision limited
channel is exactly the wrong thing to do in this case.

It is ok to monitor the APRS channel with a TNC and to take
POSITIVE action based on what is "heard"  (that is what
digipeaters do) but it is erroneous and dangerous to take ANY
action on what is *not* heard by a TNC.  

Plese, everyone understand.  If your system is half way (RF
wise) between any two other APRS systems, you will NEVER decode
(or detect with a TNC) ANY packets that are a collison between
these two digipeters.  And the Digipeaters are colliding more
often than not.  SO ANY action taken on something NOT heard is
just erroneous.  And if the action taken is to add MORE
duplicates of existing packets, then the net effect on the
overall channel performance is negative.

> Observed behaviour is such that in urban environment 
> it will cut down the packet transmissions by such 
> viscous digipeater by about 90% (80 to 95). 

And the remining 10% could very well be added QRM to the
channel, taking up an extra slot time repeating a packet that
was already digipeated by two other wide area digipeaters that
happen to collide at the location of this viscous digi.

Again, the ONLY way this can work is if a very careful RF survey
of all surrounding digis is conducted and the antenna of this
digi is so designed that it hears EACH other digi with at least
13 or more DB difference so that during any collision, then ONE
digi always wins.  THen this algorimth may have some merit.  But
since by definition ALL OTHER DIGIS are supposed to transmit AT
ONCE, when they are outward propagating a user's packet, by
DEFINITION, all the digis are supposed to collide in that same
time slot.

TO have an additional digi making decisions on what it does NOT
hear in these intended collisions and then injecting additional
copies into the system is just QRM to other users radios that
have been holding off waiting for their chance.

Again, it CAN be made to work, but ONLY when the fill-in digi
can be ASSURED to not be hearing any other digis at anywhere
near equal strength.  And since the result of not making this
indepth RF analysis, is an overall negative on the system, this
technique needs to be wathced very carefully.  In the wrong
hands of plug-n-play operators clueless to the RF environment it
is dangerous.

In my opinion.

Bob, WB4APR

> 
>  
> > --- On Fri, 10/23/09, Robert Bruninga <bruninga at usna.edu>
wrote:
> > 
> > 
> > From: Robert Bruninga <bruninga at usna.edu>
> > Subject: Re: [aprssig] Improving Messaging and dytnamic 
> Object management
> > To: "'Jason KG4WSV'" <kg4wsv at gmail.com>, "'TAPR APRS 
> Mailing List'" <aprssig at tapr.org>
> > Date: Friday, October 23, 2009, 11:50 AM
> > 
> > 
> > > This comment raises a question:  
> > > Why is such aggressive transmitting
> > > (8s/16s/30s/60s = average 30s interval) 
> > > desirable for objects, but aggressive 
> > > smart beaconing for mobiles is anathema?  
> > 
> > Good observation.  Not an anathema at all during an event. 
That
> > is where Smart beaconing is PERFECT...  And that is also an
> > ideal place where the Decay algorithm has the same advantage
for
> > objects.
> > 
> > 1) The original APRS Decay algorithm is required for any
> > meaningful use of objects at an event.  This is so that when
> > anything is moved by an operator, everyone gets the
information
> > very quickly due to the initial 8, 16, and 30  second
retries...
> > but the older objects he moved or situated several minutes
ago
> > are at longer periods to keep the overall load down.
> > 
> > 2) Under the decay method, anything older than about 10
minutes
> > (from the last human intervention) will have decayed down to
the
> > fixed rate of 10 minutes (for a local object (direct)) or to
30
> > minute rate for objects going via 2 hops...
> > 
> > TO be truely useful at any event or situtation, APRS is
supposed
> > to maintain the ENTIRE tactical picture, not just those few
> > vehicles with GPS trackers.  This means tha APRS operators
are
> > supposed to be INPUT OPERATORS, manually inputting and
updating
> > the position of everything of singificance at an event so
that
> > EVERYONE sees the same refreshed tactical situation on their
> > VIRTUAL APRS map displays.  Observers should see everything
of
> > importance, not just the APRS toys.
> > 
> > This can result in dozens or more objects that often change
> > positions frequently.  The Decay algorithm assures that
newly
> > moved objects get to everyone's screen FAST and RELIABLY
> > (initial high rate retries) but then once so delivered, they
> > decay to a lower rate to reduce the overall load on the
channel,
> > while still assuring that newcomers or other stations still
> > eventually get the full picture no matter when they tune in.
> > 
> > *** Smart beaconing does this very well for the event too,
by
> > only transmitting when NEW information is availble (A change
in
> > direction or speed), and not transmitting when things are
not
> > changing...  Smart Beaconing is ideal for this application. 
My
> > only issue with Smart Beaconing has ever been the result of
its
> > dependency on human nature settings that can sometimes be
> > inappropriate during 364 day routine operation at the
expense of
> > others.  TO change the parameters between this special
event,
> > and or routine operations requires human attention to detail
> > which has potential for human error or inadvertant settings
with
> > consequencies for everyon else on the channel until
corrected..
> > 
> > Hope that helps
> > Bob, WB4APR
> > 
> > 
> > 
> > _______________________________________________
> > aprssig mailing list
> > aprssig at tapr.org
> > https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
> > 
> > 
> > 
> >       
> > _______________________________________________
> > aprssig mailing list
> > aprssig at tapr.org
> > https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 