[aprssig] Gating Objects from Internet to RF (fina?l)

[Wes Johnston, AI4PX]

How do we get these objects out on 2m?  (from the perspective of igate
operator) I certainly don't want to igate all echolink nodes onto my local
lan, and I can't possibly know the number(s) of all the echolink nodes that
may pop up in my vicinity
Wes
---
Hitler gave great speeches too!


On Wed, Jul 22, 2009 at 16:23, Robert Bruninga <bruninga at usna.edu> wrote:

> Lynn,
>
> Great work!
> I have only been trying to get this for the last half dozen
> years or so.
> I have been badgering Jonathan (Echolink author) for years, but
> apparently I had not realized that he had finished his half
> (getting Posit data centralized).   It is so great that you have
> jumped in with the missing link.
>
> > Done.  Check out the current proposed objects at
> > http://ldeffenb.dnsalias.net/EchoLink.txt.
>
> 1) However, I agree with Steve, that you should not use the
> EchoLink callsign as the AX.25 FROM address, since it will
> conflict with that same station's HOME or other APRS station -0
> and violate the principle of ownership or common expectations.
> Besides it will also be wasting space in the APRS radio display
> by having the Echolink callsign in TWO places on the display
> when this is actually a minor bit of info.
>
> I recommend that you make ALL of these objects be originated by
> your callsign... Something like KE4ERJ-EL.  Notice that a non
> 1-15 SSID can be used, since this is being directly injected and
> does not have to go through a TNC.  Then everything works as
> desired, plus we get to see the real source of this data
> KE4ERJ-EL and not some person's call who has no idea how it got
> to APRS.
>
>
> 2) PHG data:
> > It only uses PHG if the frequency doesn't
> > adhere to the valid ones listed in
> > http://aprs.org/info/freqspec.txt...
>
> PHG should not be included in these objects in any case.  As I
> explained before, when displayed on a D700 (the primary target
> screen for these objects) the PHG data will not be parsed, but
> will show up as TEXT "PHGxxxx" pushing the other useful
> information another 8 characters off the screen.  SO do not
> include PHG in any case.
>
> 3)
> > Any "invalid" frequency will still be included in
> > the status text, but only in its owner-specified
> > format, not in a normalized FREQ object.
>
> Actually, I would rather see all non-standard entries DUMPED to
> a NEEDS-FIXING file that we can send to Echolink and get the
> originators to fix the problems at the source.
>
> 4) I see lots of these showing [offline] in the text, yet they
> all show a different % status byte.  And none of the ones listed
> showed the . Offline status?
>
>
> 5) Do you see anything that we need to feedback to the Echolink
> Author as a global change that would help force his users into
> entering correct data?
>
> Thanks
> Bob, WB4APR
>
> >>> The only mod I'd make is that the source
> >>> call be the station's call.
>
> No, as per above.
> Bob
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20090722/b515248d/attachment.htm>