[aprssig] Q: Vicious digipeater

Matti Aarnio oh2mqk at sral.fi
Fri Oct 23 20:17:47 EDT 2009


On Fri, Oct 23, 2009 at 03:04:15PM -0700, Steve Noskowicz wrote:
> Would someone try explaining this concept again? 
>   It was done a couple of weeks ago, but I didn't understand the reasoning.

How about spelling it right at first?

 Viscous.
  –adjective
    1. 	of a glutinous nature or consistency; sticky; thick; adhesive.
    2. 	having the property of viscosity.

 Vicious
  –adjective
    1. 	addicted to or characterized by vice; grossly immoral; depraved; profligate: a vicious life.
    2. 	given or readily disposed to evil: a vicious criminal.
    3. 	reprehensible; blameworthy; wrong: a vicious deception.
    4. 	spiteful; malicious: vicious gossip; a vicious attack.
    5. 	unpleasantly severe: a vicious headache. 
  ......


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.

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). 

Btw: I did not invent this, but apparently I was first to implement and measure it.

> -- 73, Steve, K9DCI
> http://k9dci.home.comcast.net/

  73 de Matti, OH2MQK

 
> --- 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





More information about the aprssig mailing list