[roc-chat] Re: GPS unit speed and altitude limitations

Thanks Allen,

Nice paper; but definitely dated - most receiver devices use VCXO's these
days and they are temp compensated (TCXO). They are also designed for
high-noise environments to begin with and have integrated LNA's which have
been optimized for the ASIC process in use. Finally, the Kalman gains can
be adjusted to give higher variance in positional nav accuracy, but less
slop on the output to avoid "hunting" problems you described.

uBlox and MediaTek use them both on their silicon; I wouldn't recommend
using an external crystal unless it's
the MIL-STD-883 rated ones like I use (Vectron, Euroquartz, Q-Tech, and
Greenray) all offer these for pennies
on the dollar.

I do have COCOM limits plots, actually GPGGA inhibition starts on a UBX-6
at a little under 500 m/s (about 492 m/s depending on AGL & air density of
the launch site). If you check out the specs on Ublox-6, the 50,000M
(150,000' MSL) and 500 m/s (1500 fps) are valid and do occur. Once you fall
out of Mach, inhibition goes away and life is good - what ends up happening
anyhow is that you have a few flat spots on your Google Chart, big deal.
Only downside is larger standard deviation which is attributed to the
initial impulse problem you accurately described. It's the time-space
problem all over again :-)

If you're relying on flying a GPS for a real flight tracking system (e.g.
ITAR gear), then the issues involve more with the degradation of the L1
signal with the mesosphere, a lot of which has been solved with WAAS to
give a poor mans DGPS, but there are other problems with WAAS since that
has not been fully deployed in the US - yet (although I plan to test some
of this in 2012).

But, you do have that issue with the processor and there is definite truth
to orientation and if you're not doing your trace length calcs correctly,
you're hosed (but this should be considered with the PCB and good antenna
design).

But yes, In general, when I hear about a "board which does not work with
vibration", it's clearly documented as a side-effect of design issues
outlined in the paper below...

Thanks,
-James




On Tue, Dec 27, 2011 at 11:27 AM, Allen Farrington
<allen.farrington@xxxxxx>wrote:

> Neat article, however, I doubt if the COCOM limits are what we experience
> when using these units in rocketry.
>
> The most likely issue is that the jerk (acceleration first derivative) is
> too much for the on-board crystal oscillator to hold it's frequency and
> then the tracking loop just can't hold. Fortunately, most of these chip
> sets will regain lock pretty quickly if they were tracking when it lost
> lock. I've not done any testing but you may find that reorienting the
> device will fix the issue.
>
> For all the details, try this paper:
> http://www.ieee-uffc.org/frequency_control/teaching/filler_paper.html
>
> Warning, there's a lot of math.
>
> Allen
>
> Sent from my iPad
>
> On Dec 27, 2011, at 8:11 AM, Chris Spurgeon <chris@xxxxxxxxxxxxxxxxx>
> wrote:
>
> > The Make Magazine blog has a little discussion of the hows and whys that
> GPS units cut off at high speed and/or high velocity.
> >
> >
> http://blog.makezine.com/archive/2011/07/gps-units-disable-themselves-if-they-go-faster-than-1200-mph.html
> >
> >
> > Chris Spurgeon
> > chris@xxxxxxxxxxxxxxxxx
> > twitter.com/chrisspurgeon
> >
> >
> >
> >
> >
> > --
> > ROC-Chat mailing list
> > roc-chat@xxxxxxxxxxxxx
> > http://www.freelists.org/list/roc-chat
> >
>
> --
> ROC-Chat mailing list
> roc-chat@xxxxxxxxxxxxx
> http://www.freelists.org/list/roc-chat
>
>

Other related posts: