This is the very long tail of non-metric conversion that drives me insane.
This date format is unforgivable:
"td_id_fltdata_date": "00181219",
(1) add in leading 00 to allow for Y2k expansion (and then ignore it)
(2) DDMMYY This is unnecessarily "difficult" for a human and a computer to sort and parse. Using ALL the same number of digits and following ISO 8601 already solves this (and with the padding 00's you don't need to touch this part of the software for 7900 more years!)
20191218 - Done.
This can only be a holdover from a pre-PC era.
Some industries move at a glacial pace when updating standards and tools. The risk to lives because of screwups (i.e. a faulty radar at Air Traffic Control) is too great to do without sufficient study and experimentation. But this can only be an unwillingness to change.
The timezone also seems to use the same 'set some high flag bit for negative'-derived approach as the coordinates. But it's a float... converted to a string...
> (2) DDMMYY This is unnecessarily "difficult" for a human and a computer to sort and parse
eh? it's trivial for humans to parse. Most of the world uses that format in day-to-day usage, albeit with some kind of separator of course. it's also absolutely trivial for a computer to sort and parse, of course. saying it's "unnecessarily" (to redirect the quotes) difficult, you may as well say decimal itself is unnecessarily difficult. just use day of year, 1-365.
you're splitting hairs here that don't need to be split.
To be fair nobody* actually uses final ISO standards even if they refer to them. I think JPEG is an example of where the "draft" became the de facto official standard because that's what everybody used instead of paying for the actual standard.
There are certain industries where you need to care. Or many lives will be lost because of it. Always follow the standard, even if it takes extra time to implement.
These are not open-standards. These are not self-documenting, csv, receiver-has-to-guess formats. These are two on-board non critical systems talking to each other. The main requirement is that the format be specified.
A desirable trait is that the format be easy to implement. Sorry, ISO 8601, you're too complicated for the task. Integrating a library to handle it is already too hard, too risky and over-engineering. You'd have to either trust it to be bug-free or heavily test it.
Panasonic holds an almost monopoly on aircraft inflight entertainment, especially on widebody planes. They run redboot Linux and have a pretty strict firewall between the plane and computer. All of what the author did was expected by the Panasonic devs hence the disclaimer.
Ads-b carries a lot of this data (at a lower interval) and is available to anyone with an antenna. Sites like FlightAware will republish it as graphs or maps. There also exist apps that take ads-b data and renders flight data in a google earth type view.
A part of me is really excited that we live in this time, but I’m living in constant fear that open data will disappear one day, so enjoy while you can!
> Panasonic holds an almost monopoly on aircraft inflight entertainment, especially on widebody planes. They run redboot Linux and have a pretty strict firewall between the plane and computer. All of what the author did was expected by the Panasonic devs hence the disclaimer.
Probably got tired of people reporting it as a vulnerability and added the disclaimer.
Fun fact: a gentleman on a united flight found this data and tweeted saying he hacked the plane. An investigation kicked off and this disclaimer was added.
Unrelated-but-related: why is it that the in-flight-status screen on the IFE or WiFi flight status page sometimes stops and simply shows the plane fixed and unmoving?
Background: I’m a terrible flyer (I’m okay with turbulence, but unexpected manoeuvres really spook me), so on a recent SEA-ORD night flight I woke-up as we were approaching a O’Hare - doing a 180-degree turn over Lake Michigan so it was pitch black outside the window, but the IFE map showed we were over South Dakota where the flight should be straight and level, no turns for hours. So for more than just a brief moment I was convinced the plane was starting to spiral out of control like Lauda Air 004 - or it was a pilot suicide like Germanwings 9525. It wasn’t until a minute after Chicago came back into view that the IFE map refreshed with our current location. My friend I was travelling with said the map froze an hour earlier.
Paranoid me thinks that if something were to go wrong with the plane that the pilots or flight attendants would shut down the IFE map or have it show false information to stop passengers from panicking. (Why yes, when I was younger I did believe the urban-myth about the brace-position only being there to preserve your jawline for later body identification through dental records)
Hi I don’t like responding to all messages in a thread I started.. but since no one else is, there are a zillion reasons why the map stopped updating. But fun fact, you didn’t actually know the plane was doing a 180 turn unless someone told you. In the pitch black or in clouds without reference, your brain loses sync of its inner ear balance and starts making up directions. You could be in level flight and your troll brain will tell you you are descending in a high rate spin. If you look at your instruments you’ll know this is a lie, but it is very difficult to overcome.. passengers don’t have instruments so troll brain fills the gap. This is also why flying into clouds who are not prepared is fatal for pilots.
That’s not why I responded tho, I responded because I used to be just like you. I hate turbulence, more importantly I hate negative Gs. It’s not normal and so your brain creates scenarios but the reality is, it’s just a pothole in the sky. One thing that made me get over my turbulence fears was getting into a simulator (or behind the controls of a real plane if you find the opportunity). I did exactly what the I hate so much. Over power the takeoff and pushed forward on the yolk to compensate and keep a slow climb. If I were a passenger I would have felt like we were climbing at a fast rate and then suddenly dropping as I corrected. My wings weren’t level until I hit autopilot and throttles fell back to 20%, passengers would think we were falling out of the sky because thrust disappeared and engines went quiet. Then I set the flight level and the throttles picked up again and we start climbing normally, calm and relaxed passengers again. I broke into a hysterical laughter and realized all of my flying fears stemmed from not only a lack of control but a lack of understanding what’s happening in the cockpit.
Watch some YouTube videos from the cockpit of cross country airbus or 737 flights. Watch turbulent landings and what the pilots are doing. In America, pilots are seriously over trained and know their craft like the back of their hand (source: pilot neighbor). Sit back and relax, sip some wine to ease the nerves. Flight is the safest mode of transport.
This suggests that a leading 8 (strangely in decimal rather than hex?) means negative sign. So your departure time zone was UTC-5 and your destination time zone was UTC+1.
The 8 is a negative. i.e. it turns N into S, and E into W.
The last 5 digits are in DDM format, the first two being degrees, and the last 3 being XX.X minutes.
You can verify this using https://www.pgc.umn.edu/apps/convert and plugging in the departure and arrival airport coordinates. The arrival long/lat matches up with the exact coordinates for AMS airport in the same format. This isn't true if you interpret the coordinates in another standard way from what I can see.
Edit: Your interpretation would suggest that PHL airport is in the Indian Ocean.
> Your interpretation would suggest that PHL airport is in the Indian Ocean.
Depends on how you use the numbers. If you assume the ~0° as W and the ~80° as N, that puts it over Greenland, which can be on the flight path between Philly and Amsterdam.
I missed the context of it being the specific coordinates of the airport, rather than on the flight path between, otherwise I’d have probably came to the correct conclusion on formatting like you did. Ty!
For this one, we know what the answer is since this was the "departure" location, which we know is KPHL. When decoded in assuming it's some odd DD mm.m concatenation and assuming the 8 indicates a negative, it results in being a point on runway 27R/9L of the departure airport.
Would be cool to be able to see some kind of a "geek passenger instrument panel" with this information during flight. This would definitely influence my choice of an airline.
Yeah for a while a few years back some airlines would include the camera view of the aircraft from the in seat screen.
With the transition to wifi entertainment that seems to have been lost, but would be pretty interesting to make a timelapse or be able to create a personalized dashboard from the raw data.
That, and sometimes you could listen in on the radio traffic.
Which was awesome until that time across Newfoundland, when someone started asking about the heavy turbulence. The other aircraft in the vicinity had no consolidation, recommending to “strap’em in and ride it through”. I spent the next several hours waiting for my worst flight, which never even happened.
General aviation Pilots use an app called foreflight that has a ton of flight data. You can use it on a commercial flight. It is very interesting but expensive if you’re just using it as a commercial airline passenger!
WingX Pro VFR is $0.99 per year and probably gives you enough to be entertained at a much better price point. (They have higher level subs if you’re actually flying.)
Found the same thing a few years ago. Was a fun pastime getting the eta up on my desktop environment's status bar without having internet based documentation. From memory I used curl and jq.
I have always been shocked how accurate altimeters are. Although I understand the math and physics, I am intuitively shocked that a device can measure differences of 10 meters.
This date format is unforgivable: "td_id_fltdata_date": "00181219",
(1) add in leading 00 to allow for Y2k expansion (and then ignore it)
(2) DDMMYY This is unnecessarily "difficult" for a human and a computer to sort and parse. Using ALL the same number of digits and following ISO 8601 already solves this (and with the padding 00's you don't need to touch this part of the software for 7900 more years!)
20191218 - Done. This can only be a holdover from a pre-PC era.
Some industries move at a glacial pace when updating standards and tools. The risk to lives because of screwups (i.e. a faulty radar at Air Traffic Control) is too great to do without sufficient study and experimentation. But this can only be an unwillingness to change.