What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

APRS says my RV-7 is doing >500 km/h !

DakotaHawk

DakotaHawk

Well Known Member
I was looking at my APRS raw data for my flight last weekend from Arlington, WA to Provo, UT to Portland, OR and return to Arlington, WA.
2010-06-27 22:43:39 UTC: N957RV-7>TUUVSV,KOPEAK*,WIDE2,qAR,AC7YY-12:`2M0,\-'/"JZ}KD5FBX RV-7
2010-06-27 22:45:08 UTC: N957RV-7>TVPPQY,WIDE2-1,qAR,W7GC-13:`2K5,4-'/"JV}KD5FBX RV-7
2010-06-27 22:46:38 UTC: N957RV-7>TVPTQY,WIDE2-1,qAR,W7GC-13:`2I~+z('/"Ja}KD5FBX RV-7
2010-06-27 22:48:07 UTC: N957RV-7>TVPXRU,WIDE2-1,qAS,W7HDO:`2HR,z+'/"JI}KD5FBX RV-7
2010-06-27 22:49:36 UTC: N957RV-7>TVQRSQ,WIDE2-1,qAS,W7HDO:`2Fl->/'/"JR}KD5FBX RV-7
2010-06-27 22:50:08 UTC: N957RV-7>TVPXRU,PACKWD,WIDE2*,qAS,KJ7XE-11:`2HR,z+'/"JI}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 22:51:06 UTC: N957RV-7>TVQVTT,KOPEAK*,WIDE2,qAR,W7AUW:`2E*. ''/"Ib}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 22:52:35 UTC: N957RV-7>TVRPXV,WIDE2-1,qAS,W7HDO:`2D<0x1c>. &'/"I,}KD5FBX RV-7
2010-06-27 22:53:42 UTC: N957RV-7>TVQVTT,PACKWD,WIDE2*,qAS,KJ7XE-11:`2E*. ''/"Ib}KD5FBX RV-7
2010-06-27 22:54:05 UTC: N957RV-7>TVRUQT,WIDE2-1,qAS,W7HDO:`2B},f$'/"Hi}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 22:55:27 UTC: N957RV-7>TVRUQT,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`2B},f$'/"Hi}KD5FBX RV-7
2010-06-27 22:57:03 UTC: N957RV-7>TVSSVX,WIDE2-1,qAR,AC7YY-12:`2A_.\$'/"G4}KD5FBX RV-7
2010-06-27 22:58:34 UTC: N957RV-7>TVSXQT,WIDE2-1,qAR,AC7YY-12:`2@C.>('/"Dy}KD5FBX RV-7
2010-06-27 23:00:02 UTC: N957RV-7>TVTRRU,WIDE2-1,qAR,AC7YY-12:`2=\,z4'/"C8}KD5FBX RV-7
2010-06-27 23:03:01 UTC: N957RV-7>TVTYVT,WIDE2-1,qAR,AC7YY-12:`27p- :'/"CF}KD5FBX RV-7
2010-06-27 23:04:31 UTC: N957RV-7>TVUSQS,WIDE2-1,qAS,W7HDO:`244-pE'/"C/}KD5FBX RV-7
2010-06-27 23:04:45 UTC: N957RV-7>TVTYVT,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`27p- :'/"CF}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:06:01 UTC: N957RV-7>TVUVVS,W7PFR-1,WIDE2*,qAR,AC7YY-12:`20[-H='/"C-}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:06:26 UTC: N957RV-7>TVUSQS,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`244-pE'/"C/}KD5FBX RV-7
2010-06-27 23:08:30 UTC: N957RV-7>TVUVVS,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`20[-H='/"C-}KD5FBX RV-7
2010-06-27 23:08:59 UTC: N957RV-7>TWPSYU,WIDE2-1,qAR,N7JGX-10:`2)h-z<'/"CA}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:10:30 UTC: N957RV-7>TWPXPP,WIDE2-1,qAR,N7JGX-10:`2'H-H)'/"C\}KD5FBX RV-7
2010-06-27 23:11:26 UTC: N957RV-7>TWPSYU,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`2)h-z<'/"CA}KD5FBX RV-7
2010-06-27 23:11:58 UTC: N957RV-7>TWQRRP,WIDE2-1,qAR,K9JEB-2:`2&(-p('/"CO}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:14:39 UTC: N957RV-7>TWQRRP,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`2&(-p('/"CO}KD5FBX RV-7
2010-06-27 23:16:27 UTC: N957RV-7>TWRTXR,BALDI*,qAR,N7JGX-10:`2](-p+'/"CT}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:17:56 UTC: N957RV-7>TWRYPX,WIDE2-1,qAR,K9JEB-2:`2[>-f)'/"C'}KD5FBX RV-7
2010-06-27 23:19:25 UTC: N957RV-7>TWSSTR,WIDE2-1,qAR,K9JEB-2:`2Z%-f&'/"Ba}KD5FBX RV-7
2010-06-27 23:20:55 UTC: N957RV-7>TWSWWR,WIDE2-1,qAR,K9JEB-2:`2Xx-4&'/"C?}KD5FBX RV-7
2010-06-27 23:21:32 UTC: N957RV-7>TWSWWR,WIDE2-1,qAo,WE7U-3:`2Xx-4&'/"C?}KD5FBX RV-7
2010-06-27 23:22:25 UTC: N957RV-7>TWTQYQ,WIDE2-1,qAR,K9JEB-2:`2X<0x1d>-UN'/"C8}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:23:08 UTC: N957RV-7>TWSWWR,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`2Xx-4&'/"C?}KD5FBX RV-7
2010-06-27 23:23:41 UTC: N957RV-7>TWTQYQ,VE7SFU-10,WIDE2*,qAS,VE7BSM-1:`2X<0x1d>-UN'/"C8}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:23:54 UTC: N957RV-7>TWTVQY,WIDE2-1,qAR,N7JGX-10:`2Y_-_K'/"A7}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:24:27 UTC: N957RV-7>TWTQYQ,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`2X<0x1d>-UN'/"C8}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:26:53 UTC: N957RV-7>TWUTVY,WIDE2-1,qAR,N7JGX-10:`2Z7,AH'/"@7}KD5FBX RV-7
2010-06-27 23:27:13 UTC: N957RV-7>TWTVQY,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`2Y_-_K'/"A7}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:28:22 UTC: N957RV-7>TWUXQV,WIDE2-1,qAR,KD7ZYW-1:`2]E,}/'/"?9}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:29:02 UTC: N957RV-7>TWUTVY,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`2Z7,AH'/"@7}KD5FBX RV-7
2010-06-27 23:29:52 UTC: N957RV-7>TXPQSU,WIDE2-1,qAR,KD7ZYW-1:`2aH,_4'/">z}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:30:09 UTC: N957RV-7>TWUXQV,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`2]E,}/'/"?9}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:31:21 UTC: N957RV-7>TXPTXV,WIDE2-1,qAR,KD7ZYW-1:`2(v-_7'/"={}KD5FBX RV-7
2010-06-27 23:32:17 UTC: N957RV-7>TXPWRS,N7RIG-5*,qAR,SEDRO:`2*^,UV'/"<H}KD5FBX RV-7
2010-06-27 23:32:24 UTC: N957RV-7>TXPQSU,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`2aH,_4'/">z}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:32:29 UTC: N957RV-7>TXPWXR,WIDE2-1,qAR,SEDRO:`2*D+*<'/";n}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:32:46 UTC: N957RV-7>TXPXRR,N7RIG-5*,qAR,SEDRO:`2)`)f\'/":4}KD5FBX RV-7
2010-06-27 23:33:15 UTC: N957RV-7>TXPTXV,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`2(v-_7'/"={}KD5FBX RV-7 [Duplicate position packet]
2010-06-27 23:33:41 UTC: N957RV-7>TXPXTU,WIDE2-1,qAR,N7JGX-10:`2'<0x1c>&fz'/"6o}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
2010-06-27 23:34:25 UTC: N957RV-7>TXPWXR,W7PFR-1,WIDE2*,qAS,KJ7XE-11:`2*D+*<'/";n}KD5FBX RV-7
2010-06-27 23:34:33 UTC: N957RV-7>TXPXWS,WIDE2-1,qAR,N7JGX-10:`2a=s}W'/"5g}KD5FBX RV-7 [Location changes too fast (>500 km/h)]
Click to expand...

