[aprssig] Why Not "Gate in Vicinity"
Steve Noskowicz
noskosteve at yahoo.com
Fri Dec 23 17:03:38 EST 2011
--- Lynn W. Deffenbaugh (Mr) wrote:
> On 12/23/2011 10:37 AM, that Steve Noskowicz wrote:
> > It seems to me that having something
> similar to the 30 second RF-RF non duplicate repeat
> restriction added for IS to RF beacons ...
>
> Maybe I just don't call it what you do, but what exactly is
> "the 30 second RF-RF non duplicate repeat
> restriction"? And where do you think such a
> restriction is implemented?
Lynn,
Could be. Perhaps it's some hold-off or such. I just know about it.
I'll elaborate a bit...
I believe it is standard setup for a digi to *not* repeat (RF>RF) an identical packet if received within 30 seconds of the previous (I think to prevent flooding the channel). While testing a setup, you can't bang away forcing packets willi-nilly and see them all digipeated. If I understand correctly, this is only for idential beacons, i.e. stopped in one place.
Now, I don't think this concept is so simple. Perhaps this proposed IS->RF gating restriction would apply to either identical or 'similar beacons' from a single client or may include other types of packets if identical. I don't know.
Since VE4HTO-14 was still moving and popping beacon posits like machine-gun fire, they won't obviously be identical. However, an interval of 1-5 seconds can't be reasonable for any situation that I can imagine. So the initial concept is inhibiting any _posit/beacon_ from an IS deviceif it was received within 5, 10, 15... seconds of the previous one.
Now, I realize this looks like a band-aid to fix one problem and it could be, but it may help in other situations if it is agreed that rapid fire packets are not useful/desired in general.
That's the concept to start.
So hope that explains it better. Give me the correct term and I'll be smarter. I also don't know the capabilities of Digi sw to do something like this.
--
73, Steve, K9DCI
More information about the aprssig
mailing list