What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

EFIS Features ? the Information Revolution

User interface improvements...

I have been spending some quality time with the GX-55 GPS simulator the past few days. The GX-55 is what our CAP plane has in it, and it is essential to know how to use it to accomplish CAP SAR missions. I hate the critter but it is very similar to other GPS units so lessons can be learned from it. I am getting used to the GX-55 and the process makes me think that there must be a better way to do things.

1) I hate having to reach up to the control panel for almost any reason, including setting up the GPS unit. I just went up Saturday with a CAP friend and I let him fly us out of GRR. While he was doing that I realized I had taken off with the GPS off, so I needed to turn it on and get it started. Even with only mild turbulence and with the other pilot flying I found it to be borderline laborious and time consuming just to initialize the unit and enter a waypoint. The combination of having to hold your arm up and reach for the big knob / little knob and the turbulence knocking my hand away from the control or causing an incorrect entry was quite frustrating.

A better philosophy for cockpit design I think is to use the control panel primarily for display only. Don't make the pilot reach up to the panel to do anything. Put all user input controls on a console under the pilot's right arm. The arm is always resting on the console for stability and only the hand has to move to manipulate a few simple (software programmable) buttons, knobs or small joystick.

2) I hate the big knob little knob way of doing things whether it is the GPS unit or the radios. Voice control, right arm console, joystick, trackball almost anything would be better. It takes a lot of time at a simulator to learn how and when the two knobs are used for what and there are many cases (in the GX-55, for example) where an errorneous input leaves one in a state where it is not obvious how to clear the entry and start over. It is clear what the reasons were that drove the decision to use the big knob small knob (simple small control to manufacture and program) but I think experience shows it was a poor tradeoff.

3) Don't make the pilot have to do flight plan entry while sitting in the cockpit. The flight plan is usually known before flight time so allow for an offline (i.e, PC based) flight planning tool. The tool would allow all entry of the flight plan before flight while the pilot is sitting at a laptop in the pilot's lounge or whatever. Then transfer the plan to the flight computer with a flash drive or other portable memory device.

4) Provide an optional slide out QWERTY style keyboard under the control panel. It would be so much easier to enter indentifiers with a QWERTY style keyboard than with a big knob little knob or even with an MCDU style keyboard.

-- NM
 
Last edited:
It's all about software / hardware architecture...

Wow! Garmin better watch their back. Everyone else, just give up. . .

Cutting Edge Military Avionics : an oxymoron.

I have been doing avionics software development for over twenty years now and I am so tired of seeing it done badly. Especially now that I am a pilot. The stuff I have been discussing in this thread and the stuff that is out there in the market ain't rocket science. I can tell you that if you architect a software solution one way it will allow for rapid and simple improvements and modifications to be made in minutes to days. If you do it poorly (as is the case with most of modern military and civil avionics) then the difficulty to build, modify, integrate, maintain or certify grows at an almost unimaginable pace - years and decades.

Take what I am working on now. The 737 FMS started out as a FORTRAN program in the seventies. Around the early nineties, a push was on to recode it in Ada and apparently, they just took the FORTRAN and sent it through a translator to turn it into Ada. So now, you had poorly written FORTRAN code made into syntactically correct Ada. Little or no thought was given to the advantages or disadvantages of structured programming over an better object oriented approach, let alone component based, nor was any real thought given to how one would design for testability. But, they made it work and now all of our work for the past 15 years has been beating on this code to shape it into the next plane's FMS. So when it is time to add a new 429 channel or a new 1553 interface it can require touching as many as 80 files at a time. But, if this had been thought out a little better, with a better software architecture, it really should only take a one line change.

Software architecture is everything. It is the difference between two or three more senior software engineers being able to produce a HUD system for the JSF protoype in a few months or 150 mostly junior software engineers being able to produce a similar complexity flight display system for the 767 in a year. I was on both projects. For some reason it seems that almost every aerospace project I have ever been on or heard about has chosen to do things the very hard way. It's all about how to decompose the problem and how to then compose a solution to the problem with well designed components.

--NM
 
Last edited:
Feet per nautical mile

I'm not sure if it's been suggested yet, but do any of the systems support a display of vertical feet per nautical mile? It seems that this might be useful at times.
 
I'm not sure if it's been suggested yet, but do any of the systems support a display of vertical feet per nautical mile? It seems that this might be useful at times.

lol - reminds me of AF flight training. We learned to do it so fast in our heads that I don't even think about it any more.

1 degree = 100' per nautical mile - or close enough for government work. If you want to lose 1,000' in 3 nautical miles, plan on 3.3 degrees.

Conversely, you can keep your cruise airspeed in your head (mine is roughly 3 miles per minute) and decide how many minutes you want to take to do your descent. Need to lose 5,000 feet on an enroute descent? At 500 FPM = 10 min * 3 MPM = start your descent 30 miles before the point where you want to be level.

But, not everyone likes doing math in their heads...

:)
 
Yes, but no digits - GRT

I'm not sure if it's been suggested yet, but do any of the systems support a display of vertical feet per nautical mile? It seems that this might be useful at times.
The GRT flight path marker shows the angle of flight so you can maximize angle of climb, but it does not give a measurement (yet).

For the ILS, though, your vertical descent rate should be one half your groundspeed in knots for a 3 degree slope. 100 kts = 500'/min.

The Garmins (at least the handhelds) show a vertical navigation guide that you configure and they work whenever you get anywhere near your destination.
 
But, not everyone likes doing math in their heads...

:)

I don't even really do the math anymore! Just about every GPS (and EFIS) tells you the TIME to your destination, so you don't compute from distance and speed. Have to loose 8,000' from cruise to pattern altitude? Descend at 1,000 fpm, and start down a little before 8 minutes.

