[aprssig] Draft Copy of Thesis on APRS
kennethfinnegan2007 at gmail.com
Sat Dec 13 19:38:07 EST 2014
Viscous delay digipeating is a very different concept than the APRS dedup
behavior. If you set the dedup timer to be 4-6 seconds, and there happens
to be any viscous digis on the network, it would disastrously double the
Viscous delay is relatively controversial. I haven't been able to even
convince myself that it is definitely a good thing.
I don't follow the argument for why you would want to allow identical
packets through the network more often than every 30 seconds. What's the
advantage of allowing repeated packets every 6 seconds on RF?
Kenneth Finnegan, W6KWF
On Dec 12, 2014 8:51 AM, "David Huff" <david.huff at rockwellcollins.com>
> "6.3 Deduplication Behavior
> As the APRS network grew and the density of digipeaters and stations
> increased in the late
> 1990s and early 2000s, it became increasingly important that digipeaters
> don't \ping-pong"
> packets between themselves.
> To prevent this, a new behavior was implemented in digipeaters where an
> "aging hash table" was used to store a hash of each
> packet for a limited length of time *(this period is never formally
> specif ed, so the author suggests 30 seconds be used as it is a popular
> I was under the impression the deduplication hash was specified as
> recommended 4-8 seconds in APRX <
> http://wiki.ham.fi/Viscous_APRS_Digipeater>, and determined by DWAIT in
> other digipeaters. <
> The 30 seconds here might be too long for RF. The APRS-IS (internet)
> folks also have a duplication filter in the APRS-IS system that is about 30
> seconds. I suggest you split the RF deduplication filter from the APRS-IS
> (internet) deduplication filter. Section 6 is still mostly RF based ideas,
> therefore 30 seconds sounds high for RF.
> We have had many digipeaters store a position for too long before
> repeating it, which causes your position to "jump back and forth" as an
> example. the internet duplication check should be separated from RF.
> On Wed, Dec 10, 2014 at 11:14 AM, Curt Mills <curt.we7u at gmail.com> wrote:
>> Morse code ID: I mentioned that because it is legal to do so, not
>> because it would be recommended. You could also do an ID to no path,
>> which would also be legal.
>> !DAO! extension: It isn't implemented by a lot of packages. We
>> haven't implemented it in Xastir yet.
>> The nice thing about the SS aliases is that you can flood a state with
>> alerts intended just for that state. Weather and Amber Alerts would
>> be two good instances.
>> As far as Version 2.0 versus 2.2 of the spec: Most of the TNC
>> implementations (not talking about APRS trackers) were done prior to
>> that, so only support 2.0. I seem to remember that there were both
>> digipeater limits and changes to the flags in the new spec, which were
>> hotly debated after it came out (on the lists), and most chose to not
>> support 2.2 at the time. So then most of the new tracker
>> implementations only supported 2.0 after that as well.
>> Regarding the APRS spec again: Version 1.0 was ratified. Addendum
>> 1.1 was ratified (which consists of a bunch of web pages, a difficult
>> thing to get my head around WRT a spec). Addendum 1.2 was not
>> ratified as far as I know, but there are several things in there that
>> have been implemented by later versions of APRS software. So... To
>> get your head around the entire spec, you need 1.0, 1.1, and maybe at
>> least parts of 1.2. I think the addendums address a few of the
>> concerns in your paper. !DAO! was in the addendums I think, so I'm
>> sure you've considered them.
>> Good luck Friday! Excellent paper by the way!
>> Curt, WE7U
>> aprssig mailing list
>> aprssig at tapr.org
> David.Huff at rockwellcollins.com
> CS Reliability, Maintainability, & Safety
> aprssig mailing list
> aprssig at tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig