<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 5/17/2012 11:43 AM, Phil N6TCT wrote:
<blockquote
cite="mid:9EAB4299-FDB7-4179-8434-1D19F8870864@lapsley.org"
type="cite"><br>
<div>
<div>We have a bidirectional igate, GERLCH, out in the Nevada
desert. It's running aprs4r under linux.</div>
<div><br>
</div>
<br>
<div>My question: Why would our igate be getting this message
from APRS-IS? Is it because we just gated a message to
APRS-IS from this station? <br>
</div>
</div>
</blockquote>
<br>
Yes, in my experience, if a station gates a packet from RF to -IS,
the upstream APRS-IS server seems to put some sort of dynamic buddy
filter on that station ID and all packets originating from that
station, that were NOT gated via your gate, come from the APRS-IS
back to your station. I always expected this for messages, and
maybe one posit after any given message (and an ack is just a
message), but my KJ4ERJ-1 IGate keeps hearing packets from mobiles
via the APRS-IS that have long since driven out of reception range
of my gate.<br>
<br>
<blockquote
cite="mid:9EAB4299-FDB7-4179-8434-1D19F8870864@lapsley.org"
type="cite">
<div>
<div>If so, that seems weird to me. I.e., if I just gated a
packet from him, presumably I'm in RF range of him, so why
would I need or want APRS-IS to hand me a packet *from* him?
(If the packet was a message addressed to him, *that* I could
see…)</div>
</div>
</blockquote>
<br>
After any message packet, the next posit is expected to be gated as
"free" information to the message destination station of the
location of the message source station.<br>
<br>
<blockquote
cite="mid:9EAB4299-FDB7-4179-8434-1D19F8870864@lapsley.org"
type="cite">
<div>
<div><br>
</div>
<div>Relatedly, is there any automated, algorithmic way that our
igate should be able to spot this and say, nah, we don't want
to gate this?</div>
</div>
</blockquote>
<br>
Actually, that's what I was going to ask. Is aprsr4 just blindly
gating everything received from the APRS-IS feed out to the local RF
channel? I thought IGates were supposed to have LOCAL intelligence
as to which packets to gate from -IS to RF and not just rely on the
upstream -IS server to only deliver gate-ready packets.<br>
<br>
<blockquote
cite="mid:9EAB4299-FDB7-4179-8434-1D19F8870864@lapsley.org"
type="cite">
<div>
<div><br>
</div>
<div>Thanks for any light you can shed on this!</div>
</div>
</blockquote>
<br>
Not sure if I shed any light, but I certainly share your opinion
that gating <IGATE packets from -IS to RF is non-helpful. But
I'm not sure it's the APRS-IS server's job to make that
determination and believe that work lies with the IGate software,
aprsd in your case.<br>
<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br>
<br>
PS. BTW, APRSIS32 runs fine under Wine and won't exhibit this
behavior. And it's configurable -IS to RF capabilities are set to
be upgraded over the next 2-3 months.<br>
<br>
<blockquote
cite="mid:9EAB4299-FDB7-4179-8434-1D19F8870864@lapsley.org"
type="cite">
<div>
<div><br>
</div>
<div>73,</div>
<div><br>
</div>
<div>Phil, N6TCT</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<br>
</body>
</html>