[aprssig] Gating Objects from Internet to RF (fina?l)

[Heikki Hannikainen]

On Wed, 22 Jul 2009, Lynn W. Deffenbaugh (Mr) wrote:

> So, a tactical FromCall with NO visibility as to who actually injected the 
> packet is ok?

In the US it might be legal, over here in Finland it's a bit uncertain, so 
we don't do it. But we only have one echolink station here now, so it 
doesn't really matter now. :)

When using a tactical fromcall, the real callsign needs to be present 
somewhere, like another beacon packet which has the tactical fromcall, and 
the real callsign in the comment field. Someone could even use CWID to 
fulfill the word of the law, although that wouldn't be so nice on the APRS 
channel.

I agree with Bob Bruninga and Steve Dimse - the source callsign should not 
be impersonated. Some people will be greatly annoyed by someone else using 
their callsign, and they will be annoyed at the wrong people (like me, as 
the aprs.fi operator). I would prefer you using your own callsign, so that 
we could gate it on the network here, too, maybe, some day.

I might have to filter this out of aprs.fi, because of the map cluttering 
effects. At least I'll have to provide users a method to filter it out 
from their view, and preferably without removing all other objects. A 
consistent source callsign would probably be the cleanest way to do this 
(unless there is a unique symbol for echolink gateways). Most people 
really look at the APRS map view of the area they live in. After a few 
weeks, everyone will know that there are a few echolink gateways in their 
area, they will have them configured in the memory banks of their radios, 
and they won't want to see them on the map any more. The're mostly 
interested in the stuff that is new or moving, unless they're visiting a 
new area, in which case they want to see the stationary stuff, too.

On the subject of packet rate - may I suggest another approach for the 
flood control. If we would define, that it's OK for an application like 
this to send out one packet per second on the APRS-IS (86400 per day, or 
pick some other number if that's too high or low). You could implement 
your application so that it sends a single packet, sleeps for a second, 
and then sends the next packet from the queue. It could walk the list of 
echolink nodes, and by some algorithm, on every second pick the most 
important node to be announced. It could be the node that was least 
recently announced, or maybe something more complicated. You could have a 
configuration variable "packets_per_second 1.5", and between every packet 
you'd sleep(1/packets_per_second).

This kind of algorithm keeps the load constant and well distributed over 
time, and keeps the load from increasing suddenly if the amount of 
echolink nodes would skyrocket somehow. Please consider that the list of 
nodes might be accidentally or intentionally flooded, spammed, or 
otherwise inflated or corrupted some night. Bugs happen, and it's nice if 
the end results are not too surprising.

That being said, I'm not sure if this is worth doing, Steve's 
APRS-IS-worthiness classification summed it up very well. I'm sure quite a 
few people would greatly appreciate it, but... I don't know.

   - Hessu, OH7LZB