[aprssig] Danger Will Robinson!

[Lynn W. Deffenbaugh (Mr)]

Steve,

I'm only hoping to offer a service that was requested.  I also 
understand the ramifications of it.  I'd really like this information to 
be visible from the various -IS viewing sites like findu.com, aprs.fi, 
and any others that I don't know of.  That's why I was asking about the 
beaconing rate.  I understand that 10 minutes provides good local 
visibility, but if we want to do that, then just get the IGate operators 
to set up their own objects.

However, right now, there's no easy way for them to even SEE what's 
around them to know what objects they might even want to consider.

What would your thoughts be of a 1 hour update rate, with the data 
smoothed over 15 minutes for delivery?  That can at least make the 
objects visible, while possibly not getting an update out to a mobile 
operator driving through a coverage area.

Lynn (D) - KJ4ERJ

PS.  And Steve, it is is your right to filter however you see fit for 
your use.  However, as we go with a consensus on one issue, please don't 
let that decision reflect on me personally nor any other APRS activities 
in which I may be engaged. 

PPS.  Remember, it would be a fairly simple thing for the EchoLink 
author to simply have their software connect to the APRS-IS and inject 
their own packets under their own callsigns at their own rates and you'd 
still have 2,000 new objects arriving at some regular interval.

Steve Dimse wrote:
> OK, if you want to do that, especially in light of the problems I see 
> with the bandwidth, I'll be filtering this from findU. There is simply 
> too much potential for confusion and other issues inherent in sending 
> a packet from 2000 different callsigns every 10 minutes.
>
> Just to be clear, I am withdrawing any support that may have been 
> implied in my previous discussion. I now consider this to be a Very 
> Bad Thing. I started to lean that way when I saw the amount of data, 
> but the fact that it is sent with what are misleading origin calls 
> makes it an easier decision. I urge others concerned about the future 
> of APRS to look carefully at this before it gets started and 
> impossible to turn off!
>
> Steve K4HG
>
> On Jul 22, 2009, at 4:36 PM, Lynn W. Deffenbaugh (Mr) wrote:
>
>> Steve,
>>
>> There was discussion both ways, some people believe it should be both 
>> ways.  There is no technical nor legal reason (on APRS-IS) for one vs 
>> the other, although some mistakenly believed these objects would 
>> somehow conflict with the real station's position.
>>
>> My final decision was based on the following factors:
>>
>> 1) There's no interference for using the station's callsign
>> 2) The ToCall of APELNK will be google-able and define where the 
>> objects are coming from
>> 3) My call will be in the path of the raw packets on the Internet
>> 4) All of the information in the object is controlled by the node's 
>> owner
>> 5) I'm only reformatting data, not authoring anything new
>> 6) All information is already available to the public (EchoLink status)
>>
>> Mike (kb8zgl) put it best at 10:39 today:
>>
>> "It would seem odd to me to see my KB8ZGL-R EL object come from 
>> someone else's callsign. That would bother me more than seeing it 
>> come from my own callsign even though I didn't put it out there."
>>
>> I agree with him wholeheartedly.  I really wouldn't want to see some 
>> other callsign "owning" my EchoLink Nodes object.  I might not like 
>> seeing someone else injecting the object, but at least the object 
>> acknowledges my "ownership".
>>
>> Lynn (D) - KJ4ERJ
>>
>> Steve Dimse wrote:
>>> Maybe I missed something. Didn't everyone agree you should not be 
>>> sending data with other hams callsigns as the origin?
>>>
>>> Steve
>>>
>>> On Jul 22, 2009, at 3:45 PM, Lynn W. Deffenbaugh (Mr) wrote:
>>>
>>>> Curt,
>>>>
>>>> Done.  Check out the current proposed objects at 
>>>> http://ldeffenb.dnsalias.net/EchoLink.txt.  It only uses PHG if the 
>>>> frequency doesn't adhere to the valid ones listed in 
>>>> http://aprs.org/info/freqspec.txt, including the GHz ranges near 
>>>> the bottom of that page.  Any "invalid" frequency will still be 
>>>> included in the status text, but only in its owner-specified 
>>>> format, not in a normalized FREQ object.
>>>>
>>>> Lynn (D) - KJ4ERJ
>>>
>>>
>>> _______________________________________________
>>> 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
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>