MGL RDAC Plugin

[brightproject]

Good afternoon @birkelbach and @e100.
Many thanks thank you for creating and developing of this project!
I would like to ask you to create a discussions section in the GitHub repository, and in it you can communicate, like on a forum, and immediately receive information regarding the project code, and this is more convenient than on the forum, and this is not an issue.
I wanted to ask about examples and details of using the file:

https://github.com/makerplane/FIX-Gateway/blob/master/fixgw/plugins/mgl/rdac.py

I wanted to get data from AHRS and RDAC manufactured by MGL and display on pyEfis.
But due to the lack of sufficient experience and examples, I have difficulties.
I have two such modules:

With AHRS, it is not yet clear what protocol comes out of it and whether the block works at all.
Regarding RDAC, as far as I understand, MGL used different protocols:

1. OEM protocol

https://github.com/makerplane/FIX-Gateway/files/15090712/RDAC_X_OEM_protocol.pdf

Message 1 – fuel flow related
$D5 DLE
$02 Start of text
$01 Message type
Flow 1 Word – number of flow sender pulses since last message 1
Flow 2 Word – pulse timing for fuel injector systems
CKS1 linear checksum
CKS2 xor checksum

Message 2 – Analog inputs and miscelaneous items
$D5 DLE
$02 Start of text
$02 Message type
OILT Word – ADC reading on oil temperature input 0-4095
OILP Word – ADC reading on oil pressure input 0-4095
LEVEL1 Word – ADC reading on fuel level input 1 0-4095
LEVEL2 Word – ADC reading on fuel level input 2 0-4095
VOLT Word – supply voltage
ITEMP Word – internal temperature
CHT1 Word – ADC reading on CHT1/WT input 0-4095
CHT2 Word – ADC reading on CHT2 input 0-4095
MAP Word – ADC reading of manifold pressure sensor 0-4095
CKS1 linear checksum
CKS2 xor checksum

Message 3 – RPM
$D5 DLE
$02 Start of text
$03 Message type
RPM Word – Value representing time between pulses on rev counter
CKS1 linear checksum
CKS2 xor checksum

Message 4 – Thermocouple temperature channels
$D5 DLE
$02 Start of text
$04 Message type
TC1 Word – temperature on TC 1 assuming degrees C and K-type
TC2 Word – temperature on TC 2 assuming degrees C and K-type
TC3 Word – temperature on TC 3 assuming degrees C and K-type
TC4 Word – temperature on TC 4 assuming degrees C and K-type
TC5 Word – temperature on TC 5 assuming degrees C and K-type
TC6 Word – temperature on TC 6 assuming degrees C and K-type
TC7 Word – temperature on TC 7 assuming degrees C and K-type
TC8 Word – temperature on TC 8 assuming degrees C and K-type
TC9 Word – temperature on TC 9 assuming degrees C and K-type
TC10 Word – temperature on TC 10 assuming degrees C and K-type
TC11 Word – temperature on TC 11 assuming degrees C and K-type
TC12 Word – temperature on TC 12 assuming degrees C and K-type
CKS1 linear checksum
CKS2 xor checksum

2. Raw data format (essentially a similar protocol, but there are differences)

https://github.com/makerplane/FIX-Gateway/files/15090688/MGL_EFIS_data_feed.pdf

