(ESP32 EFIS-EMS: last updated by Benjamin on December 13, 2025)
ESP32 EFIS-EMS is a completely redesigned system that combines an EFIS and an EMS on a single 7-inch display. Compared to the previous system, which featured two screens, one for the EFIS and the other for the EMS, both powered by Teensy 4.1 boards, this new system stands out by introducing ESP32 microcontrollers. These microcontrollers, on the one hand, enable significant improvements to the graphical user interface and, on the other, allow wireless communication between specific components.
Readers are encouraged to refer to the “TFT-LCD display for DIY avionics” and “Microcontroller boards” pages, which have been revised accordingly. One of the main goals of this new system was to completely overhaul the user interface to give it a look similar to that of professional instruments. Two other objectives were to minimize the overall system size and to improve the quality of connections to the many sensors.
A pre-prototype of this system has already undergone successful flight tests, as shown below. This page will therefore be updated when the final version is ready. These tests aimed to validate several options and innovations. Consequently, there will be some architectural evolutions in the coming weeks compared to the prototype presented here. However, the display’s visual appearance (see the photos and videos below) is almost identical to what it will look like in the future; it should change only marginally.
ESP32 EFIS-EMS Planned Final Architecture
The ESP32 EFIS-EMS incorporates several existing elements that remain unchanged, namely the AHRS, the micro-EMS, and the remote magnetometer and external temperature and humidity sensor module, or RCM (Remote Compass Module). Two new modules are introduced: a display module and a remote data acquisition module, or RDAM. The RDAM should be considered the central data acquisition module. The AHRS, micro-EMS, and RCM are specialized data acquisition modules. All these modules communicate with each other via the CAN bus. Additionally, the RDAM and the display module communicate with each other over Wi-Fi. This architecture is illustrated in Figure 1.

This modular architecture aligns with the overall IMA (Integrated Modular Avionics) philosophy of the AvionicsDuino project. The modules each handle a specific function and communicate with one another via the CAN bus. The advantage of this modular architecture is the ease of maintaining and evolving the entire system.
ESP32 EFIS-EMS provisional prototype
To validate this new system and continue development, a provisional prototype has already been flight tested, as mentioned above.
The display module prototype
This prototype included a 7-inch commercial display module with IPS-quality performance and an 800 x 480 resolution. The graphics controller for this display is an ESP32-S3 system-on-a-chip (SoC) integrated into a PCB bonded to the back of the TFT panel. The entire graphical interface is therefore programmed on this ESP32.
This display features a capacitive touch layer, which enabled testing of a menu system without buttons or rotary encoders under real-world conditions. It was also desirable to test under direct sunlight a glossy, medium-brightness (400 cd/m²) display, which is representative of similar commercially available touchscreen displays. And also to test the ESP32’s wireless communication capabilities using Espressif’s ESP-NOW protocol, which operates over Wi-Fi. For these initial tests, the only electrical connection of this display module to the aircraft was its power supply. It was not connected to the CAN bus.
For these initial tests, no changes to the aircraft’s electrical circuits or the existing instruments on the panel were required. The display module, mounted in a 3D-printed ABS enclosure, was placed on a temporary support in front of the glove compartment. It was powered via its USB port, connected to a phone charger plugged into the aircraft’s cigarette lighter socket.
The temporary pressure sensor module
Therefore, a small additional module was specifically developed for these tests, also based on an ESP32-S3 chip. It was connected to the CAN bus and communicated with the display module via ESP-NOW, serving as an intermediary between the display module and the rest of the avionics. This module included, in addition to a CAN bus transceiver, a barometric pressure sensor (AMS5915-1500A) connected to the static pressure circuit, and a differential sensor (AMS5915-0050D) connected to the static port and Pitot probe (the same pressure sensors as the EFIS). The module received all engine data via the CAN bus from the existing EMS and micro-EMS, as well as other EFIS data from the AHRS and the remote magnetometer.
No changes to the software of the EFIS, EMS, micro-EMS, AHRS, or remote magnetometer were necessary for these tests, as all data processed by these instruments were already being sent via the CAN bus to the flight data recorder. This module was placed in a temporary 3D-printed enclosure, secured with Velcro under the instrument panel (Fig. 2).

For these tests, the system architecture was therefore as shown in Figure 3.

Therefore, this prototype was operating in parallel with the existing system.
Provisional prototype flight test results
They validated the essential principles of this new system and identified areas for improvement. The photo in Figure 4 and the video below (Video 1) were taken during the first test flight. In the image, the ESP32 EFIS-EMS is on the right, with its single display, and the Teensy EFIS and EMS on the left. Below and to the right of the instrument panel, you can see the green temporary module.

