USC and GPS

[UhClem]

USC just released their flight report claiming to have gone past the Karman line. There is a lot of intersting stuff in there but I want to focus on one item: GPS

Two GPS receivers were on board and both lost lock at launch as expected. What wasn't expected is the long delay before lock was acquired again.

There was a long time period after acceleration dropped below 4G's and altitude reached the 50km lock out of the uBlox receiver in the BRB but it didn't get a lock. There was also a long delay after dropping below 50km. There are more dynamics that just the linear acceleration.

The gold standard for GPS antennas in rockets/missiles is a wrap around design. The big advantage here is a consistent phase center that is located on the longitudinal axis. See figure 3.2 of RCC 322.

The BRB has a simple patch antenna and its location is not mentioned. I suspect that no care was taken to place it on the vehicle centerline. Which means that the >6 rps rotation spun it around creating additional dynamics.

Short of throwing a bucket of money to Haigh-Farr, or some other antenna vendor, the least you should do is put the antenna on the centerline if you expect significant rotation rates.

Another problem that will make things worse is the aerodynamic heating. This raises the RF noise floor and will push a marginal link over the edge.

 

[tfish]

Tony

 

[Adrian A]

Congratulations to the USC RPL team!

I can't wait to see the Raven4 FIP data file from that flight.

When you think about the state estimation that a GPS receiver has to do, it can have a strong enough signal and still lose lock because a rocket's flight doesn't fit what the receiver thinks is possible and/or allowable. Rocket levels of vertical acceleration have been known to cause GPS receivers to lose lock, as the in-flight measurements may be tossed out as more likely to be noise or communications error. The most-recent (generation 8) U-blox receivers seem to do better at this than the Generation-7 receiver used on the Traveler, though there hasn't been a whole lot of data on it that I'm aware of yet. This flight from April, shows GPS lock maintained throughout the flight, including a 12-13 G boost. This weekend I'll be exploring the effect of higher Gs and high speed on the Featherweight GPS with my 29mm carbon rocket.

 

[jderimig]

Antennas are very important. Patch antennas are probably the worst choice for a dynamic measurement in rocket.

All COCOM gps will not send data to the output above mach. They may or may not have lost lock internally but will not output the data.

The USC flight was probably above Mach for most of the flight except when it was near apogee. At that point it would have been up to the Ublox code writers whether to output the altitude. Based on experience it most likely does not above 50km.

Some early Ublox6 chipsets reported altitude well above 200K feet based on simulated GPS signal testing that has been shared with me. Ublox7 does not and I do not know of any similar testing on Ublox 8 chipsets.

 

[VernK]

USC just released their flight report claiming to have gone past the Karman line. There is a lot of intersting stuff in there but I want to focus on one item: GPS

Two GPS receivers were on board and both lost lock at launch as expected. What wasn't expected is the long delay before lock was acquired again.

There was a long time period after acceleration dropped below 4G's and altitude reached the 50km lock out of the uBlox receiver in the BRB but it didn't get a lock. There was also a long delay after dropping below 50km.

I think the reason the GPS did not relock once the acceleration dropped off was that the velocity was too high. This was a single stage flight. Max velocity was at motor burnout. I think they quoted something like Mach 5. At any rate, the uBlox GPS in the BRB has a velocity lockout at about 1700 feet/sec. Roughly Mach 1.5. Considering they claim to have coasted to over 300K feet, I doubt the velocity dropped low enough for the GPS to start reporting fixes again until it was above 50km. However, the uBlox GPS in the BRB also has an altitude lockout at 50km. Therefore, they likely coasted from motor burnout to apogee without any GPS fixes.

After apogeee the rocket would have been in free fall from over 300K feet back down to the 50km altitude limit. However, by then it would again be traveling too fast and be above the GPS velocity lockout. It would slow down as it descends into thicker air and eventually regain GPS fixes at that point. In other words, well below the 50km limit.

 

[Adrian A]

Antennas are very important. Patch antennas are probably the worst choice for a dynamic measurement in rocket.

They're not ideal but they certainly work. If you have a GPS unit that outputs satellite signal strength, you can test this by pointing the patch antenna at the ground and at the sky. In my experience, both orientations provide sufficient signal strength to maintain GPS lock. A similar test will show you that vertical patch rotated in azimuth has even less signal strength variation, so a spinning rocket has enough signal strength to stay locked throughout the roll rotation.

All COCOM gps will not send data to the output above mach. They may or may not have lost lock internally but will not output the data.

