[aprssig] FW: Echolink objects to APRS

Bob Bruninga bruninga at usna.edu
Tue Jul 21 23:04:31 CDT 2009

> Should EchoLink nodes be objects 
> or items?  

Objects.  Since the central source has real-time status, then these objects are real-time info, and so need the timestamp that Objects provide.

> Here's what one particular EchoLink 
> node would look like in either format:

Consider making it as I describe in the www.aprs.org/localinfo.html format.  There are links there to the APRS frequency Spec that suggests the proper format.

The EL####### should be the object name.
The FREQ and tone should be the first data after the PHG, etc...

The symbol is the "EA" which is a box with an overlay E I think...

Bob, Wb4APR
>;MB7IRD-L *220128z5145.39N/00058.79WrPHG2130 Reading 145.2375 118.8
>)MB7IRD-L!5145.39N/00058.79WrPHG2130 Reading 145.2375 118.8
>This was from the following XML status block (note that the <location> 
>doesn't exactly match the <freq> and <pl>):
><location>Reading 145.2375 118.8</location>
><status_comment>On  @0038</status_comment>
><last_update>07/22/2009 00:38</last_update>
>On looking at this again, I suspect I should put the EchoLink node 
>number in the comment as well.  Right now I'm just pulling the 
><location> value which doesn't help much for offline nodes.  They look 
>like (note the lack of helpfulness in the <location>):
><status_comment>Off @2159</status_comment>
><last_update>07/21/2009 20:56</last_update>
>Finally, should I restrict it to only Online nodes?  And should I build 
>logic to Kill nodes that I notice transitioning from Online to Offline?  
>Or should I differentiate the status with a symbol (the current symbol 
>is /r for an Antenna)?  Or just let the object remain un-updated while 
>Lynn (D) - KJ4ERJ
>Lynn W. Deffenbaugh (Mr) wrote:
>> I'll see what I can do later on today.  Thanks for researching this, 
>> Bob!  Should I make the objects owned by my callsign (KJ4ERJ) or some 
>> other approach?  I'll send direct e-mails once I start thinking about 
>> the object comment and such.
>> Lynn (D) - KJ4ERJ
>> Robert Bruninga wrote:
>>> Well, The echolink objects issue is further clarified below:
>>> Looks like we need an APRS author to go get the EchoLink data
>>> and then inject it into the APRS-IS.  This is a good approach
>>> since it lets us control formatting at one central location.  Do
>>> we have a volunteer?
>>> I got this from the EchoLink folks.
>>> Quote:
>>>> The data collected from the RF Info tab is sent to the central 
>>>> EchoLink servers and displayed in summary form on the Link Status 
>>>> page (http://www.echolink.org/links.jsp). 
>>>> It is also available in XML format at 
>>>> http://www.echolink.org/node_location.xml .   About 50% of the 
>>>> EchoLink "sysop" nodes worldwide have elected to provide this data.  
>>>> It isn't being injected by EchoLink directly into APRS-IS... but 
>>>> someone could certainly do so by pulling down the XML periodically.  
>>> Anyway, so it looks like EchoLink author did his side of the
>>> objective by getting position info, and providing an operator
>>> selection for putting out the data, and all we need is to grab
>>> it and insert it.  Then local Igates add their local EchoLink
>>> object names to the pass-to-RF function and we have achieved the
>>> objective...
>>> That is, open-echolink nodes appearing on APRS for the mobile
>>> operator with Frequencys so that the mobile operator can use
>>> EchoLink easily from anywhere at anytime.
>>> Volunteer?
>>> Bob, WB4APR
>>> _______________________________________________
>>> aprssig mailing list
>>> aprssig at tapr.org
>>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>aprssig mailing list
>aprssig at tapr.org

More information about the aprssig mailing list