swatson999
Well-Known Member
- Joined
- Oct 6, 2010
- Messages
- 1,689
So here was interesting thing that happened to me today.
My plane is "down" for annual CI, and that coupled with some business travel has kept it in the hangar for several weeks now. Today, when I turned the unit on, the synthetic vision looked "weird". The local mountains were there where they should be, but the nearby "ground" or horizon was kind of tilted and covered part of the bottoms of the hills. Hmmmm...at first I thought it was a problem with the ADAHRS, but then I realized...the mountains weren't tilted at all.
After puzzling over this, I realized that it must be the GPS solution, and lo and behold, it was about 500' too low. I just let it sit for a while, assuming it must be a bad solution due to out-of-date almanacs, and it slowly came up over a period of about 5-10 minutes to be about 100' too low (I know a complete almanac takes, IIRC, 6 minutes to load from the spacecraft signal). But it then sort of got "stuck" there.
I cycled power, and the solution got a little better...50' or so too low. Repositioned the plane a bit to get a different view of the sky, still no joy, but then another power cycle and *boom*, it was dead on at the correct altitude.
All the while, the VDOP was showing around 1.6 or so, even after the correct solution, and always tracking 9-10 satellites.
I found it odd that it could be that far off and still have a VDOP that low, but what was also disconcerting was that it seemed to get "stuck" at the incorrect altitude, until forced to reacquire and recomputed the solution.
Given that the [X,Y,Z,t] vector solution is done via LSQ solution of the overdetermined matrix equation, I didn't think it was possible to find a local minimum value for the error other than the correct one, but it's been a long time since I wrote GPS software.
Any ideas why it would do this? I also assume that it would *eventually* find its way out of this solution space and into the correct one, if one were patient enough.
Very strange...it's working properly now, of course, but something worth double-checking during taxi out, that the GPS ALT is correct.
My plane is "down" for annual CI, and that coupled with some business travel has kept it in the hangar for several weeks now. Today, when I turned the unit on, the synthetic vision looked "weird". The local mountains were there where they should be, but the nearby "ground" or horizon was kind of tilted and covered part of the bottoms of the hills. Hmmmm...at first I thought it was a problem with the ADAHRS, but then I realized...the mountains weren't tilted at all.
After puzzling over this, I realized that it must be the GPS solution, and lo and behold, it was about 500' too low. I just let it sit for a while, assuming it must be a bad solution due to out-of-date almanacs, and it slowly came up over a period of about 5-10 minutes to be about 100' too low (I know a complete almanac takes, IIRC, 6 minutes to load from the spacecraft signal). But it then sort of got "stuck" there.
I cycled power, and the solution got a little better...50' or so too low. Repositioned the plane a bit to get a different view of the sky, still no joy, but then another power cycle and *boom*, it was dead on at the correct altitude.
All the while, the VDOP was showing around 1.6 or so, even after the correct solution, and always tracking 9-10 satellites.
I found it odd that it could be that far off and still have a VDOP that low, but what was also disconcerting was that it seemed to get "stuck" at the incorrect altitude, until forced to reacquire and recomputed the solution.
Given that the [X,Y,Z,t] vector solution is done via LSQ solution of the overdetermined matrix equation, I didn't think it was possible to find a local minimum value for the error other than the correct one, but it's been a long time since I wrote GPS software.
Any ideas why it would do this? I also assume that it would *eventually* find its way out of this solution space and into the correct one, if one were patient enough.
Very strange...it's working properly now, of course, but something worth double-checking during taxi out, that the GPS ALT is correct.