Data comparison
The data displayed by both systems were identical, including those from the two sets of pressure sensors in the two EFIS. These EFIS pressure data had undergone extensive validation, partly by comparing them with the reference Dynon D10 EFIS installed on this aircraft (see the EFIS page) and partly through an experimental study of the pressure sensors used (see the EFIS pressure sensors page).
ESP-NOW and electromagnetic compatibility
The ESP-NOW communication between modules was faultless. No electromagnetic interference was observed between this prototype, housed in temporary non-shielded enclosures, and the aircraft radioelectric system.
Display quality and touchscreen ergonomics
This first flight was conducted under ideal conditions at sunset. The photo and video were taken with a low-angle, low-intensity light from the front. Of course, no reflections were noted on the matte displays of the Teensy EFIS and EMS. Very mild reflections on the glossy ESP32 EFIS-EMS display were tolerable.
However, during subsequent daytime flights, with the sun much higher in the sky and directly on the display, 400 cd/m² proved seriously insufficient. Additionally, this glossy touchscreen is prone to strong reflections, glare, and mirroring, unlike the matte non-touch displays.
Moreover, while it seemed satisfactory on the bench, using the touchscreen menu proved ergonomically poor and quite tedious in even mild turbulence, despite the precaution of programming large tactile buttons, as seen in Video 2.
New version of the display module
Regarding reflections on touchscreen displays, anti-reflective filters could have been considered, but they reduce brightness and sharpness. Therefore, they are not an ideal solution, especially on screens that are already insufficiently bright.
Since no 7-inch, matte, IPS, sunlight-readable ESP32 non-touch screen was available on the market, it was necessary to make one. It is based on a custom printed circuit board using an ESP32-S3-WROOM 1 N16R8 SoC and a Newhaven NHD-7.0-800480AF-ASXP TFT panel. This panel is matte, IPS, non-touch, and has a brightness of 1000 cd/m².
For interaction with menus and the graphical user interface, the touchscreen was definitively abandoned in favor of a row of six push buttons located below the screen.
The result is shown in Figure 5, which depicts the display module in its 3D-printed ABS enclosure.

Bench tests were very satisfactory. The matte 1000 cd/m² screen remains perfectly readable under direct sunlight, with no reflections or mirroring, and the keyboard works flawlessly (video 3).
There will be no further design evolution. Without making any other changes, it could use an ESP32-S3-WROOM 1u module, which has a U.FL connector for a remote Wi-Fi antenna rather than an antenna embedded on the SoC’s PCB. This could be useful if ESP-NOW communication with the RDAM were of poor quality. For example, if the two modules were on opposite sides of an aluminium instrument panel that acts as an RF screen. But in that case, one could just as well abandon ESP-NOW in favor of CAN bus.
Display Module download section
The Remote Data Acquisition Module
There were several choices: should separate PCBs be used for the EFIS and EMS, as in the current AvionicsDuino system, or should they be combined on a single PCB? And on the other hand, which microcontroller to use: Teensy 4.x or ESP32?
The PCB
To maximize space utilization, a single 4-layer PCB was selected to increase component density and further improve compatibility and immunity against electromagnetic interference.
The microcontroller
Regarding the microcontroller choice, the ESP32-S3 was selected to leverage Wi-Fi ESP-NOW connectivity with the display module. The Seeed Studio XIAO ESP32-S3 board is ideal for its compact form factor. However, as a consequence of this choice, the well-known issue with the ESP32’s poor analog-to-digital converter (ADC) has arisen.
ESP32 ADC issues
Like many users, we observed nonlinearity in the only available ADC (the second is reserved for the system). By following Espressif’s calibration procedure, the linearity could be improved. But there is a second issue with this ADC: it is extremely noisy (especially compared to the ADCs on Teensy 4.x boards), especially when Wi-Fi is active.
Therefore, it was decided to use two external I2C ADCs (ADS7828), one for ratiometric sensors and the other for non-ratiometric sensors.
As of the date of writing this page, the RDAM is being assembled. The numerous preliminary laboratory tests on small sub-assemblies allow for quite optimism. However, the ESP32-S3 will be heavily stressed by Wi-Fi, the CAN bus, and six slave devices on the I2C bus.
ESP32 I2C issues
A concern could specifically come from the I2C bus. Even when strictly following Espressif’s procedures for bus and slave device initialization, oscilloscope and logic analyzer readings show latencies of 50-70 µs between I2C transactions, severely reducing bus bandwidth. This could impair the sampling rate and, consequently, the quality of digital data filtering.
If, unfortunately, the ESP32-S3 in the first RDAM prototype does not meet expectations, a straightforward, quick solution would be to build a second prototype with a minor PCB modification: replace the small XIAO ESP32-S3 board with a Teensy 4.0, which is only slightly larger, without making any other changes. One would then forgo Wi-Fi in favor of the CAN bus, with no genuine inconvenience. The Teensy 4.x solution is very robust and proven. The small additional cost of just over €10 compared to the XIAO board is minimal.
More to come very soon!