<div dir="ltr"><div>So here are two possible use cases for the APRS constellation:</div><div>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 <a href="http://aprs.fi" target="_blank">aprs.fi</a>. 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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div>On Sat, Feb 25, 2017 at 5:13 AM, Pete Loveall AE5PL Lists <span dir="ltr"><<a href="mailto:hamlists@ametx.com" target="_blank">hamlists@ametx.com</a>></span> wro<wbr>te:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb">> 1. This excludes packets originating from the satellites, which are probably<br>> pretty interesting.<br><br></span><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb">Actually, not. </span></blockquote><div><br></div><div>How does "<span style="font-size:12.8px">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?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">(I think your compromise in your last email is correct in improving on this issue)</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb">And if the satellite programmer wants originated packets to be gated APRS-IS, they can easily have it "digipeated" by the satellite.<br></span></blockquote><div><br></div><div>So the satellite should beacon "SATELLITE>APRS,SATELLITE*:"? I'm not impressed by the elegance of that solution.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb"><br></span><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb">> 2. Whitelists as deployed on I-gates for satellites would always lag behind the<br>> current constellation, and it's likely packets from satellites during their first few<br>> days of bring-up would be the most critical to capture.<br><br></span><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb">No "whitelist" involved in Lynn's suggestion. A satgate exists to gate packets received from satellites to APRS-IS, period.<br></span></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb"><br></span><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb">> 3. Anyone actually trying to use 145.825MHz to do something useful instead of<br>> just a vanity exercise in bouncing a packet off a satellite would rather have<br>> their packets I-gated directly instead of *maybe* getting digipeated through a<br>> satellite but likely lost.<br><br></span><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb">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. </span></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb">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.<br></span></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb"><br></span><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb">> Viscous I-gate has its own problems, but it's a preferable solution to just<br>> dropping any packets heard direct.<br><br></span><span class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-im m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail-HOEnZb">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.</span></blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br clear="all"><div><div class="m_5774811648174990229m_-1423414946589011259m_6256883610725302156gmail_signature">--<br>Kenneth Finnegan, W6KWF<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.c<wbr>om/</a></div></div>
<div class="gmail_quote"><br></div></div></div>