[aprssig] Gating Objects from Internet to RF (Really Final?)

[Lynn W. Deffenbaugh (Mr)]

Robert Bruninga wrote:
> 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.
>   
See my detailed response to Steve on this issue.  Unless someone can 
come up with a good technical reason for not using the station's call, 
I'm going with it.  Your suggestion of the redundancy would only have me 
REMOVE the call from the status text because (as you said) this is a 
minor bit of info and I'd rather get the node's description in there if 
possible.
> 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.
>   
I'm loath to use a non 1-15 SSID as the fromcall.  I know it is 
technically possible, but it can restrict others from possibly gating 
the packet directly to the RF rather that providing a full 3rd party 
packet wrapper which would be necessary for the -EL SSID suggested.
> 2) PHG data:
>   
> 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.
>   
I'll disagree on this one.  If the FREQ isn't valid, all bets are off on 
"reasonable" displays.  I'd rather get the PHG visible on APRS-IS since 
the FREQ isn't usable on the mobile anyway.
> 3) 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.
>   
I would also, but I'm also realistic enough to know that the owner is 
not likely to even notice our dump to fix it.  I'd rather get the 
information out there for all available nodes, "properly" configured or 
not.  The readable text will be humanly interpretable making the node at 
least visible and usable.  If I dump it, no one is likely to ever know 
(especially possible users).

> 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?
>   
Yes, if you look at the raw XML from 
http://www.echolink.org/node_location.xml and search for [offline], you 
will eventually find a record like the one below.  The <location> 
(status) is [offline], but the <status> is N and the <status_comment> is 
On...  Go figure.

<station>
<call>9A3COL-R</call>
<location>[offline]</location>
<node>416247</node>
<lat>43.521300</lat>
<lon>16.457700</lon>
<freq>145.400</freq>
<pl>0</pl>
<power>9</power>
<haat>10</haat>
<gain>0</gain>
<directivity>0</directivity>
<status>N</status>
<status_comment>On  @1106</status_comment>
<last_update>07/12/2009 11:06</last_update>
</station>

> 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?
>   
About the only thing I can think of is to somehow make sure that the 
frequency they enter is in MHz.  That would resolve the bogus FREQ.  
Also, if you scan my list for R00m (zero range?), there's a bunch of 
stations with a zero power setting.  Other than that, the data is much 
cleaner than most user-entered data that I've ever used.

Lynn (D) - KJ4ERJ