Posts made by Andrew Keefe

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.

I don't have a pwm_out driver. I do have a pwm_servo, and it's being called from PX4FMU, such as from update_pwm_out_state.

What I need to do, I think, is disable the mixer values for PWM so that I can set them manually. I'm not sure if my

ret = px4_ioctl(fd, PWM_SERVO_SET(PORT_FIN), pwm_value);

command goes to the mixer, or if I can bypass the mixer in mixer_module.cpp.

I'm basically commenting out things one at a time to see what happens since I'm not set up to step through the code.

@modaltb Can you help point me to where PWM is being enabled once EKF2 is initialized? I can't seem to get rid of this chatter.

That worked, and now I'm getting pitch from vehicle_attitude.
With the filter enabled though, PWM is also being enabled by the system, which is interfering with the code I wrote to manually control them. I'm getting chattering.

I branched off of version 1.0.

Just the flight controller, and honestly not really even that. Just the sensors. There is no vision. I will connect my compass and calibrate it and see if that does the trick. I'm on the bench so rotating the compass isn't always easy.

Is there a parameter I need, or a minimum number of sensors, to produce a vehicle_attitude message? I'm looking for a clean pitch/roll/yaw but it's not being published. I don't have a GPS/compass plugged in at the moment, but my gyros and IMU are calibrated.

Good question. These servos don't specify the logic power so I'll have to measure it.
I'm not seeing 5V at all though on the PWM breakout board. It should be the middle set of pins, correct?

Do you know why the 5V on the J7 PWM connector is for "reference only"? If I need to provide 5V to my PWM logic on the center rail of the 8-channel breakout, then I need to cut into the cable? Or I suppose I can provide 5V power on one of the other channels since I'm currently only using 4 of them, but now I need to find 5V from somewhere.

Has anyone been able to program the board via RF? It's generally not advisable, I know. I was just hoping to expedite hardware testing with the board inside a pressure vessel. I tried with the PX4 build tools, Mission Planner, and QGroundControl and none of them seemed to find the board through the radio after the power cycle.

I'm running a serial connection to a sensor wired as simplex. The code runs fine when the sensor is there. I wanted to turn the LED yellow if the serial read times out and returns no data, but the read function is blocking. It just sits there indefinitely.

I am playing around with

char buff = {0};
int fd;

fd = open("/dev/ttyS1", O_RDONLY | O_NOCTTY | O_NONBLOCK);
struct termios config;
tcgetattr(fd, &config);
config.c_iflag &= ~(IGNBRK | BRKINT | ICRNL |INLCR | PARMRK | INPCK | ISTRIP | IXON);
config.c_oflag = 0;
config.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN | ISIG);
config.c_cflag &= ~(CSIZE | PARENB);
config.c_cflag |= CS8;
config.c_cc[VMIN] = 0;
config.c_cc[VTIME] = 10;
cfsetispeed(&config, B57600);
cfsetospeed(&config, B57600);
tcflush(fd, TCIOFLUSH);
tcsetattr(fd, TCSANOW, &config)

ret = read(fd, &buff, 1);
if (ret<=0) {
status_yellow();
}

Yes, that worked. I placed it in rc.fw_apps