<p dir="ltr">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 network load. </p>
<p dir="ltr">Viscous delay is relatively controversial. I haven't been able to even convince myself that it is definitely a good thing. </p>
<p dir="ltr">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?</p>
<p dir="ltr">Kenneth Finnegan, W6KWF</p>
<div class="gmail_quote">On Dec 12, 2014 8:51 AM, "David Huff" <<a href="mailto:david.huff@rockwellcollins.com">david.huff@rockwellcollins.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>"6.3 Deduplication Behavior</div><div>As the APRS network grew and the density of digipeaters and stations increased in the late</div><div>1990s and early 2000s, it became increasingly important that digipeaters don't \ping-pong"</div><div>packets between themselves.</div><div>To prevent this, a new behavior was implemented in digipeaters where an "aging hash table" was used to store a hash of each</div><div>packet for a limited length of time <i>(this period is never formally specif ed, so the author suggests 30 seconds be used as it is a popular choice)."</i></div><div><br></div><div>I was under the impression the deduplication hash was specified as recommended 4-8 seconds in APRX <<a href="http://wiki.ham.fi/Viscous_APRS_Digipeater" target="_blank">http://wiki.ham.fi/Viscous_APRS_Digipeater</a>>, and determined by DWAIT in other digipeaters. <<a href="http://www.tapr.org/pipermail/aprssig/2014-May/043331.html" target="_blank">http://www.tapr.org/pipermail/aprssig/2014-May/043331.html</a>>. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>Thanks</div><div>Dave</div><div>w0im</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 10, 2014 at 11:14 AM, Curt Mills <span dir="ltr"><<a href="mailto:curt.we7u@gmail.com" target="_blank">curt.we7u@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Morse code ID: I mentioned that because it is legal to do so, not<br>
because it would be recommended. You could also do an ID to no path,<br>
which would also be legal.<br>
<br>
!DAO! extension: It isn't implemented by a lot of packages. We<br>
haven't implemented it in Xastir yet.<br>
<br>
The nice thing about the SS aliases is that you can flood a state with<br>
alerts intended just for that state. Weather and Amber Alerts would<br>
be two good instances.<br>
<br>
As far as Version 2.0 versus 2.2 of the spec: Most of the TNC<br>
implementations (not talking about APRS trackers) were done prior to<br>
that, so only support 2.0. I seem to remember that there were both<br>
digipeater limits and changes to the flags in the new spec, which were<br>
hotly debated after it came out (on the lists), and most chose to not<br>
support 2.2 at the time. So then most of the new tracker<br>
implementations only supported 2.0 after that as well.<br>
<br>
Regarding the APRS spec again: Version 1.0 was ratified. Addendum<br>
1.1 was ratified (which consists of a bunch of web pages, a difficult<br>
thing to get my head around WRT a spec). Addendum 1.2 was not<br>
ratified as far as I know, but there are several things in there that<br>
have been implemented by later versions of APRS software. So... To<br>
get your head around the entire spec, you need 1.0, 1.1, and maybe at<br>
least parts of 1.2. I think the addendums address a few of the<br>
concerns in your paper. !DAO! was in the addendums I think, so I'm<br>
sure you've considered them.<br>
<br>
Good luck Friday! Excellent paper by the way!<br>
<div><div><br>
--<br>
Curt, WE7U<br>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org" target="_blank">aprssig@tapr.org</a><br>
<a href="http://www.tapr.org/mailman/listinfo/aprssig" target="_blank">http://www.tapr.org/mailman/listinfo/aprssig</a><br>
</div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div>Thanks,</div><div>Dave</div><div><br></div><div><a href="mailto:David.Huff@rockwellcollins.com" target="_blank">David.Huff@rockwellcollins.com</a></div><div>CS Reliability, Maintainability, & Safety</div><div><a href="tel:319.295.8949" value="+13192958949" target="_blank">319.295.8949</a></div></div></div>
</div>
<br>_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br>
<a href="http://www.tapr.org/mailman/listinfo/aprssig" target="_blank">http://www.tapr.org/mailman/listinfo/aprssig</a><br>
<br></blockquote></div>