Each of the line items with
[Location changes too fast (>500 km/h)]
Click to expand...
were not accepted or plotted due to my excessive speed:D! That's almost half of the data stream rejected!

Any suggestions on how to slow my plane down so more of my packets are acceptable?:confused:

Man, I love these FAST planes!
 
All kidding aside...

Yeah, I know it's a software issue. I just want to find a way to get more data points accepted.

I really don't think slowing down is going to change anything.
 
Scott, I have seen a lot of that too, on some of my tracks.

I'm speculating here, but I think it is due either to problems with ground stations decoding your MIC-E, or with the ensuing computation of your speed based on ground station clock time and your APRS packet's position data. (MIC-E doesn't send timestamps, so time has to get associated with your APRS packets by ground stations at some point and my understanding is that APRS doesn't do that very well.) Our airplanes are traveling close enough to 500km/h that a sloppy calculation of distance, or some bad clock jitter, might put it over the edge. Much slower ground vehicles might never show this problem.

But on the other hand I've seen much worse... I have aprs.fi tracks with positions that have the longitude sign bit flipped, so my track goes from northern Oregon to central China and back within 3 track points :). For some reason that didn't get filtered due to excessive speed! I think that must be due to data corruption, maybe just bad MIC-E decoding.

I'm thinking I'll try sending plain text data, with my own GPS-generated timestamps, instead of MIC-E to see if that helps. I know, more bandwidth, etc., but I'm curious if it would make a difference.

