Hacker News new | past | comments | ask | show | jobs | submit login
The Challenge of Flying Below Sea Level (avgeekery.com)
83 points by jpindar on May 24, 2017 | hide | past | favorite | 62 comments



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.


That doesn't make sense since most GPS units also include an altimeter. Plus, you can get an inaccurate altitude estimate from GPS itself.

I suppose it's possible that the unit doesn't include an altimeter or doesn't account for altitude, but that seems odd.


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.


Obviously, but how often do they actually do that?


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.


Helicopters?


Not their target market.


More likely the sensor data is all there, but the high level routine only checks for variation in latitude and longitude.


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).


Have you ever used a field GPS device? They are riddled with oddities and bad UX decisions.


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.


5M years ago parts of the mediterranean were 6,000 to 15,000 feet below sea level. Imagine flying that.

https://en.m.wikipedia.org/wiki/Messinian_salinity_crisis


Wow, I had no idea. Thanks for posting that. And it's going to happen again "soon" in geologic time...


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.


Also possibly to help with flying in these areas:

https://en.wikipedia.org/wiki/List_of_places_on_land_with_el...


There's got to be a joke along the lines of "QA guy walks into a bar, goes down to the cellar, orders -1 beers" somewhere in this story.


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.


I now want to plug in my Apple ][, load up lemonade stand and try that.


Me too. Just tried it, it filters out negative numbers.

https://archive.org/details/a2_Lemonade_Stand_1979_Apple


And it seems to have no obvious overflow issues. Either there are multiple versions or the claim that negative numbers work is simply wrong.


Might be more simple than that.

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.

Perhaps that version didn't check the input.

* https://web.archive.org/web/20130226024448/http://theodor.la...


Visiting the head is when I usually order -1 beers.


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?


> verified altitude of -750 feet, who cares?

Ah, altitude. I'll use an unsigned long.


Q: What are the internal units in the GPS system (overall, not necessarily an arbitrary receiver unit)? Like mm? radians?


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.


http://www.gps.gov/technical/ps/1995-SPS-signal-specificatio...

"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.


How are those not part of "the challenges of flying below sea level"?


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.


It is one of the long list of challenges, sure. To call it "the challenge" is a big stretch. My 2c.


So a falsehood a programmer believed about geography then?


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.


You are right. There have to be a lower limit.


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.


> the aircraft's software was designed to operate up to 400 feet below sea level.

I hope that's actually down to :)


QA Engineer walks into a bar.

Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.

Hug your QA engineers, they save you from eternal embarrassment.


> Orders a beer.

Beer delivered, but at the center of the bar, not to the customer.

> Orders 0 beers.

> Orders 999999999 beers.

Bar room fills up with beer, drowning everyone.

> Orders a lizard.

Bartender yells gibberish at customer.

> Orders -1 beers.

Keg explodes in taproom.

> Orders a sfdeljknesv.

Bartender complements customer on their fine taste in Hungarian beer.


Orders a NULL, orders "'); DROP TABLE Beverages;"


Why would anyone drop the Beverages table? I'd think the first target would be the Customer_Tab table.


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.


> orders "'); DROP TABLE Beverages;"

The bar gets flooded by the contents of hundreds of broken bottles.


A good developer looks both ways when crossing a one-way street. A good QA person also looks up and tests the street with a walking stick.


Which was the plane that allegedly had the bug that flying across the equator or international date line caused the autopilot to turn upside down?


They didn't flip upside down, but a flight of F-22s had a bunch of systems completely crap out when they hit the date line: http://www.defenseindustrydaily.com/f22-squadron-shot-down-b...

They ended up visually following their tankers back to Hawaii.


Only (somewhat) reliable references I can find are for an F-16.

From what I've read: if this happened at all, it was in the simulator.


In high-altitude ballooning we have to convince our GPS suppliers to turn off the altitude limiter at 80 km (some sort of anti-ICBM thing).


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.


Kind of related, an adorable instructional video about density altitude:

https://www.youtube.com/watch?v=ihee35QrWtk


They were lucky that the software wasn't naively using an unsigned int, or the altitude would have read 4294966055 feet.


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).


Both QA and the Software Engineer failed the catch this serious bug.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: