And remember that Fiji is an archipelago of more than 332 islands that spans the international date line [1] meaning any sightseeing flights have fair chance of wandering backwards and forwards from -179.9 to +179.9 Longitude repeatedly in the same hour or two.
Can your avionics GIS & time software handle this?
Yes it is. But you don't actually have to deal with such things, results are given to you by the GPS receiver. (also, you don't really need to reinvent the wheel, those calculations already exists)
I think the major problem with most processing is making the NMEA 183 protocol parser work in a real time scenario, this is hard.
Eduardo, the results given to you by a GPS receiver (depending on what level of massaging it does to the data) are chains of [latitude, longitude] pairs. At some point that chain will cease to be trivially continuous and have a glaring jump from -179.9 to +179.9.
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?
Yeah, sure. But this is really not something that someone needs to reinvent, the basic 'algorithm' is even taught in private pilot classes. Did you ever had any problems with GPSes in that region? (I got interested)
We had no issues with either commercial GPS units nor with in house GPS units that recorded raw (from the satellite packets) apart from the usual ones (separation of the geoid from "sea level").
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.
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.
And that's the kind of thinking that resulted in pretty much 100% of North American produced commercial mapping software just not working in the region of Fiji when it was mapped in 1997 [1].
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.
I'd be fine with that if it meant that the avionics software was cheaper because it cost less to develop. Your average private pilot in North America is never going to need their avionics to be able to deal with this, just like they don't need the GPS in their car to be able to deal with it either.
Don't be lazy, just consider the case of crossing a discontinuity and deal with it correctly, if you're on a roll developing it doesn't increase the cost and it offsets liability later.
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?
What about compass anomalies when flying around the poles? What about flying at extreme altitudes?
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.
When flying, navigating or surveying in polar regions it pays to have control (or an understanding) over the translation from raw sat packets to polar suitable coordinates, when flying at extreme altitudes it pays to have the same as numerous commercial GPS units have altitude and/or speed cutouts.
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.
12 comments
[ 3.6 ms ] story [ 38.1 ms ] threadCan 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.
[1] http://www.mrd.gov.fj/gfiji/products/air_detl.html
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.