Re: NoGateME - Why?


K5DAT
 

I must be missing something.  Why would an IGate not beacon both on RF and Internet - in other words, why beacon on RF only and thus rely on gating yourself after a digipeat in order for those packets to get to the Internet?

Regarding the "No Gate ME" option, I like the idea of turning that on while beaconing on both RF and IS - I always thought an IGate gating its own digipeated packets for the dupe filters to throw out was kind of dumb, anyway.

Regards,
Lee - K5DAT



On Wed, Sep 25, 2013 at 5:03 AM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
 

(Wiki fodder follows)

The latest DEV release includes a feature to allow configuring an RF
port with "No Gate ME". Why would this be necessary? Well, I've
learned something new (yet again) about the APRS-IS server behaviors.
Here's my original question to Pete, AE5PL, and his subsequent answer:

> I'm trying to understand how a packet gated from RF to the -IS had its
> RFpath,qAR,KJ4ERJ-1 replaced with TCPIP*,qAC,KJ4ERJ-5 before being
> propagated using the q algorithm fromhttp://www.aprs-
> is.net/qalgorithm.aspx KJ4ERJ-1 was the source of the packet as well as the
> IGate of the packet and the verified login to the javAPRSSrvr server which is
> running as KJ4ERJ-5.
>
> The situation is that an IGate is transmitting beacons only via RF. A
> digipeated copy of that packet is received by the same IGate and is gated to
> the APRS-IS with the qAR construct. But when the packet propagates
> through the -IS, the fact that it was received via RF has been replaced with a
> qAC construct.
>
> Note: this example is from my own KJ4ERJ-1 IGate, but the real world issue
> that I'm tracking down is an operator beaconing via the ISS (RF-Only) and
> gating the received digipeat of his own packet which is exhibiting the same
> behavior. This is why Mark, MM1MPB is copied on this message.

Pete's answer:

> That is because an IGate is not supposed to pass its own packets to APRS-IS as gated packets without passing them directly to the upstream server. It has nothing to do with the q algorithm and everything to do with server operation.

> This is done before any q algorithm operation because there are clients out there that couldn't figure out how to place a TCPIP* as the only thing in the path. Pain in the butt but that is how it works to compensate for noncompliant clients.

So, if you're transmitting packets on RF only (type disabled on the
APRS-IS port), and you hear your own packet digipeated back and gate it
to the APRS-IS, that packet will not show the RF received path, but will
only show TCPIP*,qAC, making it appear to have been directly
injected to the APRS-IS. This obviously is non-desired behavior for
satellite operations.

With the new "No Gate ME" option on the RF port, APRSISCE/32 will not
pass received copies of it's own packets back to the APRS-IS allowing
remote IGates the opportunity to gate the packet preserving the received
RF path.

Note that this does not change the fact that the APRS-IS is decidedly
NOT a good vehicle for doing APRS RF coverage analysis because the dupe
filters are still in place. Only the first copy of any packet is
propagated and all other copies are summarily discarded as unnecessary
duplicates, even if received via different RF paths and/or different IGates.

Also, please note Pete's follow-up warning if you do decide to use "No
Gate ME":

> Absolutely use the login for the client's callsign, whether it is an IGate or not! The q algorithm depends on it! What you don't do is only originate packets to RF. The reason you don't do that is you break how an IGate regulates who it gates messages to on RF. It is important that an IGate always send all -originated- packets to APRS-IS. RF is the part that is optional.

So, if you're using "No Gate ME", don't expect APRS-IS-side messaging to
function correctly with remote IGates. If you're trying to be an
RF-only station with an -IS connection, you better understand ALL of the
ramifications of that operating style. You MAY be introducing more QRM
on the RF channel because remote IGates will not be aware of your
-IS-conneccted status and may be gating messages from -IS to RF for your
station because the remote IGate will believe you're on RF only and will
be "helping".

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


Join APRSISCE@groups.io to automatically receive all group messages.