Message 10: Engine data
This message is sent at a rate typically from 1 to 10 times per second depending on
implementation. Each engine has one message.
 DLE: byte; 0x05
 STX: byte; 0x02
 MessageLength: byte; Depends on message content
 MessageLengthXOR: byte; Depends on message content
 MessageType: byte; 0x0A
 MessageRate: byte; As required
 MessageCount: byte; As required
 MessageVersion: byte; 0x01
 Engine number: byte; 1..Number of engines
 Engine type: byte; 0 – Piston 1 – Turbine
 For Combustion engines:
 Number of EGT: byte;
 Number of CHT: byte;
 RPM: word; Revolutions / minute
 PULSE: word; AUX pulse/RPM value
 OIL pressure 1: word; In 10th of a millibar (Main oil pressure)
 OIL pressure 2: word; In 10th of a millibar (optional second oil pressure)
 Fuel pressure: word; In 10th of a millibar
 Coolant temperature: smallint; In degrees C
 OIL temperature 1: smallint; In degrees C
 OIL temperature 2: smallint; In degrees C
 AUX temperature 1: smallint; In degrees C
 AUX temperature 2: smallint; In degrees C
 AUX temperature 3: smallint; In degrees C
 AUX temperature 4: smallint; In degrees C
 Fuel flow: word; In 10th liters/hour
 AUX flow: word; In 10th liters/hour
 Manifold pressure: word; In 10th of a millibar
 Boost pressure: word; In 10th of a millibar
 Inlet temperature: smallint; In degrees C
 Ambient pressure: word; In 10th of a millibar (intake air pressure)
 EGT: smallint; In degrees C - Repeated for each EGT
 CHT: smallint; In degrees C – Repeated for each CHT
 For turbine engines:
 Inlet temperature: smallint; In degrees C
 N1 longint; RPM
 N2 longint; RPM
 Exhaust temperature: smallint; In degrees C
 OIL pressure 1: word; In 10th of a millibar (Main oil pressure)
 OIL pressure 2: word; In 10th of a millibar (optional second oil pressure)
 Fuel pressure: word; In 10th of a millibar
 OIL temperature 1: smallint; In degrees C
 OIL temperature 2: smallint; In degrees C
 AUX temperature 1: smallint; In degrees C
 AUX temperature 2: smallint; In degrees C
 AUX temperature 3: smallint; In degrees C
 Fuel flow: word; In 10th liters/hour
 Ambient pressure: word; In 10th of a millibar (intake air pressure)
 Padding: word; Set to zero. Used to align checksum.
 Either engine type is followed by:
 Checksum longint; CRC32

Please tell me which protocol is implemented in the code?
I also use Rasberry on a single-board PC, just a laptop with Linux installed.

Can I transfer data to the fix-gateway via a COM port in RS-232/UART format or should data only be received via CAN bus and a single board PC should be used??

[e100]

Pyefis gets all of the data from the fix gateway using net-FIX protocol https://github.com/makerplane/FIX-Gateway/blob/master/doc/plugins/netfix.rst
Net-FIX is just the TCP implementation of the CAN-FIX protocol https://github.com/makerplane/canfix-spec

The FIX-gateway has various plug-ins to communicate with different devices to send or receive data.

Regarding the MGL RDAC I have created a plug-in for the MGL CAN protocol https://www.mglavionics.co.za/Docs/MGL%20CAN%20Protocol.pdf

Only the RDAC XF portion of the CAN protocol is implemented, this starts on PDF page 11 in the above document. I own an RDAC XG and have tested the plug-in using it, it uses same protocol as thr RDAC XF. The plugin can be configured to receive data from the RDAC or to send data as an emulated RDAC.

I am unfamiliar with the RDAC XB that you have and based on the documentation you referenced it does not seem to use CAN for communication so is not supported by the plugin. I did see the RDAX XB listed on MGLs legacy product page https://www.mglavionics.co.za/legacy2.html

I can see two options if you want to interface with the legacy RDAC XB:

1. Write a plug-in yourself, or find someone who can write it. I currently do not have time to help with writing such a plug-in since I have enough work building my airplane and efis to go in it.
2. Update your hardware to an RDAC XG or RDAC XF. Upgrading might also require updating other MGL components too, so this might not be a practical option.

Regarding the MGL SP-3, it also seems to be a legacy product. It is not listed under their current products or their legacy products but they did have SP-2 and SP-4 listed as legacy.

A newer AHRS sensor that supports the MGL CAN protocol is not currently supported but I think the RDAC plug-in could be modified to support other MGL CAN devices like the SP-6 and SP-7. I named the plugin 'mgl' expecting that it would be expanded in the future to support more MGL CAN devices.
To implement a table would need created for them: https://github.com/makerplane/FIX-Gateway/blob/master/fixgw/plugins/mgl/tables.py
And the plugin would need updated to support the device/table.

