[aprssig] Draft Copy of Thesis on APRS

[David Huff]

"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 choice)."*

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. <
http://www.tapr.org/pipermail/aprssig/2014-May/043331.html>.

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.
Thanks
Dave
w0im



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
> http://www.tapr.org/mailman/listinfo/aprssig
>


-- 
Thanks,
Dave

David.Huff at rockwellcollins.com
CS Reliability, Maintainability, & Safety
319.295.8949
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20141212/9298da0d/attachment.html>