A couple of weeks ago, Kevin flew a new Raven4 altimeter together with a Featherweight GPS unit with the latest software, which performs 10 Hz data logging. We're still working on getting the logged data down through the phone, but in the meantime, here is data that was recorded and downloaded another way.
First up is altitude vs. time, which shows that we had good GPS data throughout the flight, and good accuracy performance from the Raven4's new accelerometer.
The difference between the accelerometer-based apogee altitude and the GPS AGL altitude was 1%, closer even closer than the baro-based altitude, which is about 2% low, due to flying in warmer conditions than the standard atmosphere model assumes.
The Featherweight GPS tracker only logs GPS points to the file when they pass the GPS receiver validity checks, so all of the points you see in the graph are valid data. 96% of the possible GPS measurements were valid in this flight. The next plot shows how many satellites had strong, good, and acceptable signal strength during the flight:
During the boost, the receiver lost lock on a few satellites, but still had enough for a solution throughout the flight.
The graph below shows that the new U-Blox 8th-generation receivers are great at velocity measurement as well:
There is excellent agreement between the Raven 4's acclerometer-derived velocity and the GPS velocity. The GPS provides the velocity in 3 dimensions relative to the ground, while the accelerometer only knows what the velocity is in the direction of the rocket, wherever it's pointing (assumed upward until apogee). This is potentially a big advantage for using GPS for measuring velocity, since it also can be used to calculate the flight angle, as shown above. You can see that during the boost the flight angle was around 3 degrees, and stayed under 10 degrees until 16 seconds into the flight. At apogee, the flight angle is 90 degrees (by definition) At some point I'm going to make a combined GPS tracker/altimeter that uses the GPS-based flight angle as a safety check for airstarts.
If I may make a suggestion here... an exponential back off might be an interesting idea to explore. Halve frequency of broadcasts after some amount of time, then halve them again after a block of time, then halve them again... etc. Maybe stop when you get out to some ridiculously long time between squaking... possibly make it user configurable what the slowest update frequency once the rocket is at rest will be? I know if I'm the only one at the club flying with your stuff I'd want a longer time than if there were dozens of others that could possibly see it while in the air. The longer it's been, the less likely that someone will be coming over the horizon *right now* looking for it. I'd even suggest powering down GPS once the tracker is "at rest" to save battery for broadcasting.
