[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