<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Are you sure it's the digipeater and
not your own reception? If your TNC is in PASSALL (if it has such
a mode) or if you have any overruns or parity errors on the serial
line between the TNC and your system, this behavior can occur.<br>
<br>
It may be happening on other packets, but we typically only look
at our own raw packets.<br>
<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
Win32<br>
<br>
On 10/22/2014 10:12 AM, Andrew P. wrote:<br>
</div>
<blockquote cite="mid:SNT404-EAS1083424748D27F8D8C10FAB8950@phx.gbl"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Greetings, all.
<div><br>
</div>
<div>I just had a weird "feature" with my station. I periodically
run a 2-way I-gate for testing purposes, and found that APRS-IS
was showing mangled copies of my beacon. Turns out the problem
was that I was receiving mangled digipeats of my own beacon over
RF, and, because the packet checksum didn't match, my station
was I-gating the mangled packets immediately after the original
"clean" packet was sent to APRS-IS.</div>
<div><br>
</div>
<div>Unfortunately, the mangling digipeaters didn't have tracing
turned on, so I don't know who was chewing my packets. </div>
<div><br>
</div>
<div>Should my station protect itself from such behavior by not
digipeating or I-gating any traffic whose original sender's
callsign-SSID matches my station's callsign-SSID?</div>
<div><br>
</div>
<div>Andrew, KA2DDO </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="http://www.tapr.org/mailman/listinfo/aprssig">http://www.tapr.org/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<br>
</body>
</html>