it almost takes all the fun out of it....;)

Paul
 
I'm not sure if it's been suggested yet, but do any of the systems support a display of vertical feet per nautical mile? It seems that this might be useful at times.

We have a glide and climb ratio indicator - does that help ?

If it reads 1:5 it means you are going to decend (or climb) 1nm for every 5nm horizontal gain. Of course you can plug in any units you like.

Rainier
CEO MGL Avionics
 
Killing More Fun

I don't even really do the math anymore! Just about every GPS (and EFIS) tells you the TIME to your destination, so you don't compute from distance and speed. Have to loose 8,000' from cruise to pattern altitude? Descend at 1,000 fpm, and start down a little before 8 minutes.

it almost takes all the fun out of it....;)

Paul

I should have been more precise. The Garmin 2-3-496 have a datafield that can be selected for time to VNAV which means when to start the descent at the selected rate to the selected AGL by the selected distance from the airport and it pops up on both sides of the map page a little glide guide (my terminology). It quits at 500 AGL with a notice - "approaching target altitude". It doesn't matter how far out or how high you are when you start down. You can use more or less airspeed as required and the guide still knows the sloped line you are following. It also, unlike an ILS can do this from any direction to the target.
 
Cutting Edge Military Avionics : an oxymoron.

I have been doing avionics software development for over twenty years now and I am so tired of seeing it done badly. Especially now that I am a pilot. The stuff I have been discussing in this thread and the stuff that is out there in the market ain't rocket science. I can tell you that if you architect a software solution one way it will allow for rapid and simple improvements and modifications to be made in minutes to days. If you do it poorly (as is the case with most of modern military and civil avionics) then the difficulty to build, modify, integrate, maintain or certify grows at an almost unimaginable pace - years and decades.

Take what I am working on now. The 737 FMS started out as a FORTRAN program in the seventies. Around the early nineties, a push was on to recode it in Ada and apparently, they just took the FORTRAN and sent it through a translator to turn it into Ada. So now, you had poorly written FORTRAN code made into syntactically correct Ada. Little or no thought was given to the advantages or disadvantages of structured programming over an better object oriented approach, let alone component based, nor was any real thought given to how one would design for testability. But, they made it work and now all of our work for the past 15 years has been beating on this code to shape it into the next plane's FMS. So when it is time to add a new 429 channel or a new 1553 interface it can require touching as many as 80 files at a time. But, if this had been thought out a little better, with a better software architecture, it really should only take a one line change.

Software architecture is everything. It is the difference between two or three more senior software engineers being able to produce a HUD system for the JSF protoype in a few months or 150 mostly junior software engineers being able to produce a similar complexity flight display system for the 767 in a year. I was on both projects. For some reason it seems that almost every aerospace project I have ever been on or heard about has chosen to do things the very hard way. It's all about how to decompose the problem and how to then compose a solution to the problem with well designed components.

--JCB


Don't take this the wrong way, but now I see why you think all of the current systems are lacking. You've been exposed to dinosaur era systems! Indeed the heavy iron stuff is decades out of date when it comes to both functionality, GUI's, software, etc.. when compared to what is out there in the experimental stuff. I wouldn't even classifly the Boeing/Airbus/Lockheed/et.al stuff in the same world as the Chelton/Garmin/GRT/AFS/etc.. out there right now.

To be honest, I still haven't seen anything you've discussed that isn't either completely or partially available in current systems (and even more). Sure the price may be out of sight, but don't say it doesn't exist because many of the features you've said don't exist in fact do, and quite well. I think if you got a good hard look in detail at something like the Chelton systems or the high end Garmin stuff you'd see that it's literally years ahead of the 737 era (even if it's NG stuff) that you're working with. Some of the Biz Jet stuff is pretty slick, but still hamstrung with some archaic certification rules.

I'm not trying to rain on your parade, because I truly would like to see what you end up with. But, having been around the block a couple times, I've seen more than one brilliant software (and some hardware) guy roll their own system with promises of it being the avionics panacea. You're not the first to try and you won't be the last, but 99% of the homespun systems end up being something that kinda/sort works - but isn't as good as anything money can buy right now. I'm not saying this will be the case with your system, but perhaps it would be a valuable use of your time to go fly behind a number of these systems with guys who are really competent with it before you universally discount all of them as being inferior.

I probably am speaking out of school here, so please feel free to correct me if I'm wrong...but I get the feeling you haven't been around this experimental stuff all that much? I think you'd find that some additional extensive research on curently available systems might yeild some surprising results to you. Perhaps they are too expensive, and that may well end up being your final justification (and a reasonable one at that I would agree), but I wouldn't say that your desires from a functionality standpoint are very far at all from what is out there. Perhaps in what you're working on yes, but in the experimental stuff no.

Just my 2 cents as usual. It's just an opinion so take it for what it's worth. No flames intended, just playing a bit of the devils advocate. :)

Cheers,
Stein
 
using what's there

In reading this great thread I keep coming back to the previously stated desire for good simulators for existing systems. Not only would they address operational issues but we could also then use forums such as this to address the data interpretation/useability issues. The flight path marker in the GRT being used to give information that answers previously unasked questions by the user is just one example.

I've always felt that much of the great potential of all these systems is potentially missed by the challenge of learning all of the DIFFERENT ways of using and interpreting what is already there.

If there was a simulator, I could put myself in an upcoming but unfamiliar situation and look at the box and ask "how can this help me in a way that I might not be aware of?"

As the G496 branch of this thread shows, I can't help feeling that missed existing features are a huge untapped resource for many existing systems!

Jeremy Constant
 
Back
Top