[aprssig] IGate FIlter for AMSATS?
Pete Loveall AE5PL Lists
hamlists at ametx.com
Sat Feb 25 08:13:44 EST 2017
> -----Original Message-----
> From: aprssig [mailto:aprssig-bounces at tapr.org] On Behalf Of Kenneth
> 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
> 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
Not needed if Lynn's recommendation is followed.
> Kenneth Finnegan
> http://blog.thelifeofkenneth.com/ <http://blog.thelifeofkenneth.com/>
Pete Loveall AE5PL
pete at ae5pl dot net
More information about the aprssig