Order Tray | Contact Us | Home | SIG Lists

[aprssig] Question about APRS-IS and IS->RF igating

Lee Bengston lee.bengston at gmail.com
Fri May 18 02:18:15 UTC 2012

On Thu, May 17, 2012 at 12:36 PM, Pete Loveall AE5PL Lists
<hamlists at ametx.com> wrote:
> Multiple things occur at the server on filtered ports that are configured to handle IGates (most 14580 ports).  I will focus on this as an IGate connected to a user-filter port with no filter set.
> After initial verified login, the server will only pass messages and associated posits to the client (IGate).

By associated posits, I assume these are the posits of the stations
originating the messages, and if the IGate determines by the standard
rules that it should transmit the message on RF, it also transmits the
"courtesy posit" of the originating station on RF?

> Each station gated to the server by the client (stations heard on RF) are added to a "recently heard" list which is good for about an hour on most servers but is adjustable.  This recently heard list is a moving window list (in other words, every time a station is "heard" from the client, its position on the list is updated).  That list is used for two things: passing messages and associated posits to the client for possible gating to RF AND passing any packets heard from recently heard list stations that were injected directly on APRS-IS (TCPIP* as the path).  This is so the IGate can determine if there is a station it is hearing on RF is also directly connected to APRS-IS.  If the RF station is heard directly on APRS-IS, the IGate should NOT gate messages for that station to RF.

This is great information - I have wondered in the past why with no
filter set the server would send posits to the client of nearby
stations that had beaconed directly via TCP/IP.  I'm not going to
mention any names - I figure the authors know what their software does
- but are other programs out there that will blindly transmit whatever
the APRS-IS server sends.  One of those will not do that if you put a
message-only filter on the RF outgoing side, but the documentation
doesn't seem to advise that the user should do that in order to
realize the expected behavior.

> Sounds like your APRS4R software is buggy and not following the specifications for IGates at www.aprs-is.net if it is gating everything heard on the APRS-IS feed to RF.

Unfortunately I have found that there are very few IGate programs that
have implemented all of the functionality specified there  At least
there are a few that have.


Lee - K5DAT

More information about the aprssig mailing list