[aprssig] EchoLink and other Local Info - Future?

[Stephen H. Smith]

Robert Bruninga wrote:
>>
>> As far as this EchoLink objects project, we have arrived at a
>> show-stopper (traffic load).  To me, that simply offers a
>> challenge.  I see two possible approaches?:
>>
>> 1) A widget that runs in parallel with a local Igate, but that
>> can share the TNC.  It gets the Echolink status periodically
>> just for the local object, and then it beaons that object ONLY
>> to its own path (independent of the Igate's path).
>>
>> 2) An upgrade to the APRS-IS that provides regional feeds, so
>> that Lynn's engine can inject only regional info into regional
>> feeds.
>>
>>     

Again, if you can bend the ear of Echolink's developer, this issue can 
be solved very easily:

      Support for the AGW Packet Engine in Echolink's APRS reporting 
module.  


Currently, Echolink supports the RF announcing mode either by:

1)   Using a dedicated radio & TNC

2)   Communicating directly with UIview and "piggybacking" on the radio 
and TNC UIview is controlling.

Unfortunately, the linkage only works with UIview if it is running in 
the classic TNC command interface mode.   You can't run UIview in the 
KISS mode (where it must operate to function as a digipeater and igate). 

The AGW Packet Engine is far far more than just a soundcard "software 
TNC".  It is a sophisticated data distributer that can share serial 
streams from up to 16 hardware or software TNCs with a nearly unlimited 
number of packet-data-using applications.  It can separate the VHF and 
HF data streams received on a single physical serial port from a KAM to 
multiple data streams on multiple logical ports. 

It interfaces to physical (hardware) TNCs on serial ports via a KISS 
interface A pull-down list box provides explicit support for every 
flavor of Kantronics, AEA/TIMEwave, TNC2 and Paccom devices, along with 
a number of TNCs only widely offered in Europe, and of course sound 
cards.  It can deliver these outputs either via Windows DDE (dynamic 
data exchange) to programs on the same PC, or via TCP/IP to either local 
or distant PCs.

Digital types can think of AGWpe as a kind of "router" or "switch" for 
KISS serial data.  Analog types can liken it to a "distribution amp" for 
serial ports. 

Note that each application talking back to the AGWpe interface uses it's 
own callsign, SSID and most importantly PATH. For example, UIview might 
be beaconing on a WIDE1-1 path, Echolink could be beaconing on a 
direct-only path, and UI Events beaconing on a one-hop path of a 
specific digi's eplicit callsign -- all on the same radio/TNC setup!



If Echolink would join the ranks of applications that support the AGWpe 
DDE interface, it could effortlessly share TNCs  --ALREADY BEING USED--  
by UIview, APRSplus, WinAPRS, AGW Tracker, UI Events, UI Traffic 
Manager, WinPack, APRS Emergency, etc.     

Or for non-APRS Echolink operators operating on UHF, AGWpe operating in 
the sound card TNC mode would let you recycle any old 2M radio on 144.39 
for local APRS status beacons with no TNC at all required.  



------------------------------------------------------------------------

--

Stephen H. Smith    wa8lmf (at) aol.com
EchoLink Node:      WA8LMF  or 14400    [Think bottom of the 2M band]
Skype:        WA8LMF
Home Page:          http://wa8lmf.net

JavAPRS Filter Port 14580 Guide
  http://wa8lmf.net/aprs/JAVaprsFilters.htm

"APRS 101"  Explanation of APRS Path Selection & Digipeating
  http://wa8lmf.net/DigiPaths

Updated "Rev H" APRS            http://wa8lmf.net/aprs
Symbols Set for UI-View,
UIpoint and APRSplus:




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20090723/1152c8c2/attachment.html>