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

[Pete Loveall AE5PL Lists]

> -----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?

Only the RF users local to the receive-only IGates will know for sure because they won't be able to message if, as I pointed out, the receive-only IGate prevents that messaging from occurring.  That is why I mentioned it when you started this thread as it could be a contributing factor to what you were seeing and it would be difficult to isolate.

> I dont think so.
> 
> Looking at the raw packets, I see 6 IGates that hear my 2-2 packets (yes, I
> coiuld drop to 1 hop), but if the local 1 hop IGaqtes are 1 way only, then I just
> shot byself in the foot and dont know it.
> 
> So now the question is, can we ADD IT somehow.

There was an attempt to get everybody to use the gate symbol with an R overlay but that didn't work because people promoted receive-only IGates and that admonition (R overlay) was conveniently dropped out of the conversation :-(.  Even so, instead of promoting receive-only IGates on the general-use APRS frequencies, maybe we should be promoting IGates that only gate to RF messages for stations that are heard directly as you and I discussed earlier in this thread.  This improves communication reliability by removing an unseen hole without increasing QRM on a busy frequency.

> 
> 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.

A better solution is to cease promoting receive-only IGates because there will always be non-compliant software (some authors are dead or no longer supporting their software) and promote direct-only IGates as we discussed in agreement earlier in this thread.  We kill two birds with one stone with that: people new to APRS will see that the best way to implement an IGate is to implement one providing, in essence, hot-spot coverage which would improve messaging reliability in their area and keep them involved with amateur radio, not just acting as a SWL providing an Internet feed.  And those who are already running RO IGates would begin to understand there is a better way to participate and would be inclined to convert to a bidirectional IGate on a non-interfering basis.

> That way I can see on a map WHERE my nearest 2 way gate is when traveling
> and know what I am facing when traveling.

A user of an HT or APRS mobile unit would never know this when traveling until they find they cannot message in a particular area.  A better method is change the IGate operator's thought process to be participatory instead of just providing a feed to the Internet as discussed above.

> I think UIVIEW had a flag about being 2 way?  Others?

Nope.

> Bob, Wb4APR

The thought process is much easier to alter in this case on this group than the entirety of APRS-IS software to try to accommodate a passive portal when an active portal (capable of messaging) is an easier and more apropos solution for amateur radio.  I agree it would be nice to know but, unfortunately, it does not remove the issue that RO IGates break messaging and an RF user would not know until they are in an area covered by an RO IGate and we go through this thread one more time.  Let's agree to promote bidirectional IGates that gate messages to RF only for stations heard directly instead of receive-only IGates in areas where IGate coverage already exists for one or more hops (in essence, a fill-in IGate).  This is similar to the concept of a fill-in digi that only responds to WIDE1-1 and keeps the amateur radio IGate sysop participatory in the local RF network, not just passive.