[aprssig] Compromise WinLink object proposal
A.J. Farmer (AJ3U)
ajfarmer at spenet.com
Tue Feb 15 14:50:27 CST 2005
I agree with Steve. And to add to the argument, I would guess (and hope)
that most IGate operators know what is going on in their local area so
gating the explicit calls should not be a big deal.
As part of the Winlink, Echolink, IRLP, etc. documentation, I would make
sense to state something like, "Once you have set up your node's APRS-IS
status reporting, contact a local APRS Igate operator in your area and
request that they gate your node information from the APRS-IS to local RF so
that it becomes visible to APRS users". Just an idea.
A.J. Farmer, AJ3U
From: aprssig-bounces at lists.tapr.org [mailto:aprssig-bounces at lists.tapr.org]
On Behalf Of Steve Dimse
Sent: Tuesday, February 15, 2005 3:34 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] Compromise WinLink object proposal
On 2/15/05 at 12:04 PM Bill Vodall <wa7nwp at jnos.org> sent:
>Gating by explicit call won't work. Too much trouble when stations
>are continuously coming and going.
I disagree. First, forget about "and going"...if a station goes, it stops
sending packets to the APRS IS, and therefore to the RF network, stations
leaving take care of themselves, they can be removed at any time, or never
removed without causing problems. To be clear, you don't need to edit them
when people turn their systems on and off, that is the whole point behind
these beacons, when the node is on, its packets are on the APRS IS, and when
station is off, no packets appear on the APRS IS.
Second, how many of these nodes are expected to be in the range of any given
IGate? With 500 registered in the country and fewer active, five or ten
reasonable maximum number. Those 500 happened over a period of years, it
like they add a hundred a day. So maybe an IGate operator would need to edit
their IGate call file two or three times a year on average, more in big
less in small towns.
To me, that seems like a small price to pay to protect local RF users, and
importantly to prevent the negative attitude that might prevent other
systems from being accepted on the APRS stream in the future.
aprssig mailing list
aprssig at lists.tapr.org
More information about the aprssig