GPS accuracy

[spatsch]

Hi,

I am trying to use the GPS data logged at 1/4 second intervals. However, when I compute the speed vector from the GPS lat/long and pressure alt data I get an interesting pattern (all values in feet per 250ms):

DELTA ALT,DELTA VECTOR LENGTH,TAS VECTOR,DELTA DELTA VECTOR LENGTH
-4,58.748377341881,64.9806795971661,-56.7867709288435
-6,55.7496810421258,65.1072653366411,-2.99869629975515
-4,55.6098680150781,65.3182415690994,-0.139813027047737
-4,115.562574527155,65.4026320620828,59.9527065120773
-3,57.0051754551388,65.4870225550661,-58.5573990720166
-3,58.6868392381878,65.4026320620828,1.68166378304905
-2,53.7186432974605,65.0650700901494,-4.96819594072737
0,117.218303771432,64.6431176252328,63.499660473972
0,56.9249082870942,64.5587271322494,-60.2933954843383
0,56.924649512794,64.5165318857578,-0.000258774300178288
0,55.4624126365609,64.3055556532995,-1.46223687623306
1,110.595450612246,64.1789699138244,55.1330379756852

the first column is altitude change between measurement, the second is the GPS/PALT based computed speed vector, the third the speed vector based on TAS and the last the delta in the computed speed vector.

As the computed speed vector and TAS seem to match pretty well (considering wind) over a one second average the computed speed vector seems to underestimate movement for 3 measurements (750ms) and then catches up at the 4th measurement. Those values are clearly a measurement issue (would require a +-7G load every second if they were real which I think I would have noticed  )

Any idea what's causing that inaccuracy?

Thanks

Oliver
p.s. GPS fix quality is 2 with 10 satellites.

 

[swatson999]

I'd suspect the GPS data is *computed* at 1 Hz, while the log is at 4 Hz. Something like that.

I'd be mildly surprised if the PVT solution from GPS is at a higher rate than 1/s...

 

[dynonsupport]

What GPS are you using?

The Dynon GPS-250 is a true 5Hz GPS with a position and velocity calculation 5 times a second. However, this clearly will not fit well into a 4 Hz data output, so there's going to be some jumping as one of the 4Hz blocks will have two updates inside it. You can see this in the GPS time in the log, where you will get 0, 0.2, 0.4, 0.6, 0, 0.2, 0.4, 0.6, 0, 0.2, 0.4, 0.6.

If you log at 16Hz or 8Hz, do you get what you expect, which is an update every 0.2 seconds, and does that solve the issue?

 

[swatson999]

What GPS are you using?

The Dynon GPS-250 is a true 5Hz GPS with a position and velocity calculation 5 times a second. However, this clearly will not fit well into a 4 Hz data output, so there's going to be some jumping as one of the 4Hz blocks will have two updates inside it. You can see this in the GPS time in the log, where you will get 0, 0.2, 0.4, 0.6, 0, 0.2, 0.4, 0.6, 0, 0.2, 0.4, 0.6.

I stand corrected on the GPS rate!

Looks like a Nyquist frequency thing, then?

 

[spatsch]

What GPS are you using?

The Dynon GPS-250 is a true 5Hz GPS with a position and velocity calculation 5 times a second. However, this clearly will not fit well into a 4 Hz data output, so there's going to be some jumping as one of the 4Hz blocks will have two updates inside it. You can see this in the GPS time in the log, where you will get 0, 0.2, 0.4, 0.6, 0, 0.2, 0.4, 0.6, 0, 0.2, 0.4, 0.6.

If you log at 16Hz or 8Hz, do you get what you expect, which is an update every 0.2 seconds, and does that solve the issue?

GPS-250. -- That explanation makes sense.

Will change to recording more frequently next time I fly to validate but I assume that will fix it.

On another note do you have any documentation on what the pitch degree, roll degree, turn rate, compass heading etc. does as you are going through 360 degree on all axis? I am trying to plot my loop in 3d and the GPS looses track around the top (not surprising considering the antenna is on top) for a couple of seconds so I figured I can compensate for that using TAS/PALT difference (gives me two dimensions) as well as some of the other metrics to interpolate the missing flightpath till the GPS comes back.

