Receive and parse data from the aircraft engine monitor
PROJECT OVERVIEW
The following is from my initial experience with Advanced Serial Data Logger and associated plug-ins from AGG Software. My project involved interfacing my tablet PC with the output of an electronic aircraft engine monitor marketed to be used with an experimental (home-built) airplane operated under US FAA rules, which allow the use of equipment not approved for use with certified aircraft. The instrument monitors most of the measurable parameters of engine operation. These include the cylinder head temperatures and exhaust gas temperatures for each cylinder, oil pressure and temperature, fuel and rate of fuel use, remaining fuel, carburetor temperature, engine RPM, flight time, and many other operation facets. The idea is to operate the engine properly and to monitor engine health and be forewarned of developing trouble before the engine announces a problem by some degree of failure.
The monitor has a small display screen that allows the abbreviated display of several of these measurements at a time and further allows the user to page through many others. This is cumbersome and diverts pilot attention from flying the aircraft. The screen is about the size of a cell phone display and is not in color. The user can input limits, which, when violated, activate a dashboard warning.
The user may also connect a serial output to a portable computer, and using a provided logging program, store the measurements at about one complete cycle per second in the computer memory. The data is held within the compiled software program until the program is stopped, when the resulting table may be saved to a user-selected file. This is meant for short term monitoring as the file quickly becomes very large. There is no provision for keeping these measurements less frequently, deselecting some, or for accessing the data in real-time for other purposes. I wanted to create a smaller file that could be built and retained over several hours of operation.
Further, I have designed a color graphic display of each of the measurements. Most are small bar charts with axis ticks. At a glance each of the critical measurements can be seen, and as they approach limits, the bar turns from green to yellow, and when out of limits, the offending bar turns red. It is actually more complicated than this as there is some interplay between measurements. For instance, low oil temperature greatly lowers the permissible RPM, and as the engine warms its oil, the allowable RPM increases. A simple glance of the displays will hopefully show all green, and the pilot's instrument scan is greatly simplified. One half of the tablet PC screen contains this graphic display while the other half contains a GPS driven moving airspace chart (map) and other GPS outputs.
To accomplish this graphic display, I need to feed selected output in real-time from the engine monitor to this program. The Advanced Serial Data Logger and plug-ins do this very nicely for me.
MAPPING THE SERIAL DATA STREAM
My first step was to learn everything I could about the binary serial data from the engine monitor. Fortunately, I was able to obtain a description of the data stream, which is about a page and a half long. Following is a very small, truncated serial data list as it was provided to me:
Serial Data List
All data is transmitted at 9600 baud, one stop bit, no parity. The first 3 bytes are a header that is unique, and will not show up in the data stream.
All 2-byte data is listed with an "H" and an "L" following the name of the data. To combine these two bytes into the result, multiply the high word by 256, and add the low word to the result.
All data is scaled with the least significant bit = 1 unless noted. All data is unsigned unless noted.
$FE ; Header word #1 (Decimal 254)
$FF ; Header word #2 (Decimal 255)
$FE ; Header word #3 (Decimal 254)
TACHH ; Tachometer - Resolution = 1
TACHL
CHT1H ; CHT and EGT follow all have
CHT1L ; a resolution of 1 deg
CHT2H
CHT2L
From the above one, you can see the format of the data stream. Most of the data was made up of a high byte and a low byte or word. Also, most are to a resolution of 1 degree while some items, not shown, are to .1 resolution. This allows the data parser to know where to place the decimal point while the data is otherwise treated as integer. Therefore, the decimal is not transmitted. The supplied information indicates that each stream is begun with the three header words which are given. This header allows the data parser plug-in to begin reading data after the third header word, which is not data. The order of data measurements is fixed, and the number of bytes is also fixed, so the parser properly programmed stays in step. If this precision is not maintained, an offset will occur, and garbage will result. Thus, it is important to map the data string properly.
To do this, I used a data reader included with the software, and as a convenience, read the output of the monitor through a serial port of my PC as though it was the ASCII code, although in my case, none of it is. When running the monitor on my workbench and displaying the ASCII code equivalent of each byte across the display, a continuing stream of letters and characters resulted. Very quickly, the stream will repeat itself many times as the new characters march across the display. I then stop the data logger and examine the resulting stream. In my case, the header bytes being Decimal 254 and 255 produced characters that were unique from the meaningful data stream body and were easily spotted. These header words mark the beginning and end of the data sequence.
Here is what my output looked like:
<NUL><NUL><NUL><NUL>C<NUL>C and so continuing with a few meaningful differences as the data stream was read.
To turn this output into decimal equivalents I referred to an ASCII table. I found the one I used on the Internet at www.AsciiTable.com. There are many Internet sources for a table.
If looking at the small portion of the data stream, the "NUL" value is 0. The "C" value is 67. Other characters each have a unique Decimal value. A ";" has a value of 59. All told values from 0 to 255 decimal are contained in a single byte. Thus, you can map both the number of bytes and the value of each of these bytes on this work page. If your data stream contains alphanumeric characters, the output can be accepted literally.
Using the Windows "copy" function, I selected one whole data stream from the displayed characters beginning with the header characters and ending with these same characters and pasted the result to a new Word document. I allowed the pasted string to wrap several lines as necessary on the page. I used Word because I could then set the line spacing to provide ample space between printed lines for notes. The total stream between the header bytes will be seen. Because you can see the value of each byte, many elements will probably be easily identified. In my case, all of the cylinder heads and exhaust low word bytes read 67 and 68, and the high words were "NUL" even with no temperature probe attached. While it is not, one can treat this as a default value. These indicated the position in the stream of twelve bytes. Battery voltage was in the output, and that provided another known point. Slowly you can decipher the remaining elements. If you have the data stream for the source, the job is greatly simplified. A printout of the data from another source is also a great help.
Programmers attempt to make the data stream as short as possible. They sometimes use contrivances to eliminate a byte here and there. Because the programmer knows the upper and lower limits of some data, they can add or subtract some number to adjust the result to display within the value contained in a single byte, and then when the byte is read by the parser, the adjustment is reapplied. In this case, all of the data values will be in a single byte. Your data parser will need to be programmed to deal with this. Also, two's complement binary coding can cause negative and positive signing to be included without the use of an additional byte. If this is done, do a Google search for how 2's complement works. Your data instructions, if available, may include an explanation. There are probably other tricks unknown to me, but I suggest treating all of the data as straight forward until a problem is encountered. With a monitor, one can manipulate data measured to provide a known result and then look for that result in the data stream. With the resulting mapped data, a data parser can be designed to handle the whole serial stream.
Author:
Jim Crowder
Data examples:
Input: AdvSerDatLog-COM5.log (the binary log file, created with the help of Advanced Serial Data Logger)
Output: Engine-Monitor (the Excel file)
Requirements:
Advanced Serial Data Logger. License type: Professional, Enterprise, or a trial version
.
Direct Excel Connection data export module
Universal data parser module with the XML configuration file uniparser.engine.mon.xml
Related articles: Receive and parse data from the aircraft engine monitor
