[aprssig] IGate (Identification? (RO or RT)?

[Pete Loveall AE5PL Lists]

As a follow-up to the post below, I have updated the q construct documentation (http://www.aprs-is.net/q.aspx)  to show the qAO construct can be generated by an IGate in addition to by a server.  I have also updated the IGate integral client in javAPRSSrvr to generate the qAO construct instead of the qAR construct if it has RF transmit turned off.  This does not alter server code at all nor does it require any modification to bidirectional IGates.  This solely extends the original intent of the qAO construct of indicating a non-messaging capable IGate to the actual IGate in addition to the server the IGate is attached to.  It also does not alter in any way the operation of APRS-IS and only acts as an indicator of IGate messaging support.

Again, this is not a recommended mode of operation except in special cases such as the when running as a Satgate.  The preferred mode of operation when acting as a fill-in IGate (much like a fill in digipeater) is to operate such that only messages addressed to stations heard directly by the IGate are gated to RF to be as least interfering as possible while fully supporting APRS messaging.

73,

Pete Loveall AE5PL
pete at ae5pl dot net

> -----Original Message-----
> From: Pete Loveall AE5PL Lists via aprssig
> Sent: Saturday, July 16, 2016 7:43 AM
> To: TAPR APRS Mailing List <aprssig at tapr.org>
> Subject: Re: [aprssig] IGate (Identification? (RO or RT)?
> 
> > -----Original Message-----
> > From: aprssig [mailto:aprssig-bounces at tapr.org] On Behalf Of Robert
> Bruninga
> > via aprssig
> > Sent: Friday, July 15, 2016 11:02 PM
> > To: TAPR APRS Mailing List <aprssig at tapr.org>
> > Subject: [aprssig] IGate (Identification? (RO or RT)?
> >
> > Is there a way to see who is one way, and who is 2 way?
> >
> > It would have to be ADDITIVE.  That is, once we come up with the bit (we only
> > need ONE bit somewhere in the QXX construct to indicate it).  Then we can at
> > least see all future 2-way IGates (assuming all existing code is 1 way utnil
> > upgraded).  Is there a way to do this without breaking anything?
> 
> The q construct doesn't have the ability to recognize whether an IGate is RO or
> not because it would require every IGate author to modify their software to
> properly represent the new construct and it would require -every- server to be
> upgraded to support the new construct and handle it separately.  A server
> already has the ability to indicate an IGate is connected to a port that does not
> support bidirectional IGates but this is an indicator of server capability.  This
> was primarily put in place to support Satgates on very bandwidth restricted
> connections including those that would send a gated packet via UDP or HTTP
> which does not allow bidirectional communication (Satgates, by definition, are
> receive-only as the intent is to solely support messaging via the satellites, not
> via APRS-IS).  In theory, a receive-only IGate could use qAO (o not zero) instead
> of qAR for packets gated to APRS-IS if they do not support transmitting to RF
> (receive-only).  Again, this would require IGate authors to rewrite software to
> add this (not going to happen for some software and requires forced upgrades
> of IGate software that is supported).  I will add this to the client-generated list
> in the q construct documentation but I do not expect mass acceptance since a
> large portion of IGate software is no longer supported.