How to build aviation software and why I quit flying to build a startup
eduardo.intermeta.com.br
eduardo.intermeta.com.br
Can your avionics GIS & time software handle this?
[1] http://www.worldatlas.com/webimage/countrys/oceania/lgcolor/...
I think the major problem with most processing is making the NMEA 183 protocol parser work in a real time scenario, this is hard.
The question I pose, and it's one your software needs to handle, is how well do you deal with that and are your ongoing results correct?
GPS near the pole gets more interesting as it pays to have your own translation (or one that you can trust) from raw sat packets directly to polar suitable planar mapping coords (as passing through anything [lat,lon] invokes the curse of singularity).
We had issues with essentially every bit of commercial map related software that took GPS produced [lat,lon] pairs - eg: ARCGIS (1997) when handed a chain that crossed the data line failed on all derived calculations (enclosed area, transient velocity, instantaneous headings, etc).
We were lucky in having fairly extensive in house software and no strict dependence on third party tools (eg: we didn't use Intrepid [1]) and having the ability to find all the points in the acquisition, processing, QC, presentation, and map production software that flipped out on sign inversion and recompiling to correct for those faults on the go.
The interesting realisation was just how many "professional" tools failed to work in that part of the world; see Wingman4l7's comments for a typical "if it works in North America that's all that matters" attitude.
[1] http://www.intrepid-geophysics.com/ig/index.php
I suspect we have different definitions of hard; text based serial comms protocols can be difficult to parse if you lack a complete specification from the outset or if there are ambiguities.
Hard is using Kalman filters on the fly to correct for the magnetic bias induced by a planes heading whilst correcting for diurnal magnetic pulsing and gathering multiple channels of radiometric data, watching ground separation radar and LIDAR, and doing differential GPS corrections against a base station and using temperature, pressure and humidity to estimate a standard air column density between craft & ground (for normalising gamma rays).
I enjoyed your blog and wish you well in your pursuits.
Luckily some of us can write our own mapping and avionics software.
Are you comfortable with developing avionics software that just won't work in some parts of the world? That seems a little shortsighted and a little dangerous.
The standards for avionics software are not geared towards average use in any case. They are geared towards worst case scenarios that have actually happened and could actually happen, even if the odds are low.
Are you honestly claiming that a popular bit of avionics kit will never find it's way to the region of Fiji? Ever?
If we're talking about avionics for Boeing passenger jets, that's one thing -- but those aren't going to be the same avionics that go into a Cessna 172 or a glider. That's why differing standards exist.
And no, I'm not claiming that -- that's what the giant sticker is for. If you're concerned about that sort of thing, make your hardware open and people can put on whatever custom firmware they like.
I'm certainly not talking avionics for commercial passenger craft, I'm talking about the avionics for routine global scientific measurements, geophysics, weather balloons, cheap drones, etc - all of these are application areas where roll your own avionics that aren't written by North American bound myopics are applicable.