<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif;font-size:12.8px">Pete said:</span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif;font-size:12.8px">Accidentally sent this to just Kenneth. My mistake as it was meant to be publicly posted.</span><br></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif;font-size:12.8px"><br></span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif;font-size:12.8px">Pete, I do appreciate your posts, particularly this one. However, I don't think discussing RX-only IGates constitutes encouraging them - I am just trying to figure out how to improve that situation, and mine. If you have any suggestions on how to effectively handle the RF traffic based on the screenshot I just posted, I am all ears.</span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif;font-size:12.8px"><br></span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif;font-size:12.8px">I did turn off my RX-only IGate (except for testing) and I am drilling holes & soldering to build the computer interface to a 2m Transceiver. That is what I am doing to improve APRS messaging locally.</span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif;font-size:12.8px"><br></span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif;font-size:12.8px">Can anyone tell me if the the UDP/HTTP port or the qAO construct is available for use in any client software?</span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif;font-size:12.8px"><br></span></div><div class="gmail_default"><span style="font-size:12.8px">Does the server duplicate checking really happen to a packet before insertion into the connected clients' heard list?</span></div><div class="gmail_default"><span style="font-size:12.8px"><br></span></div><div class="gmail_default"><span style="font-size:12.8px">I am going back to breathing lead fumes, for now.</span></div><div class="gmail_default"><span style="font-size:12.8px"><br></span></div><div class="gmail_default"><span style="font-size:12.8px">.ja.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 20, 2016 at 9:58 AM, Pete Loveall AE5PL Lists <span dir="ltr"><<a href="mailto:hamlists@ametx.com" target="_blank">hamlists@ametx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Accidentally sent this to just Kenneth. My mistake as it was meant to be publicly posted.<br>
<br>
You are correct, Kenneth, as Lynn expressed and I went into greater detail, Jim's suggestion (which is already available via send-only ports such as the UDP and HTTP ports as you describe) achieves NOTHING because he does not understand the premise of an IGate. It was determined from reviewing Bob's packets that he was making it to APRS-IS but that the injecting IGates were either RX-only (what he is asking to encourage here with using UDP & HTTP ports) that NEVER support messaging regardless of port they are attached to or Bob's station was considered outside of the nearest bidirectional IGate's "local" area (it was never determined what that "local" definition was for any of the IGates and I showed that Bob's digipeater "paradigm" makes it very complex to determine number of hops). It was not determined what defined that "local" area for the nearest bidirectional IGates (which we also didn't know which ones were bidirectional) but it had NOTHING to do with the servers that the IGates were connected to.<br>
<br>
Again, a RX-only IGate provides a FALSE sense of coverage as it is INCAPABLE of supporting messaging as APRS messaging requires BIDIRECTIONAL communication which a RX-only IGate CANNOT provide. Yes, in very limited circumstances a RX-only IGate can be beneficial (SATGate, tracking-only alternate network for special events, etc.) but it is not beneficial on the general APRS frequency for general amateur radio use where messaging can be used and is encouraged.<br>
<br>
If Jim wants an IGate to simply show (without actual operational effect as previously discussed) that a received packet is "out of range", that mechanism is in place as is the mechanism for a RX-only IGate to show it is RX-only. That mechanism was added to the Q algorithm by having the client use qAO (letter 'o' not zero) instead of qAR for those gated packets. It was actually there all of the time but the ability for a client to use it was added after the discussion on Bob's thread. Please note, however, that this is only an indicator that most people will never see because they will go to a nice GUI (including their own Internet connected clients) and only see they were tracked, not that a portion of the track did not have messaging coverage. Jim's approach of trying to use different ports, etc. for packets gated to APRS-IS does not accomplish anything other than provide a seldom-seen indicator that a packet was -first- injected by an IGate unable to provide messaging services to that station on RF. Note also that I said "first injected". Because of server dupe checking which is critical to loop prevention, etc., we only see the first packet gated to APRS-IS, not any later packets which might include a bidirectional IGate within range (or an IGate that doesn't show qAO). Use of the qAO construct is not harmful (its purpose has always been to simply show a gated packet without the ability to support messaging but no functional use in the APRS-IS network) but could provide a -clue- to why messaging in an area is not working. BUT, it will also provide many "false positives" since the purpose of many is RX-only IGates is to provide "fill-in" coverage where the RX-only IGate is the first to see the direct packet before a nearby bidirectional IGate sees it via a digipeater.<br>
<br>
If Jim wants to improve messaging between APRS-IS and RF, encourage bidirectional IGates in lieu of RX-only IGates. That will have the most positive effect on inter-network messaging.<br>
<span class="im HOEnZb"><br>
Hope this helps.<br>
<br>
73,<br>
<br>
Pete Loveall AE5PL<br>
pete at ae5pl dot net<br>
<br>
> -----Original Message-----<br>
</span><span class="im HOEnZb">> From: Kenneth Finnegan<br>
> Sent: Sunday, November 20, 2016 2:05 AM<br>
> To: Jim Alles <<a href="mailto:kb3tbx@gmail.com">kb3tbx@gmail.com</a>>; TAPR APRS Mailing List <<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>><br>
> Subject: Re: [aprssig] IGATE message routing bug?<br>
><br>
</span><span class="im HOEnZb">> On Sat, Nov 19, 2016 at 10:43 PM, Jim Alles <<a href="mailto:kb3tbx@gmail.com">kb3tbx@gmail.com</a><br>
</span><span class="im HOEnZb">> <mailto:<a href="mailto:kb3tbx@gmail.com">kb3tbx@gmail.com</a>> > wrote:<br>
><br>
><br>
> On Sat, Nov 19, 2016 at 11:32 PM, Lynn W. Deffenbaugh (Mr)<br>
><br>
> But I don't understand just what you think that "fixes"?<br>
><br>
><br>
><br>
> Bob's original problem - message packets got dropped until after a<br>
> position report was received.<br>
><br>
> Somebody configured something with the limited tools they had., to get<br>
> control of the useless packets that wanted to be transmitted.<br>
><br>
><br>
> Bob's original issue is that there is disagreement between implementations on<br>
> the definition of what stations are "near-by" and which units (km or hops)<br>
> should be used when expressing the concept of near-by. When your RF-gate<br>
> heuristic is "within 50km of me" you HAVE to wait for a position packet before<br>
> starting to RF-gate to a station. If your metric is instead "within one digipeater<br>
> hop of me" you can start providing RF-gate service as soon as you receive any<br>
> type of packet.<br>
><br>
> I don't see how you have changed anything here other than moving when the<br>
> RF-gate decision is made. As it stands now, I-gates send all their traffic to<br>
> 14580 and then get CCed back on all packets that the APRS-IS considers at all<br>
> possibly relevant to that I-gate; the I-gate then processes this feed from the<br>
> APRS-IS to decide which packets to RF-gate (which is very few of them).<br>
><br>
</span><span class="im HOEnZb">> In any case, we're getting lost in the weeds here. Before you start describing<br>
> how us I-gate programmers need to be rewriting our uplink interfaces to the -IS<br>
> and how we should be defining a new NOHERD alias to solve something, you<br>
> need to very clearly describe an existing problem, how the current algorithm<br>
> does not solve this problem, and how your change would improve on it. I still<br>
> have not seen any of your comments line up a real existing issue with a possible<br>
> solution to it.<br>
><br>
> --<br>
> Kenneth Finnegan<br>
> <a href="http://blog.thelifeofkenneth.com/" rel="noreferrer" target="_blank">http://blog.thelifeofkenneth.<wbr>com/</a><br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br>
<a href="http://www.tapr.org/mailman/listinfo/aprssig" rel="noreferrer" target="_blank">http://www.tapr.org/mailman/<wbr>listinfo/aprssig</a><br>
</div></div></blockquote></div><br></div>