[aprssig] IGate FIlter for AMSATS?

[Pete Loveall AE5PL Lists]

See below...

> -----Original Message-----
> From: aprssig [mailto:aprssig-bounces at tapr.org] On Behalf Of Kenneth
> Finnegan
> Sent: Friday, February 24, 2017 9:17 PM
> To: Lynn W. Deffenbaugh (Mr) <ldeffenb at homeside.to>; TAPR APRS Mailing
> List <aprssig at tapr.org>
> Subject: Re: [aprssig] IGate FIlter for AMSATS?
> 
> On Fri, Feb 24, 2017 at 6:21 PM, Lynn W. Deffenbaugh (Mr)
> <ldeffenb at homeside.to <mailto:ldeffenb at homeside.to> > wrote:
> 
> 
> 	Actually, I think the discussion was to implement an IGate mode
> whereby it would never gate a directly received packet, one with no used path
> components.
> 
> 
> And my counter arguments were:
> 1. This excludes packets originating from the satellites, which are probably
> pretty interesting.

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

> 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.

> 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.  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.

> 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 thought the sat guys were going to go set up their own APRS-IS network or
> something.

Not needed if Lynn's recommendation is followed.

> --
> Kenneth Finnegan
> http://blog.thelifeofkenneth.com/ <http://blog.thelifeofkenneth.com/>

73,

Pete Loveall AE5PL
pete at ae5pl dot net