[aprssig] IGate FIlter for AMSATS?

[Kenneth Finnegan]

So here are two possible use cases for the APRS constellation:
1. Joe Ham walks outside with his HT and a yagi, points it at a passing
satellite, and fires off a few packets. Maybe he manages to trade some
packets with someone else doing the same thing, or maybe he just runs back
inside to check aprs.fi. In either case he is then gratified that he has
successfully bounced a packet through outer space, and moves on with his
life. He possibly comes back to bounce a few more packets through a
satellite when he wants to impress his friends and family or get credit for
trading packets with a few more people through a satellite.

2. Joe Ham launches an autonomous boat in the Pacific ocean and has it
beacon its current location and telemetry at 30 minute intervals as it
makes its way from California to Hawaii. The team enjoys satellite-based
coverage without having to pay for an Iridium modem and get to involve
amateur radio in the project. Relatively few APRS packets probably get
through during the trip, but once the boat gets within about 30 miles of
the I-gate in Hawaii they start getting nearly all the packets from it to
help coordinate retrieval.

Is this second application not valid for the APRS constellation? Because
every time this argument comes up, everyone says I'm over-thinking it and
being implausible when I argue the packet contents MIGHT sometimes be more
important than what path it took. Are we trying to build a constellation
with utility for field operations here or just an exercise in ham radio on
a satellite novelty?

On Sat, Feb 25, 2017 at 5:13 AM, Pete Loveall AE5PL Lists <
hamlists at ametx.com> wrote:

> > 1. This excludes packets originating from the satellites, which are
> probably
> > pretty interesting.
>
> Actually, not.


How does "an IGate mode whereby it would never gate a directly received
packet, one with no used path components" not exclude a packet with a path
of "SATELLITE>APRS:"? What path does the current APRS satellites beacon
with if it isn't that one?

(I think your compromise in your last email is correct in improving on this
issue)


> And if the satellite programmer wants originated packets to be gated
> APRS-IS, they can easily have it "digipeated" by the satellite.
>

So the satellite should beacon "SATELLITE>APRS,SATELLITE*:"? I'm not
impressed by the elegance of that solution.


>
> > 2. Whitelists as deployed on I-gates for satellites would always lag
> behind the
> > current constellation, and it's likely packets from satellites during
> their first few
> > days of bring-up would be the most critical to capture.
>
> No "whitelist" involved in Lynn's suggestion.  A satgate exists to gate
> packets received from satellites to APRS-IS, period.
>

It wasn't Lynns suggestion (unless he was the one who suggested it last
year). He was recalling an entire thread on this mailing list back in Jan
2016 which included using a whitelist to work around my #1 concern when I
raised it then.


>
> > 3. Anyone actually trying to use 145.825MHz to do something useful
> instead of
> > just a vanity exercise in bouncing a packet off a satellite would rather
> have
> > their packets I-gated directly instead of *maybe* getting digipeated
> through a
> > satellite but likely lost.
>
> See #2.  If you want to use 145.825 for non-satellite use, that is your
> option and you can set up a separate IGate to do just that.


And I'm coming at this from a angle where you just suggested that if I
don't want to use digipeaters for APRS I can go set up a separate I-gate to
do just that. I'm just arguing that there might be cases where the user
cares more about their packet contents getting captured than what
digipeater they bounced through.


> While you consider satellite use as "vanity", it actually is more than
> that but the interface to APRS-IS has always been assumed to be
> receive-only and only what is received from the satellite's digipeater.
>

Then I'm confused. How is this satellite use more than getting vanity
credit for bouncing a packet through a satellite? And is this "getting
credit for a satellite bounce" the only use for the constellation?


>
> > Viscous I-gate has its own problems, but it's a preferable solution to
> just
> > dropping any packets heard direct.
>
> No, it is not preferable.  Delaying packets removes many safeguards built
> into APRS-IS (dupe removal is -not- for bandwidth but for loop prevention
> which, for those of us who have been around for a while, is as big a
> consideration today as it was 15 years ago when APRS-IS couldn't stay
> operational for more than a day).  It also removes the near-real-time
> aspects of APRS which is also critical to its normal, everyday use.


I'm right there with you on viscous I-gating not being a good deal. I think
10 seconds is way too long, and I won't be adding the feature to Aprx
regardless.

--
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/20170225/70807000/attachment.html>