USC and GPS

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
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.

Verifying that the math is done correctly is straightforward, both by comparing to their examples and by verifying constant ambient pressure as you heat and cool the unit into different operating ranges, both of which have been done with the Raven. Re-reading the report, I see that they didn't use the Raven's baro data recording. Not sure why, since it's the same sensor they used, but recorded twice as often. I also see a statement that isn't quite correct: "The Raven interpolates its readings to the timescale of its axial acceleration sensor, which is both the most frequently recorded source and the only data from the Raven used in the final results." Looking at the graphs of the baro data in the FIP it appears interpolated, but that's just the display. The data samples are recorded on board at their own sampling rate. If you select the parameters you want to export to a spreadsheet and right-click in the parameter selection box, you'll see an option for copying the data to paste into Excel. When you do that you'll see that each sample from every measurement gets its own timestamp at the time it was recorded.

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 flew Raven 4s, rather than Raven3s. As far as I know, the Raven4 performed the only apogee deployment. They used one of the deployment channels as a timer, which is what I have been recommending for flights over 120kft. The Raven 4s have much-improved accelerometer accuracy compared to all previous Raven versions. On this flight, if they had used the Raven 4's accel-based apogee estimate rather than a timer, it would have done the apogee deployment in the exo-atmospheric part of the flight. That's not saying a lot though, since the middle 240 seconds of this flight were over 100 kft. The rocket was reading a small negative fraction of a G before the deployment, which mostly went away after deployment, which would be consistent with centrifugal acceleration from a tumble. That small negative G reading caused the on-board estimate of apogee to be about 20 seconds earlier than apogee, which again wouldn't have made any difference since the altitude at that time was over 300,000 feet, and the density at 280,000 feet (the highest altitude I have a reference for) is 5 millionths what it is at sea level. If it's true that an exo-atmospheric tumble caused those small negative-G readings, then the Raven4's accel-based apogee estimate was right on the money. I did an accel calibration the night before I express-mailed them their units, using the standard accel cal process in the Featherweight Interface Program. Their units were stock except for high-altitude firmware which allows for longer timer durations, higher altitude thresholds, and has more filtering on the baro sensing for the deployment logic. So for people planning a flight over 100 kft with a Raven4, it looks like the on-board apogee estimate is now probably accurate enough for that task. I won't be really confident in that though, until I see more data from flights between 30k and 150kft where there is baro and GPS data that clearly shows the apogee time.
 
RPL member here!

Just wanted to clarify, we had a total of four redundant apogee deployment mechanisms on Traveler 4. The primary was our custom-built avionics unit using GPS, with a quadratic regression that would approximate our flight path and detect when we had reached its peak. We also had a fallback timer running on our flight computer that was configured to deploy at T+173 seconds. GPS lock was not regained until late in the flight, so our avionics unit deployed the drogue via timer (we know because we see a pressure spike in the nosecone at the exact moment our system activated the pyro outputs). As a backup, we had two redundant Raven4s mounted to our backplane, configured to deploy via timer a few seconds later than our unit. Thanks to our sims team, we had a pretty good idea of when the rocket was going to reenter the atmosphere, so we were quite comfortable using timer-based deployment for the backups.

Also, huge shoutout to Adrian for all his help! Just a few days before the launch, we realized that there weren't any working high-altitude ravens left in our ravens bin, and called Adrian in a near-panic. He was able to prep and ship two high-altitude Raven4s by the next morning, and they got to us just in time for the launch! He's also given us some super valuable insight on analysis of the Raven data.
 
Jamie and team. Congratulations on the flight. Very cool :cool:.

I am pleased to see you had redundant systems on your rocket. I really like the quadratic regression idea, and the contingency plans as well. Enjoy the success!
 
Regarding the locations of our GPS antennas, the best place to see it is on this picture from our Twitter:
D40GQ7jUcAEuo8I.jpg

You can see the BigRedBee under the yellow antenna on the left side, and the PA6H's antenna is under all that orange tape on the top of the unit, facing toward the camera. We had originally planned to use this high-gain omnidirectional antenna, but it or its cable appeared to fail at some point during launch prep. When we were prepping the avionics unit on Saturday for the (eventually scrubbed) launch, we were unable to get lock even after leaving the unit outside for like 10 minutes, so we switched to the backup antenna, a standard active antenna from Amazon. This was able to get lock in a minute or two under the same conditions. This is what caused the original launch delay on Saturday, pre-scrub.
 
If you want optimal lock on the GPS keep the antenna well clear of any transmitters. I have seen the lock time of GPS units affected by nearby Tx antennas. It is either receiver desensitisation or introducing clock jitter in the GPS I think. Glad you system worked out for you. Nice to see you didn't get "go fever" and scrubbed till an alternative was established.
 
