GPS vs Altimeter data

[yo3ict]

Hello,

I did a flight last year in July and yesterday I attended a flight by another team. I've been developing my own flight computers, which include barometric and IMU sensors, GPS and live telemetry on LoRa radios.

It seems weird to me but both of the flights exhibited a strange behavior : GPS apogee altitude is much lower than barometric altitude.

On the flight computers, the barometric altitude is compensated, with the following algorithm:
-I average a number of pressure samples at boot time and based on this average and a hard-coded launch site elevation, I compute the sea level pressure
-based on this sea level pressure and a hard-coded launch site temperature, the barometric altitude is then determined.

Sample rate from both barometer and IMU is around 100Hz.

My flight from last year : GPS apogee 2568 meters (8425 ft), barometric altimeter apogee 3100m (10170 ft), Constellations: GPS + Galileo
Yesterday's flight : GPS apogee 357 meters (1171 ft), barometric apogee 580 meters (1902 ft), Constellations: GPS + Glonass

The data takes into account the launch site elevation, as I have said previously, and the GPS receivers are uBlox M8.

Looking here : https://www.rocketryforum.com/threads/ublox-m8-test-flight-data.142704/ there is a graph that shows the GPS and altimeter altitude are converging before apogee. This is what I would have been expecting.

I must also say that when I compare the barometric pressures during both flights with the local met office soundings, it is the barometric altimeter which seems to be right on the money.

Can someone shed some light into what might be happening?

 

[WillMarchant]

GPS altitude isn’t all that good because of the geometry. Barometric readings are still better for precision things like takeoff and landing. I expect that may change with technology improvements.

 

[OverTheTop]

I don't think geometry is going to be an issue with GPS at most HPR launch altitudes. The satellites operate at around 20000km altitude, so a few thousand or even tens of thousands of meters will not materially alter the receive geometry. It will still be remarkably similar to that which applies on the ground and results in vertical accuracy being about a factor of three worse than horizontal accuracy.

 

[jderimig]

Look up the altitude given your pressure data against an atmospheric sounding for the day closest to your launch location.

Before you reject the SAM that almost every commercial altimeter manf uses and develop your own, verify it's a better algorithm

 

[yo3ict]

I have rejected SAM long time ago and I have verified my algorithm against sounding data and it yields very good results.

My question was a bit GPS-related.

Here is a plot from one of my flights (altitude in meters):


This was a supersonic flight so no GPS lock expected during the burn phase. It recovered just after apogee but the GPS data indicate that it was still ascending. And then there is that lagging of the GPS data behind the altimeter. They converge finally.

But this is nowhere near the behavior that I'm seeing here (using a Featherweight, I believe), where both altitudes converge right after the GPS re-acquires its lock :


Both devices are Ublox M8. On my flight, I was using the <1g dynamic model.

Any ideas?

 

[mikec]

I've used the M8 a lot and it's always been fine. Are you sure you have the right datum set and are doing that calculation correctly? Can you post your raw GPS data?

 

[WillMarchant]

I don't think geometry is going to be an issue with GPS at most HPR launch altitudes. The satellites operate at around 20000km altitude, so a few thousand or even tens of thousands of meters will not materially alter the receive geometry. It will still be remarkably similar to that which applies on the ground and results in vertical accuracy being about a factor of three worse than horizontal accuracy.

Here's https://geoawesomeness.com/accurate-altimeter-gps-watch/ an article that tries to explain why GPS altitude is worse than the horizontal position accuracy. Feel free to do a web search for "gps altitude accuracy" to get other viewpoints.

When I was writing autopilots for a NASA program we ended up using barometric sensors for anything that required "tactical" altitude accuracy, like when you're trying to sneak up on a runway for a gentle landing.

 

[mikec]

In my experience GPS altitude with the M8 is nowhere near as bad as the OP is seeing. The number of sats would be very diagnostic, you should see at least 8 typically. At 4 all bets are off as to the quality.

Flying a commercial baro altimeter as a sanity check would be useful. I assume that the simulated altitudes match the baro closer than the GPS?

 

[yo3ict]

I've sent you PM with the raw GPS data but I'm posting it here as well.

IMU data as well as met sounding data agree with the barometric altimeter curve.

 

[jderimig]

Use the 4g dynamic model. Track the pdop and vdop statistics around apogee and SV. Record the UBX logfile if you can and play it back in U-center. If you have a decent satellite constellation you GPS altitude should be within 100 feet worst case.

If you were indeed using the 1g dynamic model you might have had lock on a constellation low towards the horizon which are good for an accurate 2D fix but lousy for 3D. You need overhead satellites for that and will not get it with a 1g dynamic model.

 

[mikec]

If you were indeed using the 1g dynamic model you might have had lock on a constellation low towards the horizon which are good for an accurate 2D fix but lousy for 3D.

FWIW I've never used anything but the M8 default settings and not had this sort of problem. Maybe I've just gotten lucky with satellite geometry. Certainly using the 4g dynamic model would be preferable.

 

[mikec]

In post #5, your barometric altitude is not going to zero slope at apogee as it should, unless you had an early deployment?

I looked at the data you posted and the apogee GGA sentence looks reasonable and shows a value of 2303.8 meters ASL and a geoid sep of 34.2 meters so this site is close to sea level. 2303.8m is 7556 feet. The DOP is not bad (1.1m), 10 sats used.

