Order Tray | Contact Us | Home | SIG Lists

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

Robert Bruninga bruninga at usna.edu
Wed Jul 22 20:23:34 UTC 2009


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




More information about the aprssig mailing list