Do any of the other satellite navigation systems offer greater speed or altitude recording GLONASS or the others?
 
I think if you have access to the military navigation streams there is no velocity, acceleration or altitude limits. With the civilian data streams these limits are imposed in the receivers. It is possible to get receivers that have wider limits, and it is also possible to post-process the pseudoranges from the satellites to get the location data. You can do your own GPS receiver (really just a bunch of correlators, and simple if you say it fast ;)) in FPGA fabric if you are really keen.

Remember that GPS only provides position information. Velocity and acceleration are derived functions.
 
With their own skill set some people could develop a GPS system from first principles to be unlimited no doubt, but few have the skills.
I was wondering whether the other systems have the same velocity and altitude cut offs.
 
Remember that GPS only provides position information. Velocity and acceleration are derived functions.

Actually GPS velocity readings are as direct a measurement as position. They are a totally independent measurement. Velocity is determined by measuring the Doppler shifts and position is determined by measuring pseudo ranges. It has always amazed me that the Doppler shift can be measured by an inexpensive consumer electronics GPS for something moving just a fraction of a meter per second. Which also means the orbital velocity of each GPS satellite also has to be known to within that kind if precision.
 
This was able to get lock in a minute or two under the same conditions.
That is not a good sign. All in view GPS systems like the uBlox7 only require 30 seconds to provide position data from a cold start. They lock onto the signal almost instantly and then need 30 seconds to receive the ephemeris data so they can compute a solution.

If it takes more than 30 seconds then something is wrong. Poor antenna pattern, low signal strength, bad SWR, and/or RFI.
 
Huh. I don't remember the exact time for a cold start, but I do think it was more than 30 seconds. Maybe it was due to RF interference, as we did have our transmit antennas kinda close to the GPS antennas. On the left, the yellow antenna is the BigRedBee 428MHz 300mW APRS transmit antenna. And right at the very top of the unit the black antenna is our Digi XTend packet radio, which transmits at 900MHz with 1W of power. That thing was pretty amazing, by using a directional patch antenna we were able to receive data at apogee.
 
With a cold start time of 30 seconds on the ground you at least have a chance at reacquiring signal in under a second. If not, then it will take more time.

Out of band RF interference can be controlled to some extent. A SAW filter on the RF input and/or after the LNA helps.
 
And actually, that is sort of our plan going forward. As I mentioned in Appendix A of the whitepaper, we're looking into developing a recording-only GPS system that can log the signals it receives for analysis postflight. This would get around any "sanity checks" on altitude or velocity built in to the GPS module. I'm not on that project at the moment, but I believe we're currently contacting another team that has done something similar.
 
You know of one that is small enough to fly in a rocket?
I have been thinking about building one for a while. Lacking a pressing need I haven't done much more than think. I have been procrastinating for so long that my chosen part has vanished. (SE4150) But the MAX2769 is still around. The tricky part is grabbing onto that firehose of data and recording it.

PSAS built some hardware using this IC a while back. They weren't happy with it: https://lists.psas.pdx.edu/pipermail/psas-avionics/2015-February/012557.html
 
The max2769 is a tricky part. It's clock and pll can't hit the center of the l1 freq apparently. Piksi got it to work. There are better recievers in the pipeline but they may not available to us easily.
 
There are some Cubesat GPS receivers without velocity or altitude limits, that you can buy for a few grand, much cheaper than $100k+ a few years ago.
 
Actually GPS velocity readings are as direct a measurement as position. They are a totally independent measurement. Velocity is determined by measuring the Doppler shifts and position is determined by measuring pseudo ranges.
Thanks Vern. I have been using GPS units for over 20 years and with all the details I had read did not realise that they had snuck this into their signal processing. Makes for a more robust measurement system. Thanks for pointing that out :).
 
Huh. I don't remember the exact time for a cold start, but I do think it was more than 30 seconds. Maybe it was due to RF interference, as we did have our transmit antennas kinda close to the GPS antennas. On the left, the yellow antenna is the BigRedBee 428MHz 300mW APRS transmit antenna. And right at the very top of the unit the black antenna is our Digi XTend packet radio, which transmits at 900MHz with 1W of power. That thing was pretty amazing, by using a directional patch antenna we were able to receive data at apogee.
Thanks Jamie, I had seen one of your team members wandering around with that directional patch antenna in the video and I was wondering what it was being used in conjunction with. Also, with reference to the BRB unit, don't you mean 100mW, not 300mW? I wasn't aware Greg made a 300mW "high power" 70cm unit.
 
Back
Top