Think it would help to add a GPS on the bottom? I would think it would take to long for it to acquire a good enough position to be useful but maybe I am wrong... .


Oliver

 

[dynonsupport]

Oliver,
The GPS actually generally works fine when upside down, assuming that there isn't metal behind it blocking the signal. So you might be able to find a location (wingtip?) that still gets enough RF when upside down to keep a lock.

A second GPS won't work for the reason you state- the lock on time is a few seconds at minimum.

I'm not sure what you are asking for with what the various data does as you go through 360 degrees. Are you asking what the numbers in the datalog do? If so, all that is documented in our install manual. If not, please explain some more.

 

[spatsch]

Oliver,
The GPS actually generally works fine when upside down, assuming that there isn't metal behind it blocking the signal. So you might be able to find a location (wingtip?) that still gets enough RF when upside down to keep a lock.

A second GPS won't work for the reason you state- the lock on time is a few seconds at minimum.

I'm not sure what you are asking for with what the various data does as you go through 360 degrees. Are you asking what the numbers in the datalog do? If so, all that is documented in our install manual. If not, please explain some more.

Good tip on the GPS.

The info I could find in the manual is not quite on the level of detail I was looking for (maybe I missed something but I looked at the Appendix with the field descriptions in particular). 

Couple of examples:

- what does pitch show in inverted flight
- what does roll show in inverted flight
- how is magnetic heading impacted by pitch (e.g. if I am 90degree up)
- same for turn rate

To give a concrete example below the roll degree value during a loop. Now in a loop you never roll ... so why does it change and what can I infer if my roll degree e.g. shows 86 degree?

Oliver

Roll (deg)
-2.6
-2.3
-1.4
-1.2
-1.6
-1.9
-1.8
-0.2
+0.4
+0.3
-0.2
-0.6
-1.4
-2.5
-2.1
+0.3
+3.7
+5.9
+6.1
+4.1
+4.4
+13.9
+40.6
+86.9
+122.0
+144.3
+157.2
+164.7
+168.4
+170.8
+172.8
+174.7
+176.8
+178.8
-179.1
-177.4
-176.0
-174.1
-171.3
-168.2
-165.2
-161.0
-151.6
-112.2
-36.6
-18.9
-13.5
-10.4
-7.7
-5.6
-4.4
-4.1
-4.1
-4.2
-3.9
-2.8
-1.6
-0.7
+0.0
+0.7
+1.6
+2.5
+3.4
+3.8
+3.9
+3.9
+4.1

 

[dynonsupport]

Oliver:

Pitch when inverted (assuming level) would show 0. You are not pitched up or down. Pitch reads the nose in relation to the horizon, regardless of the roll of the aircraft.

Roll will show -180 or 180 when inverted. Roll is what defines "upside down" when level, not pitch. Roll is telling you the most direct way to being "wings level". You need to roll 180 degrees to solve this when inverted.

As you go over the top, you go from being at zero roll up until you are at straight up, to suddenly being 180 degrees rolled as you go past straight up. Now, in an imperfect loop where you do not pass exactly through straight up (you have some yaw), as you approach the vertical portion, your roll will slide from 0 to 180, not snap. This is because when you're at 88 degrees pitch but yawed 2 degrees, the closest way to wings level is actually to roll 90 degrees. Technically, when you are perfectly straight up, roll is undefined as it's a divide by zero problem.

Think of what happens in a half loop- your pitch goes from 0 to 90 and back to zero. But when you are done, you are "upside down". So while you didn't "roll", your roll angle somehow went from 0 to 180. It did that when you transitioned though straight up.

Now do a "loop" where you start with a 45 degree roll angle, but all you do is give it is a pitch input. You'll never achieve straight up, and your roll angle will change constantly as you are pitching. This is what your data shows- a slightly imperfect loop where as you didn't pass exactly through straight up.

