[aprssig] local messaging

[Pete Loveall AE5PL Lists]

This was to be public.  Hitting reply defaults to original sender :-(

See below...

> -----Original Message-----
> From: Jim Alles
> Sent: Monday, November 21, 2016 4:44 AM
> To: TAPR APRS Mailing List <aprssig at tapr.org>
> Subject: [aprssig] local messaging
> 
> So, back to Bob's collision with reality:
> 
> APRS-IS behavior that does not recognize an APRS station (in the IGate/APRS-IS
> system) unless and ONLY IF it sends a valid position report.  This is not how
> APRS messaging is supposed to work.  There should not be any dependence on
> a position report for 2-way messaging to work.

Incorrect.  APRS-IS behavior (this is the network, not individual IGate software) recognizes all APRS packets and a server does not discriminate between posits and non-posit packets when updating its "last heard" list for a client (IGate) connected to a restricted feed port.  The second part of your statement is opinion regarding individual IGate operation and does not necessarily apply to all IGates or all IGate software as previously discussed.

> But wait, (I presently am trying figure this one out - help -really!)
> 
> 1.	My IGate transmits direct, no path. and can cover most of Happy Valley
> (maybe - not tested). It can't reach Interstate-80 to the north.
> 2.	My IGate transmits with PATH WIDE2-1 and I hit 4-5 High Profile Digis
> (HPDs) all at once, reaching I-80 and more, but being in earshot of all of them,
> we get collisions in the valley - wasted bandwidth locally w/ no benefit.
> 3.	My IGate transmits with PATH W3YA-1 <http://aprs.fi/info/a/W3YA-1>
> our closest high-profile digi @ 650' HAAT The packet hits I-80, and we get a
> second clean, strong copy in the valley
> 
> To me, it looks like #3 is The Right Thing To Do.

Collisions do not "waste" bandwidth but could cause your IGate to be unreliable in Happy Valley if those digipeaters really do have almost the exact same coverage.  Another method if you want to go more than one hop or cover better in all directions is to increase #3 by adding WIDE2-1 to your IGate's path (this will get to all wide area digipeaters in "earshot" of W3YA-1 for a single repeat causing collisions but not necessarily in those digipeaters' areas of coverage) or by adding a specific wide area digipeater if you only want to go further in a single direction.

> What do I limit my transmit decision to? It has to be no more distance than
> what W3YA-1 can reach. I figure 50-60 miles in my case. I would reduce that to
> 40 if I can realize a plan for a second IGate 50 miles south, in farmland.
> 
> That means I need to ignore anything that wants to be transmitted beyond that
> transmit coverage..
> 
> How do I decide that, without waiting to get a station's position beacon?
> Number of hops (1) isn't helpful, because I can hear the other HPDs.

Now this is the dilemma that has to be dealt with if you use the premise that posits have to be ignored and only hops make a difference.  As Steve pointed out, using hops was easy when the concept was first used: we didn't have all the iterations of the WIDEn-n concept nor did we have all of the different implementations of the WIDEn-n concept (as I pointed out).  Software I have written to act as an IGate gives the IGate sysop the ability to define "don't IGate" digipeaters (if my packet isn't going through that digipeater or that digipeater has a local IGate, don't gate for stations heard through that digipeater) but that relies on the implementation of callsign insertion/replacement in the WIDEn-n algorithm and not everyone has implemented that.  And I suspect that very few people using my software have actually tried to tune their IGate settings.

> Can I know if it was Digi-peated once from direct to W3YA-1, from the path?
> does that help? is it reliable? I still might not know that the station is in transmit
> range of W3YA-1?

Yes, that can help if it adheres to the callsign replacement/insertion criteria.  But your software must support it.

> IGates are store and forward mechanisms. Could we ask something else if it
> knows where a station is, if we heard it, got a message for it, but don't yet
> know whether it is worth chewing up the channel slot?

While physically there is a brief moment that an IGate stores a packet before gating, it is not considered a "store and forward" device.  It does not store a packet for later processing just as an APRS server does not store a packet for later processing.  It is critical to the infrastructure of APRS-IS and APRS on RF that packets be transmitted as soon as possible if they are to be transmitted and not stored for later processing.  Also, APRS is a broadcast protocol which relies on everyone having access to all packets.  There is no communication mechanism between stations to say "should I transmit this packet or will you?"

> 
> .ja.

As you have discovered, we have multiple problems with the "hop only" concept of gating to RF in today's environment.  While straightforward in the early days of APRS, the WIDEn-n paradigm along with the multiple variations of digipeater implementations combined with the use of WIDE2-1 as a replacement for WIDE (since WIDE1-1 is a replacement for RELAY) makes hop counting difficult at best and will likely always generate "false positives".  However, a "false positive" is likely better than not transmitting at all since the amount of message traffic will normally be a very small portion of your RF bandwidth so erring on the side of gating a message to RF is preferred.  Also, many IGate authors do not give a lot of flexibility or (with older software no longer maintained) do not take into account today's WIDEn-n usage.  So, again, err on the side of gating a message to RF to improve messaging reliability.  All of this relies on your IGate sending all packets it sees upstream to the server.

Hope this helps.

73,

Pete Loveall AE5PL
pete at ae5pl dot net