Reply and questions interspersed below...
On 6/16/2020 3:05 PM, Justin Cherington wrote:
This is true 'nuff.
IS to RF gated packets use the same path that you have configured
for the IGate's beacons. So, whatever you have in Configure /
Beacon / Path... is the path that will be used on the 3rd party
packet gated from IS to RF. The theory is that the path will be
set to something reasonable for your RF environment and that same
environment is where you're injecting the gated packets.
What "filter" are you setting to 20 miles? There is no distance filter that affects IS to RF gating. It is strictly based on "recently" heard "local" where recent defaults to heard in the past 30 minutes and local means no more than 2 used hops in the "closest" received path from a station. And these are hard-coded and not (yet) user-settable.
That said, you can affect the definition of "used" hops by
setting appropriate aliases in Configure / Aliases / Known. If
SSn-N aliases are in use in your area, or any other aliases for
that matter, you should have them listed in there so they are not
counted as "used", but only the true digipeaters inserting used in
the path are counted.
Set an appropriate path for your IGate based on your local RF environment and you shouldn't be generating QRM. Unless, of course, you're messing around with the Control-G / Control-I filtered gating of all matching APRS-IS packets to the local RF. Someone was doing that in New Jersey and I got called out for "pushing" my lightning packets from firenet to their RF!
Note that you do not need any special filter to gate messages from APRS-IS to RF for recently heard local stations. That is automatically an IGate function in APRSIS32 with the default Port settings for any instance with an RF and -IS port active.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and