Example to configure the MGL RDAC plug-in can be found in the default configuration file:

FIX-Gateway/fixgw/config/default.yaml

Line 404 in 96318e2

mgl:

[e100]

Also, we have a forum:
https://www.makerplane.org/forum/

[brightproject]

I can see two options if you want to interface with the legacy RDAC XB

Yes, I am on the forum, but there are mainly questions of a general nature and from pilots or engineers who install/repair devices.
There is still a community of programmers on Github, and I am more interested in code issues.
That’s why I ask @birkelbach to add a discussion tab to the repository in order to have substantive conversations about the code.
I will try to write the plugin code for outdated/legacy RDAC myself, I just need to understand how I can send the protocol data from the device via USB-TTL to USB and then to pyEfis.
RDAC genering a protocol in RS-232 format, I receive it using a USB adapter.

When the FIX-Gateway starts, it displays the following data about the connection port:

test1@test1-VirtualBox:~/FIX-Gateway$ ./fixgw.py -v
INFO:20240424-14:31:23:fixgw - Starting FIX Gateway
INFO:20240424-14:31:23:fixgw - Configuration Found at /home/test1/makerplane/fixgw/config/default.yaml
INFO:20240424-14:31:24:fixgw - Setting Initial Values - /home/test1/makerplane/fixgw/config/default.ini
None
INFO:20240424-14:31:24:fixgw.netfix - Initializing
INFO:20240424-14:31:24:fixgw.system - Initializing
INFO:20240424-14:31:24:fixgw.annunciate - Initializing
INFO:20240424-14:31:24:fixgw.compute - Initializing
INFO:20240424-14:31:24:fixgw.demo - Initializing
INFO:20240424-14:31:24:fixgw.netfix - Starting
INFO:20240424-14:31:24:fixgw.system - Starting
INFO:20240424-14:31:24:fixgw.annunciate - Starting
INFO:20240424-14:31:24:fixgw.compute - Starting
INFO:20240424-14:31:24:fixgw.demo - Starting
INFO:20240424-14:31:24:fixgw.netfix - Client connection from 127.0.0.1 port 56274
^CINFO:20240424-14:32:44:fixgw.netfix - Disconnected by 127.0.0.1 port 56274
INFO:20240424-14:32:44:fixgw.netfix - Stopping
INFO:20240424-14:32:45:fixgw.system - Stopping
INFO:20240424-14:32:45:fixgw.annunciate - Stopping
INFO:20240424-14:32:45:fixgw.compute - Stopping
INFO:20240424-14:32:45:fixgw.demo - Stopping
INFO:20240424-14:32:45:fixgw - FIX Gateway Exiting Normally

When I enter the command, as I understand it, the demo mode starts

https://github.com/makerplane/FIX-Gateway/blob/master/fixgw/config/demo.yaml

but how can I enable FIX-Gateway in the mode of receiving data from the com port?
This is one of the things that is unclear to me now...

[e100]

Edit the configuration file, the path is shown on the output you provided.
Change demo load option to no so it does not load.

To get the data from you RDAC over serial you will need to create the plugin and then edit the config file to load it.

This plugin gets serial data from a Grand Rapids EIS, might be helpful to look at to understand how to create a plugin that talks to serial port:
https://github.com/makerplane/FIX-Gateway/blob/master/fixgw/plugins/grand_rapids_eis/__init__.py

This other plugin also uses serial port but not directly so not too useful as a serial port example. However this try catch in the main loop that initiates the serial connection allows the plugin to gracefully reconnect to the port in situations where the USB serial adapter is unplugged and then reconnected.
The Grand Rapids plugin does not have such logic and looks like it would likely crash the plugin in such a situation.

FIX-Gateway/fixgw/plugins/mavlink/__init__.py

Line 59 in 96318e2

try:

The logic in the mavlink will also handle starting fix gateway without the USB connected, then automatically start collecting data when it is plugged in.