Here's data from a Ublox 8 flight that says otherwise. I'm not sure what the maximum velocity a U-Blox 7 or 8 receiver will output data, but it's definitely above Mach 1.2 for U-Blox 8. This weekend I hope to try it on a faster flight if the weather allows.

The USC flight was probably above Mach for most of the flight except when it was near apogee. At that point it would have been up to the Ublox code writers whether to output the altitude. Based on experience it most likely does not above 50km.

Some early Ublox6 chipsets reported altitude well above 200K feet based on simulated GPS signal testing that has been shared with me. Ublox7 does not and I do not know of any similar testing on Ublox 8 chipsets.

The Ublox 8 receiver datasheet says there is a hard limit at 50 Km, and anecdotal second-hand reports confirm this. I think that is true for Ublox 7 as well. I agree with you and Vern that the rocket was probably just still going too fast when it passed through the 50 km threshold in both directions.

 

[plugger]

Here's the link to their whitepaper which contains quite a bit of data and analysis.

https://www.uscrpl.com/s/Traveler-IV-Whitepaper

 

[cerving]

So what did they use to determine the altitude if they lost the GPS at 50km? Did they have an IMU on board?

Here's the link to their whitepaper which contains quite a bit of data and analysis.

https://www.uscrpl.com/s/Traveler-IV-Whitepaper

Very nice, and I applaud their achievement!

What I personally found interesting is that the MS5607's temperature sensor performed rather poorly compared to the dedicated LM75B unit. This correlates data that I've seen with the MS5607 and other digital barometer chips, the integrated temperature sensors in them aren't really designed for rapid changes and they take awhile to stabilize. That may have implications for changes in hobby rocketry altimeters in the future. A lot of the other data is really interesting, but for the 99.99% of us hobby rocket flyers who aren't going to be pushing the bounds of barometric altimeters, much less reaching for the Karman line, it really isn't applicable.

 

[jderimig]

So what did they use to determine the altitude if they lost the GPS at 50km? Did they have an IMU on board?

I lightly read the whitepaper and may have missed a few things. What bothered me most was no discussion of the possibility of off-vertical error in the accelerometer integration. They did have a Bosch IMU but one pg 14 they said the output was unusable. Maybe someone else who read the paper more thoroughly can describe on the vertical component of acceleration was handled or assumed in the analysis?

 

[VernK]

I lightly read the whitepaper and may have missed a few things. What bothered me most was no discussion of the possibility of off-vertical error in the accelerometer integration. They did have a Bosch IMU but one pg 14 they said the output was unusable. Maybe someone else who read the paper more thoroughly can describe on the vertical component of acceleration was handled or assumed in the analysis?

I got the impression that the output from the IMU was declared unusable during descent but that they did use it to correct for any off vertical trajectory during assent.

 

[cerving]

There's so much thrashing around once the chutes come out that an IMU would be unusable. You CAN use it to fire the drogue, however, which is what they did. I didn't see any mention of firing a main chute... maybe they figured that they didn't really need one. Their integrated velocity graph shows it at about -2,000 fps when it ends at about 250 secs into the flight, so clearly that graph is incorrect in that regard... it would have made a really nice hole in the ground!

 

[jderimig]

I got the impression that the output from the IMU was declared unusable during descent but that they did use it to correct for any off vertical trajectory during assent.

Perhaps but no evidence of that data was presented in the white paper. They also mentioned that they had gravity correction enabled on the imu which would not have worked in a rocket flight. That is what I had interpreted their reason for the unusable statement.

 

[jderimig]

There's so much thrashing around once the chutes come out that an IMU would be unusable. You CAN use it to fire the drogue, however, which is what they did. I didn't see any mention of firing a main chute... maybe they figured that they didn't really need one. Their integrated velocity graph shows it at about -2,000 fps when it ends at about 250 secs into the flight, so clearly that graph is incorrect in that regard... it would have made a really nice hole in the ground!

Their white paper indicated they used a timer for drogue deployment. From what I thought I read. Using attitute to fire the drogue would be a very bad idea given the risk of the rocket tumbling at very high alts.

 

[jderimig]

Perhaps but no evidence of that data was presented in the white paper. They also mentioned that they had gravity correction enabled on the imu which would not have worked in a rocket flight. That is what I had interpreted their reason for the unusable statement.

If the gravity correction was enabled, and it sound like it was, the acceleration vector would be interpreted as the gravity reference vector and it would be relatively invariant. That would mostly like cause any gyro rate to be interpreted as drift by the motion engine and attenuated.

 

