[aprssig] Draft Copy of Thesis on APRS

Kenneth Finnegan kennethfinnegan2007 at gmail.com
Sat Dec 13 20:29:31 EST 2014


>Sometimes it would be nice to have a very fast beacon rate for fast
>moving objects

But if the object is moving, its going to be producing different posits and
not trigger the dedup filter. My suggestion for a 30 second dedup window
still supports this.

Kenneth Finnegan
On Dec 13, 2014 5:22 PM, "Tom Hayward" <esarfl at gmail.com> wrote:

> On Sat, Dec 13, 2014 at 4:38 PM, Kenneth Finnegan
> <kennethfinnegan2007 at gmail.com> wrote:
> > 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?
>
> Sometimes it would be nice to have a very fast beacon rate for fast
> moving objects during a special event. It's not a big deal though, so
> out of respect for the network I use longer rates.
>
> An interesting compromise would be to have smart digis that only
> digipeat one of each packet type per dupe cycle. Currently, the source
> + entire payload is dupe-filtered. My idea would be to dupe filter on
> source + type, so only one position, one status, one weather, etc.,
> per station would get through each dupe period, even if the position
> or weather changed. If you want to get really fancy, the digi could
> dynamically modify this dupe period based on ALOHA calculation.
>
> If the digis could filter like this, one guy running a fast rate
> wouldn't impact a wide area. And the people near him would have a more
> accurate location. Kind of like proportional pathing, but enforced at
> a network level. (I already use proportional pathing or short/empty
> paths when I want to beacon fast/often to the local area.) If you
> consider one of the core principles of APRS that local information is
> the most valuable to the user, this seems like a smart way to improve
> performance both locally (accuracy) and wide area (scalability).
>
> Sorry for the tangential brainstorm.
>
> Tom KD7LXL
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20141213/944fde01/attachment.html>


More information about the aprssig mailing list