Thanks @modaltb , that worked! I had to set it to run as a background function using the &. It's running perfectly now.

I probably want to rewrite it as a task, but that example code looked tough to follow. I wish the PX4 developer manual included more step by step tutorials, like the ROS tutorials.

When doing firmware development or basic Flight Core setup with QGroundControl such as loading custom firmware I prefer to not need the Power Module. Unfortunately the USB connector on the Flight Core does not pass through the +5V so the board can't be powered by USB alone.

To fix this issue I hack into the provided USB cable and attach a second 4-pin connector to the +5V and Gnd wires that then can provide USB power to the CAN connector J8. See photos.

This is not ideal, but it gets the job done. I've asked Modal AI to consider making this cable themselves to sell or provide with the Flight Core kit.

I'm sure the concern is browning out the +5V from the USB.

I have discovered that the entire module seems to stop. I had been assuming it was the UART that was failing. Is there some PX4 setting where when a telemetry link occurs that something would stop/pause running modules?

When I stream the data in the terminal by launching the module manually, connected via USB to QGC, I see the stream. I then plug my base station radio in, and as soon as it gives me a blinking red light the data stream stops.

I am using RFD900x radios in a multi-radio network. Previously when I tested these radios I was using RFD900+ in a single set.

I set the module to no longer run in the background. When I use MAVLink Console to launch the module and the base station radio is disconnected (but not the radio connected to the FlightCore) I can run the module and it runs fine.

When I have the radio link connected and I use MAVLink Console to launch the module I get an error in trying to configure the port.

I have a custom module running with modified PX4 firmware on the FlightCore. It uses the UART on J4 to receive data from a custom sensor board. This has been working for over a year.

In default.cmake I comment out TEL3:/dev/ttyS1 so that I can use it for my sensor board.

We had previously used the RFD900 with the FlightCore for updating some parameters, but since we are an underwater system we had removed it a long time ago to save power.

For an upcoming customer demo in the field I was asked to install the RFD900 so that during testing the system could be removed from the water and verified to still be operational without opening up the system.

I have been having intermittent issues with getting data from my custom sensor board whenever the radio is connected. After a very short time the topic stops publishing and using listener I just see stale data. The data is also being published to the datalog and I see the data stop, while other data from the system continues to log.

I thought maybe this was a power issue, so instead of powering my sensor board from the 5V on the J4 connector I am powering directly from the battery, but am still seeing the issue.

As far as I can tell, no one else is using ttyS1. Is there an issue with having high data bandwidth on both ttyS1 and ttyS6 (UART7 on J5) that would kill my connection?

I verified the UART is working fine using the loopback method, at a few different baud rates. I think the issue is the sensor itself must be encoding the packets differently than I am reading them. I might need to reduce the baud rate down to 9600 and review the data on the oscilloscope.

The Arduino's SoftwareSerial library didn't work properly until I inverted the input, but I didn't see that option for the linux UART.

I'm trying to receive streamed data from a 3DM-GX5 AHRS via UART. I'm re-using a port I've co-opted before. Last time I ran the interface at 57,600 baud since that was the default already for the port. This time the AHRS only supports 9600, 19200, 115200, 230400, 460800, 921600.

When I try and connect at 19200 I'm not getting the 21 byte packet I expect, which was separately verified with an Arduino using SoftwareSerial.

I'm seeing a lot of 252's and 28's. I'm looking for 117,101 or if inverted 138,154.

Is there a baud rate issue with using the UART on J4? Maybe something to do with USART vs UART?

I have disabled the mapping to TEL3 in default.cmake.

I am connecting my RFD 900+ to the J5 connector on the Flight Core. The radio is configured for 57,600 baud.

I don't have any experience setting mavlink "modes."

This is an underwater vehicle, so I only communicate with it on the bench. My hope is to not have to open up the pressure vessel to pull off the data logs, which is our current method.

I know that datalog transfer through QGroundControl over USB works great. I can get download speeds of about 250 kbps. When I connect via the RFD 900x I only get download speeds of about 4 kbps. Does this seem correct? The radio boasts possible rates up to 500 kbps. Is this MavLink hogging all of the bandwidth?

Has anyone tried to remotely connect via the radio and get to Nuttx, to download the file manually? Maybe if I connected via a different COM Port and managed my own serial interface to the radio?

When doing firmware development or basic Flight Core setup with QGroundControl such as loading custom firmware I prefer to not need the Power Module. Unfortunately the USB connector on the Flight Core does not pass through the +5V so the board can't be powered by USB alone.

To fix this issue I hack into the provided USB cable and attach a second 4-pin connector to the +5V and Gnd wires that then can provide USB power to the CAN connector J8. See photos.

This is not ideal, but it gets the job done. I've asked Modal AI to consider making this cable themselves to sell or provide with the Flight Core kit.

I'm sure the concern is browning out the +5V from the USB.

Ah, when I run the PWM program there is no chatter on the PWM signals, so I'm going to review that code again and compare it to mine.