[VernK]

If the gravity correction was enabled, and it sound like it was, the acceleration vector would be interpreted as the gravity reference vector and it would be relatively invariant. That would mostly like cause any gyro rate to be interpreted as drift by the motion engine and attenuated.

Yes, that seems right to me. I don't know the details about how the motion engine generates its orientation quaternion but the USC paper on page 8 in section III.3 says they used the IMU quaternion to transform the accelerometer readings into the world frame. That made me think they corrected the altitude derived from the accelerometer for any non-vertical trajectory. I think your point calls that correction into question.

 

[cerving]

10 Hz sampling for the IMU's quaternion function is pretty low, 100 Hz would really have been much better (that's the maximum value for the magnetometer, which is the slowest sensor in the package). They might have needed a dedicated processor for it, though.

 

[jderimig]

Yes, that seems right to me. I don't know the details about how the motion engine generates its orientation quaternion but the USC paper on page 8 in section III.3 says they used the IMU quaternion to transform the accelerometer readings into the world frame. That made me think they corrected the altitude derived from the accelerometer for any non-vertical trajectory. I think your point calls that correction into question.

I think the data and analysis establishes the rocket traveled ~330,000 feet during the ascent. The white paper is just missing the data and analysis on exactly what the path was.

 

[UhClem]

When you think about the state estimation that a GPS receiver has to do, it can have a strong enough signal and still lose lock because a rocket's flight doesn't fit what the receiver thinks is possible and/or allowable.

It is simpler than that. The code tracking loop is attempting to measure the arrival time of the signal by comparing the PRN from each satellite to the received signal. Which has a lot of noise. The code tracking loop includes a low pass filter on the output of the comparators. (There are typically three, early, late, and on time.) Less bandwidth gives you a better estimate of the timing but at the cost of high dynamics pushing the signal outside the tracking window.

The various modes of the uBlox7 change the loop bandwidth. For a rocket tracker it would be nice to use the <4G airborne setting from launch to apogee, then the <1G airborne setting from apogee to landing, and then stationary after that. Or perhaps pedestrian if you worry about wind dragging the rocket around.

Really fancy GPS systems use an IMU to aid the tracking loops.

 

[UhClem]

Antennas are very important. Patch antennas are probably the worst choice for a dynamic measurement in rocket.

All COCOM gps will not send data to the output above mach. They may or may not have lost lock internally but will not output the data.

Patch antennas work great. Just ask Haigh-Farr.

COCOM/ITAR limits went away several years ago and now what we have is what uBlox calls a sanity check on altitude. If you use an older GPS receiver it will have the ITAR limits but not most of the new stuff like the uBlox7.

 

[UhClem]

I think the reason the GPS did not relock once the acceleration dropped off was that the velocity was too high. This was a single stage flight. Max velocity was at motor burnout. I think they quoted something like Mach 5. At any rate, the uBlox GPS in the BRB has a velocity lockout at about 1700 feet/sec.

The documents indicate only an altitude sanity check. The velocity limit is more like the acceleration limit. It doesn't work as well if you exceed it.

In any case, the Princeton flight last year did something very similar. It lost lock at launch, developed a high spin rate (up to 2,000dps at one point), never exceeded 50km, but didn't start getting GPS data again until about 9 seconds after apogee.

 

[UhClem]

What I personally found interesting is that the MS5607's temperature sensor performed rather poorly compared to the dedicated LM75B unit.

I suspect that they recorded the compensated data which is a bad idea. The MS5607 data sheet has details on performing the calculations but if you do them on board and drop a bit somewhere it is very hard to pick it up again.

If they had the raw data then they could see if it were a sensor problem or a data crunching problem.

 

[UhClem]

Their white paper indicated they used a timer for drogue deployment. From what I thought I read.

The Ravens were configured as timers (perhaps the Raven3 performance scared them?) but they were a backup to their custom "HAMSTER" avionics package. GPS apogee detection appears to have been the primary mode with the timer backup doing the work in this case.

They also say that the ADXL375 accelerometer is unreliable around 0G's. Which I don't believe. You do have a problem with noise but that is easily dealt with. I seem to recall describing this in excessive detail in my 2004 NARAM R&D report. Sampling a 400Hz bandwidth signal at 20Hz isn't a good start.

 

[VernK]

The documents indicate only an altitude sanity check. The velocity limit is more like the acceleration limit. It doesn't work as well if you exceed it.