--Paul
 
Garage Guy said:
Scott, I have seen a lot of that too, on some of my tracks.

I'm speculating here, but I think it is due either to problems with ground stations decoding your MIC-E, or with the ensuing computation of your speed based on ground station clock time and your APRS packet's position data. (MIC-E doesn't send timestamps, so time has to get associated with your APRS packets by ground stations at some point and my understanding is that APRS doesn't do that very well.) Our airplanes are traveling close enough to 500km/h that a sloppy calculation of distance, or some bad clock jitter, might put it over the edge. Much slower ground vehicles might never show this problem.

But on the other hand I've seen much worse... I have aprs.fi tracks with positions that have the longitude sign bit flipped, so my track goes from northern Oregon to central China and back within 3 track points :). For some reason that didn't get filtered due to excessive speed! I think that must be due to data corruption, maybe just bad MIC-E decoding.

I'm thinking I'll try sending plain text data, with my own GPS-generated timestamps, instead of MIC-E to see if that helps. I know, more bandwidth, etc., but I'm curious if it would make a difference.

--Paul
Click to expand...

Based on my experience I think Paul summed up the situation very well. Scott, there isn't anything wrong with your tracker, just ground station errors.

Here is a blog entry by the aprs server owner that gives some background about tracking errors:

http://oh7lzb.blogspot.com/2008/03/on-duplicate-and-delayed-packets.html
 
Great article

Sam,

That article really explained my problem. Summing it up - it's the ground stations receiving my APRS signal that are causing the corruption to my data.

It's because the ground stations are jealous because they're moving so slooooowwww.....;)
 
DakotaHawk said:
Sam,

That article really explained my problem. Summing it up - it's the ground stations receiving my APRS signal that are causing the corruption to my data.

It's because the ground stations are jealous because they're moving so slooooowwww.....;)
Click to expand...

It's interesting that the aprs.fi software does not presently look at tracker-generated timestamps. Consequently, adding timestamps to our packets won't help the situation.

Fortunately, the duplicate/error problem isn't bad enough to compromise the usefulness of our trackers, just means some packets will be dropped. But there are a few ground stations out there that could use some software tweaking.
 
You must log in or register to reply here.
Back
Top