This is not required for the plugin and I'm no expert on udev so would not be much help but if you will have more than one USB serial port for different devices I highly recommend creating udev rules to give each port a static unique name. Without this you could find that one day your RDAC is ttyUSB0 and some other day it becomes ttyUSB1. My suggestion would be to name them ttyUSB10, ttyUSB11, ttyUSB12, etc for two reasons 1. You cannot rename ttyUSB1 to ttyUSB0 if ttyUSB0 already exists, so renaming to known unused numbers is more reliable and 2. Some security settings, like in apparmor or selinux, will sometimes let you connect to ttyUSB10, etc. but not myCustomMadeUpDeviceName so using standard naming convention is more reliable.
I had to write a similar udev rule for my two CAN0 and CAN1 bus ports because they kept flipping names randomly. I named them CAN10 and CAN11
https://github.com/e100/makerplane-configs/blob/main/INSTALL.md#optional---setup-waveshare-can-fd-hat

[brightproject]

Edit the configuration file, the path is shown on the output you provided.

Thank you for your work and help, I will try to implement the plugin.

[brightproject]

Hello @e100
I'm making some attempts to receive data from the RDAC via the COM port.
The RDAC module generated data in binary form, I received the following message:
In ASCII

b'\xd5\x02\x05!\x00!\x00!\x00!\x00\xfc\x0f`\x04\xa2\xc7\xd5\x02\x03\x18y>7\xd5\x02\x03\x18y> 7\xd5\x02\x03\x98\xf9\xbe7\xd5\x02\x02!\x00!\x00!\x00!'

9 bytes per *hex

D5 02 01 00 00 FF FF A9 54
D5 02 03 18 79 3E 37 D5 02
03 18 79 3E 37 D5 02 03 18
79 3E 37 D5 82 83 18 79 3E
37 D5 02 03 98 F9 BE 37 D5
82 84 23 00 23 00 23 00 22
00 39 50 D5 02 03 18 79 3E
37 D5 02 03 18 79 3E 37 D5
82 83 18 79 3E 37 D5 02 03
18 F9 BE B7 D5 02 05 22 00
22 00 23 80 A2 80 FC 0F 70

The main problem is my Linux on a virtual box.
It works, but there are certain peculiarities in setting up the COM port forwarding, its operating baud speed, etc.
My RDAC XB has an old protocol, and stably sends data via the communication protocol only at a speed of 1250 baud (selected empirically)

Using the minicom utility, you can only change the speed to 1200 baud, and this creates misunderstandings during parsing.

At first I tried to simply receive data into the com port and read it using the CoolTerm program.

By combining the results obtained using the Saleae logic analyzer, the data is here.
I also looked at the data using a simple console utility hexdump.

I added the following configuration to the default.yaml file:

  mgl_rdac:
    load: yes
    module: fixgw.plugins.mgl_rdac
    # type: serial
    # baud: 115200
    baud: 1250
    port: /dev/ttyS0 
    # port: /dev/ttyUSB0
    # model: VB #RDAC Vb
    model: "XB" #RDAC Xb

In the plugins folder I added a new folder mgl_rdac and created a __init__.py

#!/usr/bin/env python

#  Copyright (c) 2019 Makerplane
#  Modified in 2024 by [email protected]
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#  along with this program; if not, write to the Free Software
#  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
#  USA.import plugin

#  Reads data from MGL RDAC serial port

import threading
import time
from collections import OrderedDict
import fixgw.plugin as plugin
import serial

