(LCD screen : last updated by Benjamin on Decembre 16, 2022)
The selection of which LCD screen to use will depend on many factors. The connexion interface is the first to consider, followed by availability and quality of libraries, then brightness. The size and definition will depend on the software application using the screen and the space available on the instrument panel. For an EFIS or an EMS, to ensure excellent readability in all circumstances on the instrument panel, a size of 4.3 to 5 inches, a definition of 480 × 272 pixels or more, and a minimum brightness of 500 cd/m² are a good compromise. IPS technology offers much wider viewing angles.
Touch screen or not? It is a matter of personal choice: during flight, finger selection of a small screen area or menu option may be difficult during turbulence on a 5-inch (or less) display. Other control systems can be considered, such as push buttons, rotary encoders, or joysticks, often more precise than a capacitive touch screen. The latter also has the disadvantage of being glossy, while an anti-glare mat screen is much more readable under direct sunlight.
LCD screen interface
There are several display interfaces, including HDMI, parallel, and serial, to cite the most commonly used.
HDMI interface
Microcontroller boards never embed an HDMI-type display connector. Single board computers, such as the Raspberry Pi under Linux or the LattePanda under Windows, have such an interface. There are many others. But computers, particularly their operating systems, are hardly compatible with power loss; they must be powered off cleanly.
Embedded systems need to be designed so that any unexpected power loss (such as switching off the master switch on an aircraft) will not cause corruption in the operating system or data loss from the application software running on the device.
To be operated safely in an embedded application, a single-board computer requires measures to secure its power supply (such as this one for Raspberry), which gives the operating system the necessary time to shut down properly. In the context of a DIY project, the system is, therefore, more complex and at increased risk of failure. Microcontrollers are better suited to embedded tasks; turning off the power is their standard shutdown procedure. In addition, 5 inches or less, sunlight-readable HDMI displays are rare and seldom orientable in both portrait and landscape mode. For these reasons, HDMI displays are neither suitable nor easy to use in our avionics applications. The graphics computing power of a single board computer, associated with graphics software such as Processing, is undoubtedly much greater than that of a microcontroller … But we will see that there are alternatives.
Parallel interface
With parallel interfaces, each bit of each color (red, green, blue) is transmitted on a separate line. So 24 lines are required if each color is coded on 8 bits, plus several other lines for vertical and horizontal synchronization. Many microcontroller boards do not have a sufficient number of pins. A few rare (and expensive) prototyping boards use a high-end microcontroller that embeds a high-performance graphics controller. Few of these boards expose a parallel interface via a suitable output port, for example, the MIPI-DSI port on specific STM32 boards or the Arduino Portenta. These boards are instead reserved for industrial and professional applications; they go a little outside the field of “DIY,” i.e., the domain of the amateur to whom this site is intended. The display screens adapted to these boards are rare, often not very bright, and the libraries are inexistent or inaccessible… The advantage of such parallel RGB graphics controllers is their high refresh rate (50 frames/second and above) combined with double or triple frame buffering. These features ensure perfect display fluidity without any flickering. These controllers require a lot of resources, especially memory, but it allows fast animations without the slightest flicker. Unfortunately, this type of interface hardly meets the essential principles of the specifications on the home page: simplicity and economy.
Serial interface
This is the most suitable category of interface for microcontrollers. Screen serial interface can use i2c or SPI protocol.
I2C
I2C can control a device with just two I/O pins: SDA and SCL. Several devices can coexist within a network on the same bus, as long as they have different addresses. This bus is relatively slow, ideally suited to sensors, less to screens. Some alphanumeric monochrome LCDs, such as the one in Figure 1, although having a parallel interface as standard, can be connected to an I2C bus using a parallel to I2C interface board located on the back of the display. To display a few lines of text, the I2C bus is more than sufficient. A screen of this type could have its place in avionics, for example, to display some engine parameters, the position of a trim, the settings of an autopilot, etc.
SPI LCD display screen
Due to the rudimentary and somewhat outdated aspect of monochrome alphanumeric displays, color graphics displays are generally preferred. Especially since their cost is often equivalent. TFT technology is by far the most widespread. SPI connection is the rule. TFT displays with SPI interface have various controllers: ILI9341, ST7735, HX8357, and RA8875 … to name a few. Their sizes vary from less than 2 inches diagonally up to 7 inches. Their definitions range from 128 x 160 to 800 x 480 pixels, sometimes with a touch interface.
The SPI interface is significantly faster than the I2C one; it uses four wires: MISO, MOSI, CLK, and CS. It suits these TFT screens and personal avionics systems’ needs. However, this interface has some drawbacks compared to parallel interfaces: there is no possibility of synchronization between the microcontroller and the timing signals of the display. In addition, the controllers of these screens do not embed multiple frame buffers. This can lead to annoying flickering phenomena on fast animations, manifested by flickering, dark lines, or bands that scroll vertically. The animations are to be used sparingly. The best way to remove any flickering is to update only the areas of the screen that change and keep those areas as small as possible. These prevention principles are impossible to apply in the example of video 1, where a large circular surface is moving. The circle is successively displayed, then erased by drawing an identical circle with the background color (here black), then displayed again in green at the next location: flickering guaranteed! You should not think of programming a video game with moving sprites using a microcontroller and a TFT SPI screen!
Fortunately, avionics displays can do without sprites. However, displaying the artificial horizon of an EFIS can be a real challenge. It is necessary to display many textual and graphic objects (which may vary quickly) on a mobile background representing the sky in blue and the earth in ocher. To overcome this difficulty, for our EFIS project, we chose to use a display equipped with a RA8875 controller. The latter serves as an interface between the microcontroller, to which it is connected in SPI, and the LCD-TFT panel to which it is connected via a parallel interface (Fig. 2). The RA8875 allows two different layers to be managed separately, each with its dedicated memory, which brings it closer to the principle of double frame buffering. This controller also benefits from an exceptionally efficient and fast library optimized for Teensy boards.
The main drawback of this library, which is the price to pay for its speed, is that it does not handle attempts to display pixels outside of the coordinates allowed by the screen definition. It is up to the programmer to either manage these overruns at the cost of slowing the calculations or to avoid them. The second solution was chosen, which led to making a small concession on the usual appearance of an artificial horizon: the pitch graduations rotate with the horizon, but do not move vertically with it, see video 2. A better solution might be adopted later…
The EastRising / BuyDisplay displays have a few additional functions that are not useful for our projects: micro SD slot, SPI Flash memory, and keyboard slots. In addition, they show a certain tendency to malfunction, for example, when the SPI connection exceeds a few centimeters or when a solderless breadboard is used for testing. Incomprehensible black screens are not uncommon. For these reasons, we prefer to use the far more reliable Adafruit RA8875 controller and a separate panel, like this one and that one that have the significant advantage of IPS technology (Wide Viewing Angles). This allows greater flexibility in the arrangement of elements when installed on the instrument panel. Indeed, the RA8875 controller board can be integrated on the same PCB as the Teensy board, which guarantees the most reliable and shortest possible SPI connection. In addition, unlike the SPI connection, the parallel connection (40 conductor FFC cable) between the RA8875 controller and the LCD panel can be extended without inconvenience thanks to a 20 cm extension (Fig 3). See EFIS page.
High-brightness 5″ LCD panels require more backlight power current than 4.3″ panels. For this reason, it is necessary to solder the two pads labeled “+100mA” on the back of the RA8875 controller (fig. 4).
Hi Robert,
Thank you for your kind comments and interesting suggestions. Actually, I installed my aircraft’s electrical system according to Bob Nuckolls’s (Aeroelectric) recommendations, so I have almost no circuit breakers; instead, I mainly use fuses. It’s a fairly simple installation, but very effective and, above all, very safe and secure. And the space on my instrument panel is limited. That’s why I didn’t include a rotary encoder, even though it’s true that it’s more practical for adjusting a numeric value.
The benefit of sharing this type of project is also that everyone can then adapt it to their own constraints and wishes.
I really need to take the time to translate the EFIS-EMS page into English. The ESP32 display section of this new project is ready, and I’ll be able to publish the electrical schematics and Gerber files soon. I’m currently working on the interface board with all the aircraft’s sensors.
Hi Benjamin.
I was looking at your new version on the French site.
I see you have 6 buttons in a frame, I think buttons will be a tremendous advantage over just touchscreen but it would be nice to have both.
I suggest having two or three (or 4) rotary encoders for remote vhf radios and intercom settings, and expand the number of buttons so that, perhaps in the future, they could also be programmed to control electronic circuit breakers. I could see selecting a “button function page” which puts them in electronic circuit breaker mode, displays the breaker label, current limit, ipresent current draw, condition (flipped, on) above on the screen and then long pressing the button allows you to set the current limit of the breaker using one of the rotary encoders, short press would reset the breaker.
Once the switches and rotary encoders are there they can be programmed to do whatever is necessary / desired by the owner / user.
I am sure you’ve considered this and I guess if you are 3D printing the frame it doesn’t matter much what you put on it initially.
Robert,
Thanks again for your comments and suggestions.
Indeed, I’m sure there are plenty of 1000 nits displays on AliExpress/Alibaba; perhaps most are touchscreen (i.e., glossy) and not necessarily IPS (which I think is helpful in an airplane). I agree that touchscreens on an instrument panel can be challenging to use in turbulent conditions.
Our first EFIS-EMS prototype utilized a touchscreen, which is visible on the French page (not yet translated). But the second, as seen in the photo I posted earlier, has a 6-key mini-keyboard.
I purchased a Newhaven Display for my tests to ensure the quality, but if everything works as I hope, I’ll need to find a less expensive solution later, likely on AliExpress or Alibaba.
We share the same reservations about Python, which isn’t really suited to developing an aeronautical graphics application. I tried using Pygame on a Pi 4, and it was horribly slow. It was faster and smoother with Processing, but using the CAN bus and even the UART was not very easy. In comparison, it is relatively straightforward with a microcontroller, such as Arduino, Teensy, or ESP32. Moreover, for the latter, the ESP-NOW protocol and LovyanGFX library are significant advantages.
My PI 4 is now relegated to the sole role of running… Pi-Hole at home! With an excellent success in limiting unwanted publicity. Indeed, a Pi Zero 2W would have been entirely sufficient for that task!
Benjamin
Hello again, Robert,
Actually, I haven’t been home for the past few days and haven’t had time to reply to your message of September 22nd yet.
I’m, of course, familiar with various widget libraries, especially those from huVVer. But it’s not necessarily easier to use other people’s libraries and modify them to suit your own needs rather than starting from scratch to get exactly what you want. That’s what I did for the EFIS-EMS currently in development. By the way, I’ve started writing the French page for this EFIS-EMS, but I haven’t yet found the time to write the English version; that’s, of course, planned.
I’m not familiar enough with embedded versions of Linux that do not have the “power loss” issue, so I have a hard time responding to this specific point. In fact, I don’t have any particular reluctance to the Raspberry Pi – Linux system. Rightly or wrongly, I just have the impression that we can do just as well, and above all simpler, lighter, more reliable, easier to use for readers not necessarily familiar with Linux, with microcontrollers, in particular with ESP32 screen controllers and the LovyanGFX library, which is an improved version of Bodmer’s TFT_e-SPI library. It is also for this exact reason that I probably did not search enough, and therefore did not find the right matte, non-touch, IPS, sunlight-readable screen for the R-Pi.
Benjamin
Hi Benjamin.
Thank you for replying. I saw that display of yours, it looks very good and I look forward to seeing your updates. Thank you for your hard work.
Re – daylight readable displays…there seem to be a lot (that claim to be) 1000+ on AliExpress and Alibaba, although I have not checked all the interfaces but I am researching.
Re – File system corruption on the Pi … there are at least 3 RTOS, read only root file systems available for the Pi in the open source community. This would obviate the need for LifePo4 batteries, would it not ?
The one thing I much prefer of your development is that it is in C++/C, rather than Python which, to me, means better performance, which is why I am much more interested in your efforts than Makerplane, whose pyEFIS is, … in Python 🙂
I already own a couple of Pi’s, one of which I made a “tablet” out of with a 7″ touch screen, in addition to my Stratux device. The one thing I think really is hard to manage in an aircraft is touch screen…my experience here is with the Garmin.
I also have Arduino MEGA and ESP32s now although my ESP32s I am currently developing orchard heater remote monitoring and control. It’s been a while since I did anything at this low level so I’m not going to get anything completed in a hurry but I will setup a development environment and reconnect to github and get a copy of the code so that I can begin studying and understanding it as time allows.
Hi Robert,
Thank you for your comment.
We tested the R-Pi, HDMI, and Processing combination, which allowed us to achieve a beautiful, highly responsive graphical interface. However, on the one hand, it was almost impossible to find an HDMI display bright enough for aeronautical use. On the other hand, in our opinion, adding an uninterruptible power supply with a LiFePO4 battery would introduce significant complexity, bulk, increased cost, and a higher risk of failure, so we decided against pursuing this path.
The Teensy-RA8875 system is straightforward, but it doesn’t allow for such professional-looking graphics, and it’s pretty complex to avoid flickering.
The relatively recent advent of ESP32 displays, such as those used by huVVer, combined with the LovyanGFX library, makes it possible to combine a sunlight-readable display with high-quality graphics and animations, featuring smooth, flicker-free animations. Therefore, this is the path we chose to follow. We anticipate being able to conduct flight tests and publish our results on the website within the coming weeks.
Since commercial ESP32 displays are glossy, which causes a lot of reflections, and they’re never bright enough, we developed our own ESP32-S3 controller to pair it with a non-tactile 1000-nit matte IPS display, usable in direct sunlight on an instrument panel. The picture below shows our EFIS-EMS prototype on a single 7-inch 800 x 480 Newhaven NHD-7.0-800480AF-ASXP display.
More details will be available on the website very soon.
Benjamin
There are a number of open source rtos embedded linux versions that do not have the “power loss” issues mentioned.
There are loads of open source widget libraries.
The Pi4 is pretty cheap.
There are loads of high brightness TFT displays available with various interfaces.
Why the reluctance to use the Pi ? I don’t get it.
Avilution have an EFIS system with a 17″ display and, I think, 1900×1200 with much higher brightness (things change quickly in this business :)).
I would like to emulate their size and format, particularly as I am building a Zenith 750 SD with an Unpanel(tm) arm designed for the Avilution device.
While I have some electronics experience and a career of s/ware development experience, I’m almost obsolete but like a challenge.
The newer Stratux iso uses a read only file system to avoid the corruption common with power loss before shutdown. With this in mind, would it not be cheaper to use a pi4 or 5, even with the cost of the Pi, to run an hdmi (or other common interface), with the Pi ?
I am really interested in EAB avionics and digging into it all over the place and it seems to me you are way ahead of everyone else in this space, with the possible exception of Huvver but they seem to be replacing 6 pack instruments with configurable six pack instruments rather than a single EFIS/EMS display.
“CHEAP” is a very relative term. $80 for a Pi is cheap to me, but perhaps not compared to a Teensy 4.1 board. Then again, if you are building an airplane…
Thanks for the quick reply. I did find the ra8875 on digikey yesterday, I didn’t see it in my earlier searches but probably just missed it. I have a couple on the way.
Thanks again.
Ron
Hello Ron,
Thanks for your kind comment.
Digikey has 133 in stock ! You can order now, you’ll receive the board in 3-4 days.
Unfortunately, there is no satisfactory alternative, the RA8875 is perfectly suited for this task with its two layers, and a highly optimized library is available for Teensy 4.x. Real Time animation of an artificiel horizon over SPI is a true challenge !
Benjamin
Hi,
This project is great work for anyone who’s hobbies include electronics and flying. Great work.
My question is, with the RA8875 controller nearly impossible to find, do you have a reliable second recomendation for a screen driver that you may have tested with the other hardware? Im looking at using the teensy board only for a build but can’t find the 8875 available.
Thank You
Hi Will,
Arduino, Teensy, STM32, and other microcontrollers never have an HDMI socket. An HDMI display would therefore require a single-board computer with HDMI connectivity. The operating system of these single-board computers (usually Linux) does not support sudden power loss, which requires securing this power supply using an uninterruptible power source (UPS). We are considering (with low priority) an EFIS solution based on a Raspberry PI, which would (slightly) improve the overall graphics performance, but the costs and overall complexity would increase significantly.
This would take us away from one of our goals: simplicity and low cost…
Benjamin
Hi,
amazing work, you’ve made me re think my entire panel (:
You had mentioned that perhaps you would be working on a solution for the HDMI screen to run ( display ) EFIS, just curious whether this was something you were still planning on re visiting .
Thank you for sharing all of this, truly brilliant!