makerplane / fix-gateway Goto Github PK

The Stratux Plugin is crashing on some kind of Timeout. I didn't have a lot of time to troubleshoot it at the show and see exactly what part of the code was crashing but the WiFi was not good in that room and we were constantly disconnecting from the Stratux even though it was only a few inches away. Occasionally the Stratux Plugin would not recover and it would stop talking.

We should be able to have the program restart plugins if they fail. We may also need a better way to indicate the failure of a plugin than the thread is still running.

The command module will allow for the same point to be subscribed to multiple times. This doesn't make any sense and causes a single update to the point to print to the screen multiple times. This is most noticeable when using the enter key which will repeat the sub command.

I think it's maybe a good tool to create for data manipulation with sensor. like (ex: i have 3 bmp085 and node red compare data from this sensor and use data from one make better sense or create average from this 3 sensor...) and many more possibility (automatization ...).

Nodered https://nodered.org

I think this node are a good start https://flows.nodered.org/node/node-red-node-serialport

Sorry for my english. My 2 cent ...

is there a plugin for persistence of all db fields over time?

I've just done a clean install on a Raspberry Pi4 8GB and am getting an error trying to start the fixgw:

pi@raspberrypi:~/makerplane/FIX-Gateway-master $ fixgw
Traceback (most recent call last):
File "/usr/local/bin/fixgw", line 11, in
load_entry_point('fixgw==0.1.0', 'console_scripts', 'fixgw')()
TypeError: main() missing 1 required positional argument: 'args'
pi@raspberrypi:

It appears that load_entry_point() is getting the wrong number of arguments?

Allow the program to send itself to the background. i.e. run as a Daemon in the *nix world or a service in other worlds.

It is my intention to write a client library for the NetFIX protocol and include it in the FIX-Gateway codebase. Currently the 'fix' module that is used in pyEfis is included in the pyAvTools package which is fine but it might make more sense to move that library to the FIX-Gateway repo since the FIX-Gateway client application needs to use these libraries as well. It would avoid some duplication and make testing easier.

To that end I'd also like to redo how the client library works. Currently the client side of the netfix connection tries to maintain a database of the values that are also stored in FIX-Gateway. There are not a lot of values so the memory requirements are not terrible but maintaining the state of the data between the two databases has proven to be an issue. I think it makes more sense to present to the client application an interface that 'looks' like it is accessing a local database but behind the scenes it will simply communicate with the fixgw server and retrieve the information in real time.

Most of the client interaction with the database involves subscriptions to data value changes anyway. That part of the library would simply need to be a collection of the callback functions needed to communicate these changes to the individual client parts that need them. This would result in zero network overhead since the communication would have already taken place to start with.

Add --verbose option to the client and the server and only show log.info() messages at that level. If neither --debug or --verbose is passed then only warnings and errors will be logged.

I seem to be reinventing the wheel with my canbus module. There is a fairly mature called python-can that should do what we want. I'll probably just build the can-fix interface on top of that with maybe some simulation capability for development and testing. At least this way we can have access to all the hardware that python-can has access to and we don't have to fool with any of that.

Try to launch gateway (fixgw.py) with latest master branch and it fails to launch.

Error message is:

File "fixgw.py", line 20 in
import daemon
ImportError: No module named daemon

Currently the mapping has an item for FUELQ. This should be FUELQ1 but for some reason FUELQ get's mapped to FUELQ1 in the database. It's probably best if the mapping change to some kind of external configuration file anyway.

The console client crashes when a command is set while the server is disconnected. We should either exit cleanly or, better yet, display an error and continue and try to reconnect.

We've never implemented any locking on the database. Most of the plugins operate in their own thread and all access the database at some level. It seems to be working well enough. I know in Python a lot of things are atomic that are not in other languages. I can't really convince myself that we need it and it's seems to be working really well, but it goes against the grain on multithreaded programing to not lock common resources. Comments?

I need to interface to an MGL RDAC, if anyone has some existing code that would be nice.
If not, is anyone else interested in such a plugin? What features do you need?

I was thinking the plugin should not only get data from the RDAC over the CAN bus, but also be able to impersonate an RDAC and send data on the CAN bus.
Being able to send data as an RDAC would be quite useful for anyone who has MGL equipment.

I only have an RDAC XG to test with but the plugin should work with the XF model too.

Add a Rate calculation to the compute plugin for calculating things like turn rate from heading or vertical speed from altitude. Probably should add a rolling average type of filter to smooth it out.

In setup.py i notice "config/canfix/default.map" but the filename is map.yaml, this give me a install error.

Adding a way for FGw to handle annunciation messages has been talked about.

There is a lot more to this than it first seems. How do we deal with intermittent conditions? Do we allow overrides? Which program determines when settings have been exceeded (i.e. Low Oil Pressure?) Or do we just make it a message handler? Do we tag messages into groups (engine alarms could be separate from system alarms) or is that too complex for an airplane?

Personally, I think it need not deal with what actually causes an alarm/warning condition rather deal with distribution, clearing and logging of the messages. Let the devices or plugins that are closer to the problem determine what is an alarm and what isn't.

Right now the FlightGear plugin is only one-way. FlightGear --> FIX-Gateway. We need to add the ability to move data from FIX-Gateway to FlightGear as well.

Need a way to specify a unit conversion function in the XML file for the fgfs plugin so that we can convert to the proper units.

We need to get the program in a state where it can be distributed as a "real" application. Whether this is with pip (setuptools?) or distribution (apt, rpm, etc) or we freeze it into a binary. Personally I think we start with setuptools since that seems the most logical for a Python application. I haven't done much of this so I'm open to suggestions.

When an initialization file tries to initialize a meta data point (also known as aux data) an exception is raised and the program halts. This should print a better error message and have the program halt.

I'm seriously thinking of removing the GUI plugin from the server and adding that particular functionality to the client instead.

Some of the information that comes over CAN-FIX is kinda special and needs to be dealt with. Mostly it's parameters that come in as a group and need to be separated. For example... Time and date both contain multiple pieces of data H, M, S etc. These need to be separated into three different FGW database items when they are read in. The encoders are similar.

we need a way to set the annunicate flag on database items that aren't getting that information from the producer. We can either add a plugin or add to the compute plugin. I'm leaning toward adding it to the compute plugin.

The 'canfix' plugin is crashing when the python-canfix module raises exceptions for bad messages that it received on the CAN Bus. All of these exceptions need to be caught and the plugin continue operating no matter what.

Kyle provided one. Just have to check it in.

If no commands are issued while the server is down the client will survive and attempt a reconnect the next time a command is issued. If the server is not running while a command is issued the client will crash. It should issue an error message and try again next time.

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??

When an input callback to one of the compute plugin's functions get's called with a meta data update the plugin crashes because the meta data updates only send a float as the value instead of the tuple that a normal update would contain.

Get the documentation building properly with Sphinx.

Add airdata calculations to the system somewhere. Perhaps as an addition to the compute plugin or create a plugin specific for this.