class MainThread(threading.Thread):
    def __init__(self, parent):
        super(MainThread, self).__init__()
        self.getout = False   # indicator for when to stop
        self.parent = parent  # parent plugin object
        self.log = parent.log  # simplifies logging
        # serial_port = self.parent.config["port"]
        self.port = self.parent.config["port"]
        self.baud = self.parent.config["baud"]
        self.model = self.parent.config["model"]
        if (self.model != "VB" and self.model != "XB"):
            print("Unsupported RDAC model")
        else:
            print("RDAC model: " + str(self.model))
        # self.ser = serial.Serial(serial_port, 1250, timeout=1)
        self.ser = serial.Serial(self.port, self.baud, timeout=1)
        # open serial connection.
        # self.ser = serial.Serial(
        #     port=self.efis_data_port,
        #     baudrate=self.efis_data_baudrate,
        #     parity=serial.PARITY_NONE,
        #     stopbits=serial.STOPBITS_ONE,
        #     bytesize=serial.EIGHTBITS,
        #     timeout=1,
        # )

    def run(self):
        while not self.getout:
            if(self.model == "XB"):
                # print("Model XB")

                # Read data from com-serial
                data = self.ser.read(50)
                # print(data)

                # Format data in HEX
                # hex_data = ' '.join([format(byte,'02X') for byte in data])
                # print(hex_data)

                # Parse the message
                # Typical msg for RDAC RPM 
                # D5 02 03 18 79 3E 37
                # $D5 DLE
                # $02 Start of text
                # $03 Message type
                # RPM Word – Value representing time between pulses on rev counter
                # CKS1 linear checksum
                # CKS2 xor checksum

                for i in range(len(data)):
                    if data[i] == 0xD5:  # DLE - Data Link Escape
                        if i + 9 <= len(data):  # Make sure we have enough bytes for a complete message
                            if data[i + 1] == 0x02:  # STX - Start of Text
                                message_type = data[i + 2]
                                if message_type == 0x03:  # Example handling for message type 0x03 (RDAC RPM)
                                    # rpm_bytes = data[i + 3:i + 7]  # RPM bytes
                                    # rpm_value = int.from_bytes(data[i + 3:i + 7], byteorder='big')  # Convert to integer
                                    # rpm_value = int.from_bytes(data[i + 3:i + 7], 'big')  # Convert to integer
                                    big_endian_rpm = int.from_bytes(data[i + 3:i + 7], 'big')  # Convert to integer
                                    # little_endian_rpm = int.from_bytes(data[i + 3:i + 7], 'little')  # Convert to integer

                                    # RevFactor values (number of pulses per 10 revolutions)
                                    rev_factor = 10

                                    # Calculate RevFudge for little-endian and big-endian
                                    # rev_fudge_little = (6000 / rev_factor) * 15586
                                    rev_fudge_big = (60000000 / rev_factor) * 15586
                                    rpm_big = round (rev_fudge_big / big_endian_rpm)


                                    # print("RPM:", rpm_big)
                                    self.parent.db_write("TACH1", rpm_big)
                                    # self.parent.db_write("TACH1", 100)


            elif(self.model == "VB"):
                print("Model VB")


        self.running = False

    def stop(self):
        self.getout = True
        self.ser.close()

class Plugin(plugin.PluginBase):
    def __init__(self, name, config):
        super(Plugin, self).__init__(name, config)
        self.thread = MainThread(self)
        self.status = OrderedDict()

    def run(self):

        self.thread.start()

    def stop(self):
        self.thread.stop()
        if self.thread.is_alive():
            self.thread.join(1.0)
        if self.thread.is_alive():
            raise plugin.PluginFail

    def get_status(self):
        return self.status

I managed to parse the data and partially decode it.
I still have to figure out the coefficients of the resulting revolutions of the RDAC XB itself, but a start has been made.
So far I haven’t been able to figure out how to change the designation of the TACH1 speed variable to something of my own.

RPM: 28
RPM: 28
RPM: 228
RPM: 228
RPM: 228
RPM: 228
RPM: 36
RPM: 228

I also don’t understand why the speed hasn’t changed yet, although the real data is changing, and this is visible:

I have not yet written code to automatically determine the required serial port, as you advised above in discussion.
Perhaps you can give some valuable advice.

[e100]

If you edit your code so it prints the RPM before writing it to the DB like:

                                    print(f"RPM: {rpm_big}")
                                    self.parent.db_write("TACH1", rpm_big)

The value you see in the pyEFIS screen should match what is printed out from fix gateway.
If that is not happening the only thing I can think of is maybe you accidentally ran two fix gateway instances and pyefis is connected to the wrong one.

You do want to use TACH1 for the engine RPM, unless it is the RPM for a 2nd engine then you would use TACH2. All of the database items are defined in fixgw/config/database.yaml