Tom and the gang tested the P.Ref-1 airframe on a home-brew O5800 motor this weekend.

Here you see the GPS overlay on Google Earth for our launch site in the Black Rock Desert.

There is an interesting GPS artifact during the supersonic climb. GPS works off of relative timing differences in signal transmission times to satellites with known positions. If you are going fast enough, the Doppler shift in those timing signals fools the system. Although it maintains GPS lock, the incoming timing signals are distorted by supersonic flight. This is why the z-dimension seems to be low for quite a while, but as soon as the rocket slows down, the inputs are correct, and the rocket position snaps into place, in this case 27,100 ft. as the rocket arcs over at apogee and deploys the first parachute.

Then the rocket comes back by drogue parachute drifting off to the right. Closer to the ground, the main deploys, and the slope of return lengthens in the prevailing wind.

I am looking forward to the big Sony and Clotho Project flights in July… it will ultimately fly on 16x as much motor — three Q’s staging to a Q, with four HD cams on board!

6 responses to “RocketMavericks GPS Overlay”

  1. In Memoriam: jerryfi_99 Avatar
    In Memoriam: jerryfi_99

    You have discovered that not all GPS receivers are created equal. The code and carrier tracking loops need to be designed to handle the doppler – most don’t need that capability (some commercial units wouldn’t even work in jet aircraft). But there are receivers designed to work in artillery shells, LVs for range safety tracking, on satellites (Gravity Probe-B, APEX, DARPASAT, and scads of others), etc. You might check with Brad Parkinson (I think he is still at Stanford), or the good folks at Trimble, to see if there is handy solution for your app. It may be pricey, but maybe not… they may even want to give you a sample 😉 Probably wishful thinking on that… BTW, there could be other causes for the data lockup, such as computation speed, satellite acquisition, number of channels, etc.

    Reply
  2. jurvetson Avatar
    jurvetson

    Do the civilian units work over Mach 4? I thought you needed to adjust the firmware to enable that….

    Reply
  3. In Memoriam: jerryfi_99 Avatar
    In Memoriam: jerryfi_99

    Mach 4 is about 1.4 km/s at sea level. A satellite in a 400 nmi circular orbit is moving at about 7.5km/sec, 5x faster. The satellites mentioned above used the C/A (coarse/acquisition) code, otherwise known as SPS (Standard Positioning Service), or "civilian" code (a misnomer). IOW, they use the same signal, code and algorithms as used in standard commercial/consumer GPS rcvrs. However the rcvr’s code and carrier tracking loops (sort of analogous to a radio’s local oscillators) are designed for the high doppler. They are available for civilian use, but probably not across the counter at Best Buy as "consumer" units. Trimble used to make the TANS receiver which was flown on the APEX satellite (and some others), nearly unmodified as I recall. If interested in finding a high dynamic, C/A code, receiver for your app, there are still some people at Stanford (Brad Parkinson has retired apparently) who are up on what is available, and what was used on the Gravity Probe-B. I’ve ignored the acceleration factor, but that is also influenced by the rcvr tracking loops and the computation speed. All do-able, but possibly pricey.

    So, short answer, "civilian" code receivers are available for high dynamic apps, but probably not in the consumer market. It would be interesting to see how the current crop of low cost consumer units work at high velocity. BTW, we are talking firmware changes to modify the tracking loops. I probably muddied the water here, but the terminology and details get pretty complex when you get beyond the screen of that little handheld map. The first GPS receiver I saw was a full 6′ tall rack of equipment (at Stanford Telecom in the early ’80s). It couldn’t move very fast.;-)

    The Precise Positioning Service (PPS), sometimes called the military service, uses the P(Y) code and is not available for use commercially. A lot of stuff left out of this discussion, but there are some good tutorials on the net. For instance: edu-observatory.org/gps/tutorials.html

    Reply
  4. Pieces of Eye Avatar
    Pieces of Eye

    Iv’e had a similar problem with low speed climbs. GPS is also the least accurate in the vertical direction. The Doppler shift is also ridiculously small. Fobs = Fsrc * sqrt(1-v^2/c^2)/2. I know the GPS is corrected for General Relativity effects. Any idea, jerrfi_99 what Doppler shift magnitudes are needed for notable position errors in the vertical?

    Reply
  5. In Memoriam: jerryfi_99 Avatar
    In Memoriam: jerryfi_99

    PoE, off-hand I don’t know, it depends on the rcvr implementation. Just some general comments: for this type of app, you would want a rcvr with at least 6 channels, 12+ is better.

    You would want to be sure that you’ve achieved code lock on all sats in view, especially those overhead, before launch- that may take some time and you want the rcvr powered for maybe a half hour before use, to acquire the catalog.

    You also want to be sure that the antenna(s) has good spherical coverage especially in the vertical direction.

    You should also wait for a low VDOP (vert dilution of precision), which will usually require a GPS sat nearly overhead. You are correct that vertical precision is most challenging, and a VDOP plot for the day may steer you away from certain launch times. There will usually be at least one period, of a few minutes, each day when the VDOP spikes.

    With all that in place, you’re depending on the rcvr design to maintain carrier and code lock, the solution computation speed of the processor and also the data interface speed. How many solutions/sec are being produced? If the data is being output once per sec, it will already be very stale before it is seen. There are $50 rcvrs and there are $50K+ rcvrs. There are differences.;-) For critical apps, there are some other techniques for improving accuracy, such as differential GPS, translators, wide area augmentation system (WAAS), and finally inertial measurement augmentation. I would start by looking at the first four points I made above. In the end, most low cost commercial GPS receivers are not optimized for vertical motion, as they are meant for surface applications – you would have to search that out.

    BTW, after all that, my experience with high accuracy GPS use is somewhat aged- unlike with wine, that is usually not a good thing. Somebody more current may have better ideas.

    Reply
  6. _Jim1 Avatar
    _Jim1

    @jerryfi_99 jerryfi_99, experience here with first GPS receivers were with the HDUE (High Dynamic User Equipment) and Manpack units at a defense contractor (TI’s Equipment Group, that unit now part of Raytheon) circa 1978.

    These units used 5 and 1 physical "receiver" modules respectively (the Manpack unit multiplexed in sequence to the various viewable GPS birds), with the PRN ‘code’ (for both C/A and P codes!) located in (or on) actual "ROM" board under the control of a TMS9900 uP on it’s own ‘card’. Each receiver module was composed of approx. five 5" x 6" boards with a common chassis-mounted RF preamplifier and N-way L-band RF power splitter and common 10.23 MHz precision reference oscillator.

    The HDUE ‘box’ was about the size of a small microwave oven and the Manpack unit about half that size.

    At the time TI was also supporting field tests at the Yuma Proving Grounds and only 3 ‘birds’ had been deployed for the Space Segment. Years later (1990 time frame) I cubed with another engineer (Pat S.) who had been out at the Yuma Proving Grounds supporting the GPS field testing in ’78. Small world sometimes!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *