[aprssig] IGate Registering for ANSRVR (Messaging failures)

Robert Bruninga bruninga at usna.edu
Fri Jul 15 13:06:55 EDT 2016

Thanks Steve!
I'm so glad I remember it the same way.

And this also now explains why I have had ABYSIMAL messaging success when I
travel with an old D7 and send a message or two.  Since the D7 does not have
an internal GPS, and since when I am sitting in an airport I have little
info on a manual position, I rarely take the time to estimate one.

But if the local IGate will not send my APRS-IS acks and recepients
responses back without a position, then this goes a LONG way in explaining
why it has appeared that messaging is so broke!

But I would change your rememberence by one...

> n was to be adjusted to match the number of hops
> the outgoing message would be sent with.

I think the default IGATE-back-to-RF path should always be 1 hop (or less)
and no more (without a warning).  Because as soon as anything in APRS goes
more than one hop, it is no longer "local" but becomes regional.  And it is
easy to negotiate local IGATe performance locally (usually local clubs), but
impossible to negotiate IGate coverages regionally with "strangers"... going
out 2 hops in all directions.

Also, 2 hops is so  unreliable in desne areas, it adds little to
communications reliability  and gives a false sense of connedctivity..


-----Original Message-----
From: aprssig [mailto:aprssig-bounces at tapr.org] On Behalf Of Steve Dimse via
Sent: Friday, July 15, 2016 12:02 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] IGate Registering for ANSRVR (Messaging failures)

> On Jul 15, 2016, at 11:12 AM, Lynn W. Deffenbaugh (Mr) via aprssig
> <aprssig at tapr.org> wrote:
> PS.  If anyone can speak authoritatively on what criteria the other IGate
> software uses for gating messages from the APRS-IS to RF, I'd be all
> ears... er eyes and would love to be corrected or confirmed in my
> recollection that one of them can consider distance rather than used hops.
The intent very definitely was as Bob stated, it should be based on what the
IGate hears as local, local being defined as heard in n or fewer hops in the
last y minutes. n was to be adjusted to match the number of hops the
outgoing message would be sent with. e.g if the TNC sends via WIDE,WIDE, n
should be 2; if it uses VIA WIDE then n=1. y should be a few times greater
than the longest beacon interval, say 120 minutes but this is not that

I do not recall ever hearing about someone defining local as a distance, and
if I had I would think I would remember. This is a bad idea. A hop may be 20
miles as in the Florida Keys, or 100 miles or more for a mountaintop digi.
And if it is a wide coverage it is very likely not omnidirectional, so even
with thought you could not program a single realistic distance to call

I don't think I'd go as far as Bob to say this ruins the utility of
messaging, but it does make it less reliable while adding no improvement
that I can think of. Anyone doing this in their code should reconsider.

Steve K4HG
aprssig mailing list
aprssig at tapr.org

More information about the aprssig mailing list