[aprssig] Danger Will Robinson!

Wed Jul 22 17:28:11 EDT 2009

Filter on the ToCall of APELNK if filtering was necessary.  That's, I 
believe, one reason that Bob suggested a new value for that field.

I can be persuaded to change the ToCall to something like KJ4ERJ-EL (I 
solicited good technical reasons), but threatening to torpedo the effort 
by simply filtering it all out and stating that "it won't appear on 
findu" is tantamount to "I'll take my ball and go home".

I understand the concerns, and would like to work with them.  I don't 
see any need to store the object packets themselves, just the current 
state of the station for visibility.  History of moving objects is 
helpful.  Detailed history of stations that MIGHT change their status 
(which I'm not even sure should be included other than on or off and 
then only inject the On objects) within 2 or 3 hours in any given day 
doesn't seem to have any benefit.

My plan was to evenly distribute the packets over 5 of the 10 minutes.  
Distributing them over 60 of the 60 means that the final packet is 60 
minutes old before even being published.  Not really helpful in my 
book.  Distributing them over 15 of the 60 would seem to balance the 
infrastructure load against the staleness of the data.  (I know, I could 
always refresh the status from EchoLink at intervals and report selected 
subsets over time, but I'm looking for simple here).

Lynn (D) - KJ4ERJ - Discussion, rather than threats, promotes progress

Steve Dimse wrote:
> Injection with other hams callsigns in the origin forces me to filter 
> them. If that were corrected and the rate made 1 hour with the packets 
> evenly distributed (one every other second), I'd try it without the 
> filtering to see what happened. As for what gets filtered, I'm not 
> going to implement a list of 2057 callsigns to check against, beside 
> which I would then be filtering people who ARE legitimately on APRS. 
> Yet another argument for putting the correct originating station in 
> the packet!
>
> Steve K4HG
>
> On Jul 22, 2009, at 5:06 PM, Lynn W. Deffenbaugh (Mr) wrote:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>