[aprssig] Excess Tx I-gating

Lynn W. Deffenbaugh (Mr) ldeffenb at homeside.to
Thu Jun 15 10:14:05 EDT 2017


I assume you're referring to http://www.aprs-is.net/IGateDetails.aspx 
which allows for

> Gate all packets to RF based on criteria set by the sysop (such as 
> callsign, object name, etc.).

In my APRSISCE/32, I support an APRS-IS-style filter setting where the 
matching packets will be gated from the APRS-IS to local RF. This is 
currently only available in my development version, is not persistent 
(must be re-established on each restart), and is a two-step process.  
The first step is to hit Control-G to specify the filter into a 
"FilterTest" window that I support.  Once that is accomplished, a 
Control-I confirms that the user intends to gate the filtered packets to 
local RF.

My design goal is to keep the filter spec to select the packets to 
forward but to allow multiple filters, make them persistent across 
restarts, and implement a "Leaky Bucket" to throttle the packets flowing 
through each filter and a composite for each RF port.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  My internal filter implementation adds a "+" qualification on a 
term.  Similar to how "-" eliminates packets from passing a filter, my 
"+" requires that the term be matched to pass.  This implements a sort 
of "AND" similar to the "AND NOT" of the minus. Of course, as we all 
know, non-qualified terms are "OR".  For instance:

b/KJ4ERJ-12 +m/10 would only gate my Android phone's packets to RF IF I 
was within 10 km of the IGate.  Without the + modifier, there's no way 
in the standard filters to accomplish this.


On 6/15/2017 10:00 AM, spam8mybrain wrote:
> Greetings, all.
>
> Some time ago, there was a thread discussing what a Tx I-gate should 
> and should not forward to RF. The aprs-is.net website clearly 
> documents the minimum allowed and prohibited traffic, but does not say 
> anything about optional forwarding.
>
> What do other I-gating applications do to control extra 
> I-gate-operator-approved forwarded traffic, and how do you let the 
> control operator specify what extra is allowed?
>
> The reason I ask is that I've gotten some questions about my 
> application YAAC, regarding why it isn't forwarding geographically 
> local Internet-only stations to RF. YAAC presently only supports the 
> minimum forwarding (Internet traffic explicitly addressed to RF-local 
> stations, and one subsequent position report from those specific 
> Internet stations). I'm trying to figure out how to sanely and safely 
> allow operators to specify additional traffic so they can't 
> accidentally specify dumping the entire APRS-IS feed to RF.
>
> Any suggestions or descriptions on how other I-gates do it would be 
> welcome.
>
> Andrew Pavlin, KA2DDO
> author of YAAC
>
>
> _______________________________________________
> 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/20170615/cf59caf8/attachment.html>


More information about the aprssig mailing list