[aprssig] Throttleing EchoLink Objects
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Wed Jul 22 21:54:49 CDT 2009
Steve Dimse wrote:
> On Jul 22, 2009, at 10:15 PM, Lynn W. Deffenbaugh (Mr) wrote:
>> Actually, there is a difference here. When an EchoLink node dies,
>> the APRS-IS feed will automatically quit sending the objects and it
>> won't matter that the IGate operator is configured to get them to RF,
>> they'll just quit.
> Let's back up. Are we agreed the point here is to get the beacon to
> RF? If so, do you understand that in order for something on the APRS
> IS to be gated to RF, the IGate operator MUST manually enter the
> callsign of the blessed station or object?
Almost, I want to see the EchoLink nodes on BOTH platforms. RF for the
mobile or non-Internet connected user, and -IS interleaved with the
remainder of the APRS landscape for trip planning in advance. I know
the data is available elsewhere, but I would like to see it integrated
in one view.
> So if I add a new echolink node, it will not appear on RF until the
> local IGate operator finds out about it, and manually edits his
> configuration file.
Agreed, unless we can dream up some other way of getting them out, say a
trusted object source (ECHOLINK or KJ4ERJ-EL) and a local range filter
configured ONCE when the IGate operator authorizes the gating.
> Yes, you are right that if we choose not to clutter the APRS IS, the
> data will not reflect the changing status of the node, but with
> proposals for updates once every 10 minutes or 1 hour, it is not
> exactly like we are talking about real time information.
I'm still not enamored of trying to reflect the realtime status
(Available, Busy, Conference) in the object. I think we'd be ok with
just Online and completely suppressed for Offline. If we included the
ABC status (+-= in the current proposal), that's a bonus but a snapshot
of the status at the time of beaconing.
> Only for an IGate running javAPRServ. I run a very old version of that
> program on findU, perhaps the new versions are capable of being
> IGates, I'm sure Pete will help me out on this. Even if it is capable,
> the majority of IGates are client programs like WinAPRS and UIView, or
> aprsd. These require the operator to manually configure the blessed
> station list. Nothing javAPRServ could do would control the output of
> these IGates.
Yes, javAPRSserv does IGating. That's what I'm running so I'm guilty of
the carpenter syndrome. I've got a hammer so everything looks like a
nail. Does anyone have any statistics on the IGate software
> This is not a bug. An IGate operator is responsible for everything
> sent out on its transmitter, to pass off automatic control is not
> something I would ever want to see!
Unless it is as I described above. In order to do messaging, we have to
gate from Internet to RF. If we put our licenses at risk, so be it.
I'll take mine down if I ever hear of an FCC action against an IGate
operator for passing through third party traffic. (No, I do NOT want to
open that can of worms discussion right now either!) :)
We agree on a lot of points, and disagree on some. That's the best way
to arrive at a better solution that addresses, but may not completely
satisfy, everyones needs.
Lynn (D) - KJ4ERJ
More information about the aprssig