If your baro altitude is really and truly right, then unfavorable sat geometry is the only thing I can think of. Without SV sentences you'd have to go back and look at ephemeris data to see what it was like on the day of launch.

Launch site is in Romania, correct?

 

[OverTheTop]

Here's https://geoawesomeness.com/accurate-altimeter-gps-watch/ an article that tries to explain why GPS altitude is worse than the horizontal position accuracy. Feel free to do a web search for "gps altitude accuracy" to get other viewpoints.

When I was writing autopilots for a NASA program we ended up using barometric sensors for anything that required "tactical" altitude accuracy, like when you're trying to sneak up on a runway for a gentle landing.

That article quoted I feel is quite lightweight and doesn't discuss geometry causes of position degradation. The quote “The earth blocks out satellites needed to get a good quality vertical measurement. Once the vertical datum is taken into account, the accuracy permitted by geometry considerations remains less than that of horizontal positions.” I think somewhat misses the point as to the cause of vertical error. She states that the ionosphere affects the pseudoranges, which is true, but doesn't mention the troposphere which has a similar effect. Geometry of visible SVs (space vehicles) isn't mentioned.

As jderimig stated you need a decent number of satellites high in the sky for better vertical determination. Imagine all the satellites on the horizon and the system would only be able to provide a 2D location with the height being somewhere on a vertical line.

Vertical error is largely due to the overlap of the pseudorange error bars being greater in the vertical direction than in the horizontal directions, with this being caused by the mostly acute angles between the satellite pseudoranges determined from the SVs.

Remember GNSS navigation (GPS is only one satellite constellation of the many available to use) uses trilateration, not triangulation. Think triangulation without the baseline. It relies heavily on determining the length of the path between the satellites and the receiver (pseudoranges). Horizontally we can have satellites on either side of our location which helps determine the lat/lon of our receiver. For altitude there is no nadir signal available (blocked by the Earth) and the error bars on the pseudoranges become more important in the determination.

That is my understanding of the cause of the higher HDOP. I am happy to be corrected if I have the wrong end of the stick.

 

[JoePfeiffer]

I'd want to also have a commercial altimeter on board. See if it matches your GPS, your altimeter, or neither.

 

[manixFan]

I'd want to also have a commercial altimeter on board. See if it matches your GPS, your altimeter, or neither.

This, plus a commercial GPS tracker as well. No one ever wishes they had less data to compare against for error analysis. If the OP has developed both the baro and GPS units, there could be errors in each that are divergent, or worse, are convergent in some instances, but not others. (Been there, done that, hate the t-shirt.) Until both are validated over a range of test conditions, you can't assume either one is correct.


Tony

 

[jderimig]

GPS uses the intersection of 3 spheres to determine your position and one additional sphere intersection to synchronize the receiver clock to the satellite atomic clock. Ionospheric correction is all done within the chipset now below 80km. There is no basis for vertical less accuracy than horizontal UNLESS the chip firmware biases the satellites used towards the horizon which is the optimum bias for the majority of consumer use cases.

But even with this bias ublox implies it tries to get at least one satellite overhead so that the vertical error is no more than 2x the horizontal error. So you should expect about 5m error in gps altitude.

 

[Adrian A]

There is no basis for vertical less accuracy than horizontal UNLESS the chip firmware biases the satellites used towards the horizon which is the optimum bias for the majority of consumer use cases.

Just because of geometry and look angles, when the GPS satellites are evenly sprinkled around the sky, about half of them of them are going to be 30 degrees above the horizon or less. In this random snapshot, there are 4 of 21 GPS satellites with more than 60 degrees elevation and 10 of 21 satellites with less than 30 degrees elevation.

 

[RocketPro]

The constellation doesn’t change in geometry very much during a typical flight so the fact that the solutions eventually converge make me think that you have a filtering issue going on. For a rocket flight, you probably want to set a high-dynamic mode so that the output solutions aren’t filtered as much. The Featherweight data that you shows a step change in the output that you don’t have…your changes are smooth which says “filter” to me.

 

[jderimig]

The constellation doesn’t change in geometry very much during a typical flight s

But the selection of satellites used by the receiver can change. If you select 1g dynamic range you will quickly lose the satellites you are accelerating towards that the receiver might have been tracking while it was sitting on the pad.

 

[RocketPro]

@jderimig…Agreed. A careful look at the mode and navigation settings to understand what the receiver is planning to do is probably in order. Also would be good to record the module’s internal status messages in addition to the NEMA strings to see what the receiver is actually doing. These modern units are very sophisticated which makes them sensitive to the configuration settings.

 

[yo3ict]

Thanks everybody!

I understand now that the dynamic 4g model relaxes the doppler constraints. With the constraint set too tight, the most affected sats will be the directly overhead ones, which are responsible for the 3D fix and vertical resolution. Sats near the horizon are not so affected by the doppler during flight but they are good only for a 2D fix.

For the next flight, I use a multi GNSS configuration (GPS + Galileo + Glonass, weekend testing shows that I can achieve 20+ sats). I'll also be using the NMEA GNS sentence instead of GGA (GGA is limited at 12 sats for backward compatibility reasons), logging more GNSS data for later playback within u-center and going with a 4Hz GNSS navigation rate.

 

[cls]

Late to this thread...

Baro is correct, GPS is just wrong.