Menu Sign In Contact FAQ
Banner
Welcome to our forums

Flying by ear vs. flying by numbers, and slow response of EFIS displays

10 Posts

With six hours of familiarisation/transitioning training and about 40 landings with my RV-7 under my belt, a few things are quite noticeable:

  • I did not realise how much I relied on the sound of the engine & prop to set power. In the Robins despite their CS prop, a change of the power lever also was accompanied by a change in sound in the cabin, so after my first lessons, I set power mostly by ear; same in the Piper Cub with its fixed-pitch prop. The RV-7 with its CS prop gives very little feedback when reducing MAP, and I still need to look a lot of the engine instruments to set the right power levels.
  • Glass instrumentation is not my favourite: As you can see on the cockpit photo below, the flight instruments comprise the two EFIS in the pilot’s field of view, which are mostly set up as PFD left, engine monitor right, with the real engine instrument (the VM1000C) in the far right and actually quite outside the primary field of view. I miss the quick feedback of the steam gauges of our Robins which gave an immediate impression of speed, sink rate, etc. The tape presentation gives a precise readout but lacks the overall visual picture.
  • Speed control: Everything happens massively faster than I was used to before. We did circuits at EHMZ yesterday the whole morning, and you have barely time after takeoff to throttle back and settle into the 700ft circuit; so I am still often overshooting by a 100ft or so the circuit altitude and POH downwind speed is mostly only achieved correctly at the end of downwind. Same then on final as the plane really likes to lose speed when approaching the flare. Was better handled on grass than on the wide asphalt in EHRD.

Still, tons of fun, and I am quite happy to learn to fly the plane more precisely than required by our very docile trainers!

EHRD / Rotterdam

Interesting, and for sure a neat installation job.

Would you say there is a delay in the “tape” (EFIS style) presentation, or is it just that it is harder for a human to respond to it effectively because the visual cues are so much smaller?

Administrator
Shoreham EGKA, United Kingdom

Peter wrote:

Would you say there is a delay in the “tape” (EFIS style) presentation, or is it just that it is harder for a human to respond to it effectively because the visual cues are so much smaller?

Both. The speed tape as well as the altitude tape to a lesser degree are digital and precise but lack the trend information and at-a-glance visualisation of a moving needle; that has probably been discussed to death anyway.

The engine display of the EFIS, if activated, lags quite a bit behind the change in e.g. throttle or RPM compared to the VM1000. It needs to be understood that the engine data in our plane are collected by the usual array of probes and transducers and fed into the FADEC boxes which provide an RS-422 stream to a serial bus converter whose RS-232 data output feeds the VM1000 and the EFIS. The EFIS (now 13 years old) seems to be a bit slower processing the data compared to the instantaneous readout provided by the VM1000 (which is unfortunately not in the primary area of visibility).

EHRD / Rotterdam

Something strange there because RS232 (this stuff is my day job) runs fine at 115200 baud which is ~10k bytes/sec so in this context “absolutely instant”. And RS422 at is least as fast. And any 232/422 converter is totally instant (I make these at work) unless it is doing some weird protocol conversion and not doing it well.

Is the baud rate configurable in your interconnections?

Administrator
Shoreham EGKA, United Kingdom

Peter wrote:

Something strange there because RS232 (this stuff is my day job) runs fine at 115200 baud which is ~10k bytes/sec so in this context “absolutely instant”.

That does not help if the EFIS’ serial port runs at 9600 8N1 … The problem with the whole installation is that due to the nonexistence of the respective manufacturers of the FADEC, engine monitor, and EFIS, anything in that list breaking will render the other items equally useless. And in the documentation I inherited, the protocol details e.g. for the FADEC serial link are not described at all.

A fun winter project would be a serial sniffer to try to decypher the FADEC protocol, as it would then be possible to create an interface to current EFIS (we have a spare set of FADEC controllers in the cupboard).

EHRD / Rotterdam

You just need a laptop running Teraterm, and a suitable serial to USB adaptor to monitor the data lines.

It may be obvious. Or, as my philosopher GF always adds, it may not

Administrator
Shoreham EGKA, United Kingdom

Peter wrote:

It may be obvious. Or, as my philosopher GF always adds, it may not

Right, and as my civil law prof. used to say “it depends”

In all seriousness, the task might be easier if they use at least a non-binary protocol. I played with the idea to start with the easy things such as disconnecting the MAP sensor, applying a range of known test pressures while not changing any of the other variables, and figuring out that protocol unit. Rinse, repeat with variables such as battery voltage, fuel pressure, fuel level, oil pressure, oil temperature. CHT I might be able to reproduce with a thermo-chamber, EGT will be more tricky.

EHRD / Rotterdam

I had a similar experience when I did transition from a C172 to a Beech F33A in the past. The C172 could be flown by feeling if it was right but the faster planes will require memorized parameters you set in certain situations. Then you no longer feel the need for analogue instruments telling you roughly where you are as you already know what the approximate speed etc. will be and you need the instruments just for tiny adjustments.

www.ing-golze.de
EDAZ

Sebastian_G wrote:

the faster planes will require memorized parameters you set in certain situations

I haven’t trained to that extent of muscle memory yet, and especially in the quickly-changing circuit training environment, I still rely a lot on feedback clues, be they sound or instruments. Fingers crossed that the weather stays alright, we’ve planned to switch Saturday from the grass at Midden-Zeeland EHMZ to the asphalt at Seppe EHSE.

EHRD / Rotterdam

Most good programmers, unless specifically trying to obfuscate, will go for a simple protocol where a specific character (which cannot occur within the data) denotes the start or end of a packet. This makes parsing incoming data easy, and deals with the case where there is some garbage to be cleared out following power-up. Anything else is a lot more complicated, but this method rules out a purely binary protocol.

Even at 9600 you can get a lot of data through. It’s 1000 bytes per second. Nearly all industrial data collection / control runs at 9600, with people going to 38k / 115k in applications where a lot of slaves have to be interrogated frequently.

Administrator
Shoreham EGKA, United Kingdom
10 Posts
Sign in to add your message

Back to Top