[aprssig] FW: Echolink objects to APRS
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Wed Jul 22 06:49:45 CDT 2009
Looking good so far. I hadn't read that particular spec page yet. I'm
getting more and more tempted to start working on an APRS2xx.pdf file
that pulls ALL of these things together in one place....
Why no PHG spec for these frequency objects? I know the spec says they
have "little value" in APRS-IS, but I use aprs.fi to map out trips and
see what Digi, IGate, and Repeater coverage I can expect on my travels.
Without the PHG, I can't get any range circles. Or do the DXXX displays
not suppress the PHG and it messes up the alignment? Although I do see
your comment "The FREQ and tone should be the first data after the PHG,
etc...", the echo-irlp-win.txt file doesn't mention it.
Although I'm not an expert on javAPRSsrvr configuration (and don't even
run UI-View or xastir), I'm only familiar with gating a source callsign
selectively from Internet to RF. I don't know that it's possible to
gate an Object ID to RF individually. I'll post separately to these two
groups, but I think it may be prudent to use the nodes call (minus the L
or R) as the source call. They'll all be gated by my callsign, so
they'll still be traceable back to me. I can move the L or R into the
Updated sample objects coming soon for final comments.
Lynn (D) - KJ4ERJ
Bob Bruninga wrote:
>> 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.
>>>>> 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
>>>> 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.
>>>> Bob, WB4APR
>>>> aprssig mailing list
>>>> aprssig at tapr.org
>>> aprssig mailing list
>>> aprssig at tapr.org
>> aprssig mailing list
>> aprssig at tapr.org
> aprssig mailing list
> aprssig at tapr.org
More information about the aprssig