Avionics discussions

[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](https://github.com/makerplane/FIX-Gateway/blob/master/fixgw/plugins/mgl/rdac.py)?
I also use `Rasberry` on a single-board `PC`, just a laptop with `Linux` installed.
![EMS](https://github.com/makerplane/FIX-Gateway/assets/1788098/e883a9fa-7a36-4861-9d0e-c4bdf102bff5)

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: https://github.com/makerplane/FIX-Gateway/blob/96318e2cee1e9df0055a5c2c7eff6b6f9558f63c/fixgw/config/default.yaml#L404

[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. https://github.com/makerplane/FIX-Gateway/blob/96318e2cee1e9df0055a5c2c7eff6b6f9558f63c/fixgw/plugins/mavlink/__init__.py#L59 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.