Sunday, November 28, 2010

GAGA-1: CoCom limit for GPS

One problem for high-altitude balloon projects is the CoCom limit on how high and how fast a GPS will operate. To prevent GPS modules from being used in very fast moving weapons (such as ballistic missiles) GPS receivers are not allowed to operate at:

1. Higher than 60,000 feet

2. When traveling faster than 1,000 knots

The second restriction doesn't matter for GAGA-1, but the first does. GAGA-1 will have a maximum altitude (balloon dependent) of more like 100,000 feet.

Different manufacturers implement the CoCom limit in different ways: some use an AND rule (>60,000 ft and >1,000 knots) and others use an OR rule (>60,000 ft or >1,000 knots). For high-altitude ballooning it's ideal if the GPS uses AND. Unfortunately, this information is shrouded mostly in mystery and it's only through actual flights and testing that people have managed to determine which GPS receivers are AND and which are OR.

For GAGA-1 I have two GPS units: one in the Recovery Computer and one in the Flight Computer. The Flight Computer is using a Lassen IQ which is known to work correctly on balloon flights.

The Recovery Computer is using the GM862-GPS which will fail. This is OK because it is used when the balloon has landed to send GPS location via SMS messages. But the failure mode is important.

I've been back and forth with Telit technical support and they claim that the module will simply fail to give me a GPS fix above 60,000 ft but that once the balloon is down again it'll restart automatically. Others claim that code should be included to automatically reset the GPS if it hasn't given a fix for some length of time. I plan to update the code to include an auto-reset after 30 minutes if no fix or no satellites during flight and recovery.

2 Comments:

In the '80s I worked on a drone nav system before GPS was small enough or fast enough to be practical. (Not that it matters for this comment but we started with a commercial Omega navigation system from Collins.)

Anyway, one part of the system was a backup nav system in the event the Omega nav system failed. It was a seperate box that recieved lat/lon from the Omega nav on a regular basis. If that stopped then the backup would take command of the drone and use dead reconing to fly back to the recovery point and pop the 'chute.

We used airspeed and heading for the dead reconing, which I doubt would be useful in a balloon but perhaps integrating a pair of horizontal accelerometers at right angles to each other might give you some kind of approximation of location if/when the GPS cuts out.

I've done no checking on this and I guess the small values of accelleration might make it impractical with low cost accelerometers.

Hi! Interesting article! I didn't know there was such a limit in GPS products. Just a thought: is this limit in software or hardware? If it's in software, isn't there an existing open-source GPS software platform that you could modify to delete the condition, re-compile, and use it on some generic GPS hardware?

Links to this post:

About

Available Now

With this unique traveler's guide, you'll learn about 128 destinations around the world where discoveries in science, mathematics, or technology occurred or is happening now. Travel to Munich to see the world's largest science museum, watch Foucault's pendulum swinging in Paris, ponder a descendant of Newton's apple tree at Trinity College, Cambridge, and more. Each site in The Geek Atlas focuses on discoveries or inventions, and includes information about the people and the science behind them.

The GNU Make Book demystifies GNU make and shows you how to use its best features. You'll find a fast, thorough rundown of the basics of variables, rules, targets, and makefiles. Learn how to fix wastefully long build times and other common problems, and gain insight into more advanced capabilities, such as complex pattern rules.