Order Tray | Contact Us | Home | SIG Lists

[aprssig] Curious about bogus packets on Findu

Robert Bruninga bruninga at usna.edu
Thu Sep 30 19:20:03 UTC 2010


APK101 is the TOCALL version number for the radio.
You wont see it except when the radio is sending a message.
Otherwise, for positions, it is the latitude encoded.

Bob 

> -----Original Message-----
> From: aprssig-bounces at tapr.org 
> [mailto:aprssig-bounces at tapr.org] On Behalf Of Keith VE7GDH
> Sent: Thursday, September 30, 2010 1:06 PM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] Curious about bogus packets on Findu
> 
> Steve K9DCI wrote...
> 
> > Noticed some error lat long locations on Findu's Long term
tracking.
> > I've not seen this before. I save some of these images to 
> show with my
> > APRS talks.
> >
> >
www.findu.com/cgi-bin/track.cgi?call=k9dci-9&start=400&geo=usa.g
eo
> 
> > I also see some raw packets with the TOCALL (APK101) instead
of the
> > Mic-e data and don't know enough to understand that.
> >
> > I couldn't see these glitches on aprs.fi.
> 
> from findu.com...
> 
> 20100929191639,
> K9DCI-9>APK101,WIDE1-1,WIDE2-1,qAR,N9XTN
> :'|2y"4K>/]"7w}Delayed 45 minutes
> 
> from aprs.fi...
> 2010-09-29 19:16:39 UTC:
> K9DCI-9>APK101,WIDE1-1,WIDE2-1,qAR,N9XTN
> :'|2y"4K>/]"7w}Delayed 45 minutes [Invalid position ambiguity 
> in mic-e packet]
> 
> They are the same packet. It would appear that findu.com used
> the data and aprs.fi tagged it as having a problem.
> 
> Lynn suggested a digi or iGate using PASSALL turned on. I 
> would consider
> it a possibility if it was a random character that was 
> altered, but a random
> character change wouldn't change the MIC-E "to" field to
APK101. Does
> that make it a Kenwood? Is there any setting in it to tell it 
> to only use valid
> positions from the GPS receiver?
> 
> Also, there were some "high speed" beacons showing on aprs.fi.
I would
> suspect that the device was sending valid positions most of 
> the time, but
> sometimes used invalid positions from the GPS. Again, can the 
> device be
> told to use only valid positions from the GPS? The 
> alternative is that the
> GPS is outputting a valid position (or at least indicating in 
> the $GPRMC
> sentence when it isn't) but that the device is using it 
> anyway... or that it
> sometimes corrupts the data. Just guesswork here... e.g.
> 
> 2010-09-29 18:49:12 UTC:
> K9DCI-9>PP4Y2R,LARC,WIDE2*,qAR,NU0C-15
> :'|R !Rv>/]"8:}Delayed 45 minutes [Location changes too fast 
> (>500 km/h)]
> 
> PS - you are using MIC-E and a responsible two hop path. 
> However, sending
> "Delayed 45 minutes" with every beacon makes it 18 characters 
> longer than it
> needed to be. I know that it's nit picking, but shorter 
> transmissions would yield
> a higher chance of success for you and for others around you. 
> Would it be possible
> to send it as a message or bulletin, or does the Kenwood 
> (D700?) allow you to
> send a beacon comment every X transmissions?
> 
> Ummm... were you using a one minute beacon rate? That's 
> probably OK when
> you are operating in areas with very low APRS usage. If the 
> frequency is busy,
> backing it off to 2-3 minutes might be better. Of course, you 
> could alter the
> beacon rate based on where you were operating.
> 
> 73 es cul - Keith VE7GDH
> --
> "I may be lost, but I know exactly where I am!"
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 




More information about the aprssig mailing list