Turn rate is "heading rate". It's how quickly your heading is changing. When going over the top as you go through zero ground speed and change from going due north to due south instantly, your turn rate goes infinite for a moment.

Now, with all of this said, the AHRS in SkyView is not meant as a perfect reference in aerobatics. High rates, unusual pitch attitudes, and lots of G's will lead to some small errors. So if you're trying to use SkyView to "judge" your loop and are trying to get zero roll until it snaps to 180 at the top, and going through 90 every time in pitch, you might not get the exact results you want every time.

 

[spatsch]

Oliver:

Pitch when inverted (assuming level) would show 0. You are not pitched up or down. Pitch reads the nose in relation to the horizon, regardless of the roll of the aircraft.

Roll will show -180 or 180 when inverted. Roll is what defines "upside down" when level, not pitch. Roll is telling you the most direct way to being "wings level". You need to roll 180 degrees to solve this when inverted.

As you go over the top, you go from being at zero roll up until you are at straight up, to suddenly being 180 degrees rolled as you go past straight up. Now, in an imperfect loop where you do not pass exactly through straight up (you have some yaw), as you approach the vertical portion, your roll will slide from 0 to 180, not snap. This is because when you're at 88 degrees pitch but yawed 2 degrees, the closest way to wings level is actually to roll 90 degrees. Technically, when you are perfectly straight up, roll is undefined as it's a divide by zero problem.

Think of what happens in a half loop- your pitch goes from 0 to 90 and back to zero. But when you are done, you are "upside down". So while you didn't "roll", your roll angle somehow went from 0 to 180. It did that when you transitioned though straight up.

Now do a "loop" where you start with a 45 degree roll angle, but all you do is give it is a pitch input. You'll never achieve straight up, and your roll angle will change constantly as you are pitching. This is what your data shows- a slightly imperfect loop where as you didn't pass exactly through straight up.

Turn rate is "heading rate". It's how quickly your heading is changing. When going over the top as you go through zero ground speed and change from going due north to due south instantly, your turn rate goes infinite for a moment.

Now, with all of this said, the AHRS in SkyView is not meant as a perfect reference in aerobatics. High rates, unusual pitch attitudes, and lots of G's will lead to some small errors. So if you're trying to use SkyView to "judge" your loop and are trying to get zero roll until it snaps to 180 at the top, and going through 90 every time in pitch, you might not get the exact results you want every time.

OK that makes a lot of sense. My goal is to interpolate the missing GPS data using that data during a loop so as I get all of this into my model will see how accurate it matches the part for which I do have GPS data... .

One clarification on heading rate though. I would have thought that this is based on the AHRS and not the ground speed. The heading change in my fuselage (where it points to) does not have to coincide with the heading change in ground speed for various reasons. So assuming no yaw when I go through 90 degrees up or down I should have an infinitely small period of infinite heading change in a perfect world.

 

[dynonsupport]

Yes, technically the heading rate is based only on the AHRS. I used a bad example of defining heading. It is the direction the plane is pointed, and turn rate is the rate at which that is changing. There is a moment pointed straight up or down when there is no "heading".

 

[preid]

Although I don't have the data point issue, I do have the question of just how accurate the GPS-250 actually is?
I was flying a RNAV approach visually, in other words, I used the points normally used for a RNAV as waypoints finishing at the airport. What I discovered however was that the plane was flying to the North of the actual airport itself. If I had flown the plane to the ground I would not only miss the runway but the airport itself by at least .25 miles.
When I check the LAT/LONG for the airport (FUL) used by my Flight plan in question on Google earth, it shows the center of the runway in the center of the airport.
Why would the AP flying a (GPS) HSI centered needle fly me off course to my airport? All other waypoints appeared to be flown precisely.

Thx!

 

[dynonsupport]

... I do have the question of just how accurate the GPS-250 actually is?

The SV-GPS-250 is a WAAS GPS, so it has WAAS accuracy.  However there is a statistical limitation to GPS without RAIM, which calculates reliability using several factors including satellite availability. Is KFUL always wrong? For the accuracy of the GPS itself, I think you answered the question in regards to the other waypoints.