<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Yep, there's a bunch of trashy packets out on the APRS-IS. My
suggestion: if it doesn't look good, ignore it. If it originated
from a good packet, it either was just processed in the correct form
or it'll come again, hopefully not corrupted.<br>
<br>
When in doubt, check the originating station's raw packets at
aprs.fi and see if Hessu sees the same thing and what his parser
complains about.<br>
<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br>
<br>
On 11/28/2011 1:14 PM, Andrew P. wrote:
<blockquote cite="mid:BLU156-W19CC0F090FEDDFA583462DB8B20@phx.gbl"
type="cite">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
<div dir="ltr">
Greetings, all.<br>
<br>
I've been looking at APRS messages I've been receiving, and
noticing an alarming tendency towards mangled messages. It can't
be just from my software not keeping up with the serial data
stream, because I'm getting this on APRS-IS server connections
(which, by their nature as TCP/IP connections, can't drop bytes
in mid-stream). So, is there that great a frequency of garbled
packets out there being forwarded by I-gates, or do we just have
sloppy software (or sloppy manual data entry) putting garbaged
messages out there? Here's some examples:<br>
<br>
KA1GJU-3>APN382,UNCAN,WIDE2*,qAR,W1CLA-1:!!06
0F02@000-,-----(--,-- 02035 00000"7<br>
<br>
WV9E>APW249,KC9DGP-10,N9MEA-6,K9ABC-1,WIDE3*,qAR,N9MXT-10:_113P0414c11s000g(00t032r000p0<0P000h30b09930wRS� <br>
<br>
$GPRMC,11,A,4458.2127,N,08720.8152,W,0.000,0.0,120,2.2, W <br>
<br>
WA9KJE-1>APU25N,WA9+JI,AB9FX-1,K9MOT-15*,qAR,<a class="moz-txt-link-abbreviated" href="mailto:N9MXT-10:@28163z4159.74N/08741.51W_22">N9MXT-10:@28163z4159.74N/08741.51W_22</a>�.<00�100t040r000P000p000h87b10173/WX
Chicago-Peet2100-All Sensors Nominal<br>
<br>
DB0DLG-1>APNU19,WIDE2-2,qAS,DB3MA-2:!4830.78N10102�222<br>
<br>
AB9FX-1>APNW01,KA9SCF-15,K9SA*,WIDE2,qAR,N9MXT-10:/2;1412z4156.52NT08745.66W&PHG4180
wx3in1 A=650�<br>
<br>
WX0U-1>APN382,K0SUN-13,ETULSA,CLRWTR,WIDE3*,qAR,AC0JK-5:;HAMEXAM03*111111/3824.90N\09610.88W<br>
<br>
KY2O-4>APTT4,K4AG-6,W4NVU-4,WIDE2*,WIDE2-1,qAS,N9LCK-10:!2505.77N/08026 51W-Key
Largo Fill+in Digi<br>
<br>
OE6PWE-11>APRSOE,TRACE3-3,qAS,OE6XLR-10:!4734.11N/014�4.5<br>
<br>
G6UIM>APWW08,TCPP*,OZ1AHV-2*,qAR,OZ1AHV-2:;G3TQ/6
*11115026.94N/00334.92Wr050.750MHz T077 1.5M GB3TQ PAIGTON
G0AZX!w+G!<br>
<br>
<br>
Any suggestions for dealing with such packets would be
appreciated.<br>
<br>
Andrew Pavlin, KA2DDO<br>
</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>