[aprssig] Cleaning up the Global APRS Satellite ground station network?- New Symbol

[Kenneth Finnegan]

On Mon, Aug 7, 2017 at 10:21 PM, Robert Bruninga <bruninga at usna.edu> wrote:

> >> If we bgine using #J overlays for APRS-IS satelite ground stations,
>> what conflicts will arise?
>>
>
>
>> > I can only repeat things I have said before about other proposals to
>> identify function based on symbols.
>>
>> > 1. Each station only gets one symbol. If a station has more than one
>> function it has no choice but to not send one of the symbols, and it takes
>> away the personalization option that has always been attractive to hams
>> participating in APRS.
>>
>> I'd say each Radio only gets one symbol, and these permanent gound
> station radios listening on 145.825 as satellite grouind stations are only
> doing a single function. And they are not on 144.39 where their other
> station symbols might be.
>

What if they're a university station with only an omni? What if they're
non-optimum sky view on the UHF downlink? I think Steve's complaint is that
you're trying to encode three different things in the symbol overlay. If
we're going to come up with a way to encode all of this information for
"various" sat-gates anyways, why not only use that and let the symbol be
used for something else?


>
>
>> > 2. You will never get great compliance with anything that is
>> user-configurable, especially if it involves station identity. Even if #1
>> were not a problem there will always be people that will not do it
>> correctly.
>>
>
> But no reason not to have a standard for those that want to make it an
> identifiable network.
>

I thought the satellite guys were going to set up their own APRS-IS network
with different dedup semantics so they could get their vanity satellite
bounce online even if they were near another sat-gate. What ever happened
to that project?  Attaching to a specific set of APRS-IS servers seems like
a much more effective way to filter the network than to try and pattern
match stations by *any* metric suggested.


>
>
>> > 3. Even if 1 and 2 aren't a problem, you only get those who intend to
>> be satellite gates, not those who actually meet equipment, performance, and
>> configuration requirements.
>>
>
> Thats exaclty what we want.  We want them to self identify and there are
> multiple overlays so each Satgate station can identiy their category and so
> one-size does not have to fit all.
>

But self-identification has proven to be of low quality. I think Steve is
suggesting that we should be coming up with more robust ways to identify
stations than them setting certain symbols, which they have every right to
do for any other APRS application since we never told them *not* to use
these symbols for anything else.


>
>> It is easy to identify those people who function as satellite gateways
>> using the path of packets. Creating a database from the actual data will
>> catch those who actually function as satgates without needing any extra
>> compliance from the operators.
>>
>
> Yes, but two problems.  First you need a symbol to be able to do an easy
> sort-by-symbol map which is usually the first-order view of APRS
> information. You cannot sort a map based on the QAR construct. And second
> not all of the 330 stations that actually IGated are the permanet core
> satgatges we are interested in.  See below.
>

But all the I-gates which were set to 145.825 for a pass and their symbol
changed to "S&", then changed back to 144.390 are core sat-gates which
we're interested in? The "S&" special event I-gates that someone set up and
then forgot about are sat-gates we're interested in?

What problem are we trying to solve that isn't better fixed by someone
curating a list of known good sat-gates? We think there's only a few dozen
of them, so it wouldn't even be that much effort.

What value are we offering to current sat-gate operators to encourage them
to go dig into their sat-gate configs to change their symbol from the
satellite dish to an abstract black diamond with some letter on top of it?

--
Kenneth Finnegan, W6KWF
http://blog.thelifeofkenneth.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20170807/fefebc12/attachment.html>