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