I'm reminded of a glider GPS failure mode I've heard a few times.
There's a phenomenon called mountain wave where strong winds at altitude get angled upward. When it's working right, a glider can point into the wind and ride it up like an elevator.
Some GPS units save you from running down the battery if you forget to turn them off by noticing you haven't moved in a while and shutting off automatically.
So you get into wave, point into the wind, ride the elevator up while motionless over the ground... and then, boop, your GPS shuts off because it thinks you're parked.
Whoever wrote the "am I parked?" code probably didn't think to check altitude, since when could an airplane possibly be moving vertically but not horizontally? A lot of these units are built for powered aircraft and then appropriated for gliders. I'm confident that software written with gliders in mind would not have this problem.
Actually this is quite possible in a light aircraft. If you're flying into a fast wind, you can maintain lift while also not generating enough thrust to negate the speed of the wind, leaving you hovering over a spot, or moving backwards.
I once sat in a commercial aircraft (only barely - a Do228!) which, landing straight into the wind, appeared to stand still and just touch down vertically.
Now, I know that this is impossible (no way the stall speed, even with full flaps, sensible AoA and near empty plane is lower than the wind speed at which the airport closes!) - but it definitely felt and looked as we simply gently dropped out of the sky, helicopter style.
The pilot suggested this was not uncommon practice when I asked him after we'd parked on the apron - fast, steady wind was what they encountered every day landing on these northern Norwegian islands.
Fairly often, given a light enough aircraft and strong enough winds. My grandfather used to like to tell the story of flying backwards (over ground) in a Luscombe 8A or 8B.
It seems like a GPS meant to go on an aircraft would support checking all degrees of direction before deciding to turn off or just not turn off at all since having an aircraft turn off any of its navigational aids seems really dumb. It sounds like he's using just a typical handheld GPS or one meant for a car instead of a real aircraft version.
There are cheap handheld aviation units that are not meant to be relied upon in any way, but just help out when able. You're never supposed to put yourself in a situation where losing them would create any safety risk.
GPS units that you actually rely on are built to a totally different standard (and price).
Most paragliding/hang gliding vario/altimeters shutdown after a few minutes sitting still. It basically assumes you have landed. That said, I am positive that my vario/altimeter considers altitude gain/loss on the equation.
I was in Israel last summer hiking with my kids at a spring (Ein Gedi) near the Dead Sea. We'd hiked up a trail and had gained maybe 500 ft of elevation. We were looking out across the Dead Sea toward Jordan when some Israeli military jets flew across above the Dead Sea and they were definitely at or below us. It was an interesting site being above the jets, and only later did I realize we were all still below sea level.
Ein Gedi is one of my favorite placed on the planet. There is (used to be, this is 20+ years ago) an amazing pool on top of the waterfall where we used to go swimming, and have this ridiculously beautiful view over the Dead Sea.
Why is -400 MSL the threshold? 0 would be the naive bug. I wonder if it's related to the geoid correction for altitude, which can be as much as -106 meters. That's close to -400 MSL. https://en.wikipedia.org/wiki/Geoid
In the old GPS selective availability "SA" days it was generally assumed you'd get vertical errors of about 1.5 times horizontal errors and SA added "up to" 100 meters of random error, so if you were at sea level and SA were turned back on again (WW3?) it would not be surprising to see -400 feet, but -500 would indicate a system failure of some sort because "obviously" there are no airports below sea level so set the firmware failure detector to -400.
Another thing to consider with modern avionics is this isn't a hand held Garmin or an iphone. There are two interesting military, and increasingly civilian, avionics features, GCAS ground collision avoidance system and TAWS terrain avoidance and warning system. GCAS theoretically engages the autopilot and pulls up if the plane is about to hit what it thinks is the ground. GCAS has already saved at least one F16 pilot's life, probably more by now. TAWS is about the same concept but rather than "don't hit the ground" its "don't hit the radio tower in front of you" which is somewhat more complicated to calculate both the danger and how to safely avoid it. Either GCAS or TAWS might have freaked out and "fail safe" design means you're better off shutting off or dumping into a reboot loop than letting something detected to be freaked out take over the plane. I specifically listed "or" because nothing fires off a fail safe quite like having GCAS report all is chill and calm while TCAS vehemently disagrees (or vice versa). I am a little unclear in avionics in general what happens when a GCAS and TCAS disagree. I guess TCAS only avoids obstacles by turning or climbing whereas GCAS only avoids obstacles by climbing (obviously?) so as long as they both implement that protocol they should never disagree. Unless there's a bug in only one of them below 400 feet.
Finally the verbal description of the problem indicates the nav gear failed after reboot but operated fine until reboot. My guess is the GPS firmware itself might have an "issue" in its acquisition firmware where obviously all positions below sea level are categorically unable to be accurate during acquisition mode so you can toss out any interim solution and keep acquiring if you find an altitude below -400 feet (see first paragraph). Or the GCAS or TAWS do the finite low pass input filter thing over multiple location data points where the last 60 seconds of flight data show a smooth descent to -1400 feet or whatever so thats perfectly fine because the boot up self test is not running while the system is booted, but on boot up during self test the input data filter having an output of -1400 is "obviously" a software bug so keep on rebooting until the input data filter has a reasonable value.
Seems like -400 ft was the number they picked to account for all the airports that are slightly below Sea Level (Amsterdam, etc), not taking into account this one geographical anomaly of a landing strip 1200 ft below sea level.
In the Apple ][ lemonade stand simulation game you could order negative quantities of supplies and your account would be credited without having to actually sell anything.
A piece of widely used Norwegian online retail software also did this for a long time. If you had a negative quantity of a product in your shopping basket, the value of the product would be subtracted from your total.
In the source of the Apple-published program, there's a comment that it was based on an earlier program from MECC* (you might remember them as the creators of Oregon Trail). That program goes back to 1973.
This reminds me of certain credit card signature pads that generate an error if you don't begin your signature in a particular area on the pad.
It's all too easy for designers to consider input constraints that (a) don't actually improve the user experience, and (b) don't actually make the downstream part of the system more robust.
If the user's signature is a chicken scratch and the GPS is reporting a trusted, verified altitude of -750 feet, who cares?
GPS data from a receiver is usually output using the NMEA format. The lat,long is reported in degrees, minutes, seconds, and the altitude is reported in meters. After the actual receiver calculates position, I'm sure this same data is just handed over to the part of the device so it can display your coordinates or pin point on a map. You can buy chips that will do all the GPS signal processing and positional math for you and just spit out NMEA data sentences for a computer to process.
"GPS operates in a well-de
-
fined set of coordinate systems, and all performance standard definitions assume their usage.
The satellite position and geometric range computations must be accomplished in the World Geo
-
detic Survey 1984 (WGS-84) Earth-Centered, Earth-Fixed (ECEF) coordinate system."
Later tables say that the ephemeris (not the user position) is broadcast in units of 2^-29 radians. Other bits of the table use "2^-31 semi-circles" - effectively a custom coordinate system that spreads the 2^32 bits evenly around a circle.
The title is a bit misleading, at least to me. I thought the article was about either physics of flying very low or flight-like motion underwater. Instead the technical bits are about software bugs appearing when altitude is below MSL.
It's a bug in a software package for a specific plane, not a general challenge of flying below sea level. I too initially read the title the same way and was then disappointed to read about a software bug.
The airport of Amsterdam (https://en.wikipedia.org/wiki/Amsterdam_Airport_Schiphol) is often used in test data because of its negative elevation. It is so well known that I can hardly believe that a certified aircraft has this kind of bugs.
If you notice, the nav system comes back at -300 MSL, so it's not as simple as "negative numbers don't work". They're inconsistent about negative signs, but I think the nav system fails at -400 MSL.
I don't know why it might handle some negative numbers but not others. Maybe there's an overflow somewhere?
It's probably hard limits set to make sure that the GPS doesn't display erroneous data due to a glitch in reception or whatever but as long as you are computing a running average of the position, those hard limits aren't really needed and only serve to create failures for weird edge cases like this.
It could also have been due to a confusion between metric and American units. The lowest airport on Earth as featured in the article is around 400 meters below sea level, but the aircraft's software was designed to operate up to 400 feet below sea level. It's a rather odd limitation that can't be explained by "duh, they didn't account for negative numbers" alone.
If you are a QA engineer testing to see if an input is injectable it hardly matters what you target database wise
If you are attacking with the intent of stealing information it would likely better to use the database injection as the foundation for multiple pivots into other systems that would presumably have more valuable stuff than a list of people who bought a beer and or their credit card numbers.
Possibly related to conversion to/from https://en.wikipedia.org/wiki/ECEF which uses ellipsoidal height (Geodetic), potentially in ways which would be problematic for negative values.
Assuming an unsigned int is 32 bits large. Never assume the size of an int; this is what uint8_t, int8_t, uint16_t, int16_t, etc are for. The only thing the standards say about the size of an int is that it must be at least as large as a short, which must be at least as large as a char, which must be 1 byte. Even then, 1 byte is not necessarily 8 bits (but it is in POSIX).
There's a phenomenon called mountain wave where strong winds at altitude get angled upward. When it's working right, a glider can point into the wind and ride it up like an elevator.
Some GPS units save you from running down the battery if you forget to turn them off by noticing you haven't moved in a while and shutting off automatically.
So you get into wave, point into the wind, ride the elevator up while motionless over the ground... and then, boop, your GPS shuts off because it thinks you're parked.