Order Tray | Contact Us | Home | SIG Lists

[aprssig] Throttleing EchoLink Objects

Michael J. Wolthuis wolthui3 at msu.edu
Thu Jul 23 02:11:42 UTC 2009


I agree the load is an issue.  However, where I would really like this 
info is on my d710 for auto tune.  When I travel the US I have had many 
instances where I don't know the local EchoLink node and so badly want 
to check into one of my nets from another state.  I have drive to find 
Internet terminals if I can't get it on my iPhone just to find the 
nodes.  I have also done the drive and type on the phone to find them 
heheh.....

I liked the idea of being able to know if the node was free, in-use, 
offline, etc....

I do agree this probably should be handled at the local IGATE level.  
However, without the data from the XML parse I can only put out a 
non-informative object for my nodes.  I really like the IRLP script that 
puts out the status, although that has had formatting issues with the 
d710 also that are being worked on. 

There is no way I can see a 10% increase on the APRS-IS as worth it for 
those of us grabbing the full feed still, but if there was a single 
separate server with the data and each IGATE operator (if so desired) 
can connect to there also and grab the live data for his local area with 
a simple filter and put it out with a local path it makes some sense.  
Additionally, if that single server was able to be queried (ie. CQSRV) 
and that returned to the APRS-IS and any IGATE the local object one time 
only I think you have the best of all worlds.

I'm just saying I see both sides.  I love my cellphone and the Internet 
on it, but I also like my d710 and the TUNE button...

Mike
kb8zgl






Steve Dimse wrote:
>
> On Jul 22, 2009, at 9:41 PM, Bob Bruninga wrote:
>
>> ITs not about how people use aprs now.  (Too many trackers, and no 
>> one watching)...  Its all about how we should be using APRS with 
>> displays in the mobiles.
>>
>> And pushing very useful data like Echolink nodes so that any time, 
>> anywhere, I can look at my radio, and make a voice contact to 
>> anywhere on the planet is a powerful tool...
>
> IF (and it is a VERY BIG IF) this scheme automatically and reliably 
> placed the information on every mobile radio, we could discuss the 
> merits. But this proposal does not do that. It places the information 
> on the APRS IS, and depends on hundreds of IGate operators to 
> correctly (and recurrently) update their configuration files. You've 
> been at this long enough to know exactly how that will turn out.
>
> Why not just tell those IGate operators (or any other local RF user) 
> to transmit an RF beacon with the information? Same amount of work, 
> and since it allows any ham, not just the IGate operator, to do it the 
> chance for success is greater. Any increased load on the APRS IS is 
> incidental to increased load on RF, and even that could be minimized 
> by making the beacon RFONLY.
>>
>> Build it and they will come! Bob, WB4APR
>>
> I have a big philosophical difference with your opinion. A 1200 baud 
> ALOHA channel will never be able to carry a significant amount of data 
> from the internet to mobiles. Ten years ago, when no other options 
> existed, trying made sense. Now mobile internet is common, two or 
> three years from now it will be ubiquitous. Why are you still trying 
> desperately to force all information through a tiny straw when there 
> is a huge pipe lying alongside?
>
> The right tool for the right job...
>
> Steve K4HG
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>




More information about the aprssig mailing list