⇒Index⇒Flugmodell ElektronikRender-Engine⇒etc Aeromodeling near Lofer, Austria

The "Render Engine"(n+2nd :-) Version...   June 2018   → Change List


The Render Engine is a microcomputer to render data, in this case mainly telemetry data from aeromodels.
I think such devices will gain increasing importance for RC equipments. Here I describe my development for installation in a Multiplex® ROYALpro RC transmitter to increase its functionality and to try out new ideas. A first version with still limited functionality is ready now and shall be tested during this season. It can read telemetry data from the MLink® module, can execute evaluations and application code. It renders data using speech, vario- and shepard-tones and, of course, haptic output.

Table of Contents
   Data Input, Unified Data Structures
   Virtual Rendering Devices
   Technical Rendering Devices
Further Development

Haptic gauges
Haptic gauges

...you can →feel whether your glider is climbing or descending - your RC transmitter device has levers mounted near the sticks which can easily be felt with the ring fingers. I call this rendering device a "haptic gauge": Haptic because you feel what happens, and gauge because it has a zero point (reference point) and some span upward and downward to render a physical entity up to and down to a certain degree. See the figure at the right: This was my first "Render Engine" (it is inside the RC transmitter's case, you only can see the gauges:-).
One day I met some Italian comrades on a slope near St. Moritz, Switzerland - they were so excited seeing this simple device and immediately understood the advantage (silence) ...and they could show their excitement really impressively, perhaps Italian people can do this better than others. This alone was worth the effort...

The Render Engine is just an extended rendering device for telemetry data and a supplement for the RC transmitter's abilities.

...you can experiment with known or new rendering techniques:
Optimize the scaling or the zero position frequency of the variometer tone to your preferences, or experiment with the zero position: Define the optimal climb rate for your F5?-aeromodel for the climb phase as "zero" to aid training (credit for this idea goes to Mike inserthisNAME),

The Render Engine is a device to optimize rendering techniques.

...you can invent, implement and prove your own rendering technique for

The Render Engine can be used by creative people to invent new rendering techniques. The span goes from tiny, simple but practical extensions up to real inventions - there are large areas for creativity!


The Render engine must fit into an ecosystem as follows:

This was a short overview what happens in the Render Engine, let us look on some...


The Design of the current implementation does not contain surprises:

Render Engine - Block Diagram

There is an input driver for the telemetry data stream - as already mentioned there are several formats of data streams, depending on the RC equipment brand, and the input driver shall generate a stream of telemetry data items of a standard format, as is described in an extra document:
↠Data Format and Semantic Specification for Telemetry Data in the Field of Aeromodeling.

The current implementation does not contain its own data storage (the sound clips and the operational parameters are stored directly in the controller's flash memory) or its own sensors (like a compass), but future engines will of course.

The current implementation contains an elementary user interface which consists of a 3 step switch and a press button, not more. These devices are parts of the RC transmitter device, but are soldered off and connected to the (built in) Render Engine. An analog input will be added later.

The stream of telemetry data items, as it comes in from the input driver, is processed in a main loop: Few items are stored, others are processed to generate additional infos (e.g. warnings) or to create new data, e.g. compensated data out of uncompensated data.

There is a library of rendering functions (virtual rendering devices), which will be described in some detail later. The main loop controls the “plumbing”, which value is to be rendered by which function on which rendering device.

A set of operational parameters, which is defined by the user, controls various aspects of the processing: It supports the input driver by yielding additional information, which value in which context is to be translated into which (uniquely defined) telemetry data item, or it defines alarm levels, or it controls the “plumbing”. As the operational parameters must be written into the flash memory of the ARM controller this mechanism is currently not programmed fully, but this is one of the fields of improvement scheduled next.

Data Input, Unified Data Structures

The current implementation reads its data stream from a Multiplex HFM4 transmitter's radio module. The format is not published but it is easy to understand. Telemetry data are embedded in blocks, 2 data items per block. Under standard conditions 10 blocks are transmitted per second, if you use 14 ms servo cycles there are 15 blocks per second. If a channel is prioritized one of its data items is transmitted per data block, the other “space” is shared among all other (active) channels.
The format of the MSB data items is communicated, it is used for data transmission in the vehicle (Other people or firms than Multiplex are allowed to build and sell sensor devices).
In short words: One MSB telemetry data item consists of a format code (0..15), a channel number (0..15), an alarm bit and a 15-bit signed integer number. The meaning of the number is specified by the format code; for example, format 3 means a "low speed" number in 10th of [m/s], <3/-14> does mean -1.4 m/s, possibly descending speed.
Users are meant to notice, which value per channel means what telemetry data item. For example, a voltage (format 1) on channel 3 may mean the voltage on the lower cell of the supply accumulator and a voltage on channel 4 may mean the upper cell.
This mapping, <format, channel> to “meaning” for the render engine, must be done by the input driver. A list of operational parameters controls exactly this mapping: There may be 2 parameter entries like the following:

<msb channel="3" format="1" TDEL="TDEL_SUPPLY|TD_VOLTAGE|0" TDNUM="TDNUM_Q1516|TDNUM_01">
<msb channel="4" format="1" TDEL="TDEL_SUPPLY|TD_VOLTAGE|1" TDNUM="TDNUM_Q1516|TDNUM_01">
↠Data Format ... the Field of Aeromodeling to understand the TD... codes and expressions.
Another Example: A "low speed value [m/s]" (format 3) on channel 7 means the uncompensated climb rate of a glider. It is the user who must know all details of this mapping as parts of this are not specified anywhere (it really means compensated | not compensated climb data) and as he or she is the one who equipped the aeromodel. Such mappings may change from aeromodel to aeromodel.

The main loop “pulls” item by item out of the input driver. Normally these items are independent of each other, but exceptions are possible (and should be well documented:-) and may be recognized by comparing the timestamps: All items out of one block of the HFM4 radio module get the same timestamp generated by the input driver.


This means:

Finally, standard procedures for the plumbing are called. These are controlled by user defined settings (The current implementation executes hard coded decisions in this part).

Virtual Rendering Devices

A virtual rendering device is not described by “how it rendes data”, but which kind of data can be rendered best with it. I have identified the following classes of virtual rendering devices:

Technical Rendering Devices

These are, of course, the most visible parts of the Render Engine which attract curiosity of others...
What I have heard of: We all know acoustic rendering via speech, the variometer tone and some kinds of alarm tones. Someone tried to establish a stick shaker for alarms (I don't know how the potentiometers of the sticks survived that). I have heard from a hobbyist who mounted a very small servo on his glasses and saw the levers during flight, indicating climb or accumulator's state. Surely some tried small text or numerical displays to be mounted on the hat, but I don't know about any success. Such displays have one problem: brightness - they cannot deliver enough light to “stink” against the sun or they use the sunlight themselves (transparent LCD devices) but this makes them really dangerous when lenses must be used.

Acoustic rendering, as it is used today, may be extended by the shepard tone as a supplement technique for searching thermals. It is a real improvement (I never want to miss it any more) but is is only a tiny new extension for acoustic rendering in general.

Haptic rendering might still be at the beginning and can be developed in several directions: A simple gauge with one or two reference points may easily be implemented with standard servos. Reference points may be valuable for marking important values (zero climb) or “optimal” values like best gliding speed etc. More reference points may be good for signaling an accumulator's state. All this needs a means to calibrate the device. The servo may be mounted on the stick (very impressive!), of course I tried it but didn't succeed.
Haptic gauges may also be used for alarms by letting the servo shake a bit.
I would be glad if I could create a haptic clock, even perhaps 2 stacked pointers, but the mechanic is complicated and stepper motors are expensive and current consuming (or they are not good enough). We will see.

Visible rendering is complicated as the pilot should always look at his aeromodel. It may be possible to create an instrument which can be read without looking directly on it (like instruments in cars), but only very few of them may be used without overloading the pilot. The mechanics may be the same as with haptic gauges, really fat pointers and extreme color schemes may be used to improve readability.

Simple indicators (LEDs) may be mounted into glasses and may be good for enumerations and alarms. I shall try 4 LEDs (green / green / yellow / red) to signal the accumulator's status. Data glasses may develop to extremely valuable render devices when they

There is a promising announcement from Intel (early 2018) and a tiny screen, which can be fixed at a hat, has been introduced by Fraunhofer Institute (late 2017).

Data glasses of course can offer graphics of very different kinds, gauges, clocks (!) and indicators (enumerations) can be implemented for nearly any needs - the upper limit is defined by the overload border for the pilot.

Further Development

All these developments can be realized with the current Render Engine which consists of a rather tiny hardware (a NUCLEO®-L432KC, an I²S-Audio amplifier board and few resistors and capacitors, ah yes, small servos for the haptic gauges). But for the future, when a new, large Render Engine is available,     imagine...

...you are part of a community where new ideas are shared and improved and

...you can think about really new things which might affect aeromodeling in the future: When ADS-B is mandatory even for small aircrafts a passive (only listening) receiver may help estimating flight heights of other traffic and planning the model flight height. FLARM devices (only listening) might also help. And, I am sure this will happen: RC transmitters will set up ad hoc networks - information exchange will help finding thermals and will help avoiding collisions in thermals (:-) and other applications will come up when the basis is provided.

The Render Engine is worth being recognized by any creative person who is able and willing to improve aeromodeling.

Change List
2016, February, Version 1
2017, July, Version 2 (in German)
2018, June, current version, 100% revised...