In any case, the Princeton flight last year did something very similar. It lost lock at launch, developed a high spin rate (up to 2,000dps at one point), never exceeded 50km, but didn't start getting GPS data again until about 9 seconds after apogee.

What documents are you referring to? The uBlox7 used in the BRB and other rocketry trackers definitely has a velocity lockout that is set to exactly 515 m/s. I have flown many past that velocity and they all immediately stop reporting valid fixes. As soon as the velocity is below 515 m/s they immediately resume normal operation. I have also verified this behavior using a GPS simulator.

 

[UhClem]

What documents are you referring to?

https://www.u-blox.com/sites/defaul...tionProtocolSpec_(GPS.G7-SW-12001)_Public.pdf

 

[VernK]

https://www.u-blox.com/sites/default/files/products/documents/u-blox7-V14_ReceiverDescriptionProtocolSpec_(GPS.G7-SW-12001)_Public.pdf

The table titled "Dynamic Platform Model Details" at the top of page 2 lists a maximum horizontal velocity of 500 m/s and a maximum vertical velocity of 100 m/s for the airborne <4g mode. The accuracy of the fix might be degraded above those limits, maybe that it what it is trying to say. However, I can also say with absolute certainty that the device will stop reporting valid fixes when the velocity in any direction exceeds 515 m/s. That table also lists a max altitude of 50,000 m for the airborne <4g mode. Using a GPS simulator, I have confirmed it stops reporting valid fixes above that altitude. It resumes again as soon as the altitude is even 1m below that limit.

 

[jderimig]

Patch antennas work great. Just ask Haigh-Farr.

COCOM/ITAR limits went away several years ago and now what we have is what uBlox calls a sanity check on altitude.

Try and buy a gps without altitude and especially velocity limits. If you are tempted to point to the Piksi SDR GPS's I can share an email where they told me they would refuse to remove the velocity and altitude lockouts. The limits are well in place still.

 

[OverTheTop]

If the gravity correction was enabled, and it sound like it was, the acceleration vector would be interpreted as the gravity reference vector and it would be relatively invariant. That would mostly like cause any gyro rate to be interpreted as drift by the motion engine and attenuated.

Depending on where it is in the atmosphere and what speed it is doing there can be a significant shift in what the IMU interprets as down. In my VTS system I mount the autopilot "upside down" so that the deceleration vector, caused by drag, is actually pointing in the right direction so I get the relevant controls working during the coast phase of flight when the stability system is active and also keep the gravity correction relatively happy. If I had mounted the autopilot right way up it would encourage the rocket to swap ends when the stability is enabled, since it would think the rocket was flying inverted.

If they have any tumble or roll this can also potentially mess with the IMU's gravity correction.

 

[jderimig]

Depending on where it is in the atmosphere and what speed it is doing there can be a significant shift in what the IMU interprets as down. In my VTS system I mount the autopilot "upside down" so that the deceleration vector, caused by drag, is actually pointing in the right direction so I get the relevant controls working during the coast phase of flight when the stability system is active and also keep the gravity correction relatively happy. If I had mounted the autopilot right way up it would encourage the rocket to swap ends when the stability is enabled, since it would think the rocket was flying inverted.

If they have any tumble or roll this can also potentially mess with the IMU's gravity correction.

It may be happy but it's not totally right. In a rocket you should disable the gravity correction and only use the rate gyro's to calculate the rotations. Thrust and acceleration vectors are not gravity and will always point in the vehicle z-direction. The IMU processing engine assumes that vector is the earth frame z-direction not the vehicle frame z-direction. The result will be an under estimation of gyro rates.

 

[OverTheTop]

It may be happy but it's not totally right. In a rocket you should disable the gravity correction and only use the rate gyro's to calculate the rotations. Thrust and acceleration vectors are not gravity and will always point in the vehicle z-direction. The IMU processing engine assumes that vector is the earth frame z-direction not the vehicle frame z-direction. The result will be an under estimation of gyro rates.

It may not be exactly right, but it does work somewhat. I had set myself the challenge of using a COTS autopilot for my VTS implementation, so it is what it is. I will eventually get around to a VTS v2.0 which will have firmware specific for rocket use.

 

[jderimig]

It may not be exactly right, but it does work somewhat. I had set myself the challenge of using a COTS autopilot for my VTS implementation, so it is what it is. I will eventually get around to a VTS v2.0 which will have firmware specific for rocket use.

Which autopilot is it?