QGC appears to open/take control of USB Serial interfaces it isn't configured to use

[spiderkeys]

Expected Behavior

If there is not a CommLink automatically configured to use a serial device, nor a box selected under General settings to automatically connect via Pixhawk, then that serial device should never be opened by QGC.

Current Behavior

• Opened QGC with two serial interfaces connected on host device:
  • /dev/ttyUSB0 (USB serial adapter being used to monitor PX4 debug output on console pins via picocom)
  • /dev/ttyACM0 (USB connection to FMU intended for use by QGC
• QGC opened /dev/ttyUSB0 despite all auto connections being unchecked and no comm links specified for it (there was one specified for manual, non-auto connection to /dev/ttyACM0
• Garbage starts spewing out of the console, almost as if the flight controller has been reconfigured for a different baud rate by QGC
• Upon trying to close and re-open picocom, I am informed Device or resource busy as /dev/ttyUSB0 is being held by QGC
• Close QGC
• Re-open picocom and the device is available and comms are back to normal

Steps to Reproduce:

Steps are provided above, but the strangest thing is that the behavior appears to be random. Sometimes it happens, sometimes it doesn't.

Out of 10 tries, 7 didn't cause the issue and 3 did.

System Information

When posting bug reports, include the following information

• Operating System: Ubuntu 20.04
• QGC Version: 4.2.0
• QGC build: Daily AppImage from a few weeks/months ago
• Flight Controller: Matek H743 Wing v1
• Autopilot (with version): PX4 master

[MaEtUgR]

You might have already done this but for reference. If you don't turn of these auto connection options QGC will capture serial connections.

And you said there is a manual connecting Serial connection in use and you did disable the auto connection on that one.

But it might be the source of the issue. I would try removing it, restarting QGC and see if it persists. Just to see if there's a bug in that part.

[spiderkeys]

Thanks, the autoconnection box is unchecked for the one serial comm link I have defined (ttyACM0). I have a separate serial adapter (ttyUSB0) which is connected to the console uart pins on my FMU, which is the interface seeing the issue. There is no comm link entry in QGC for ttyUSB0, in this case.

Similarly, all of the auto connection boxes in the QGC general settings are also disabled (pixhawk, SiK, px4flow, etc):

Edit: I will give a try completely removing the manual serial link for ttyACM0 though, just in case that has an effect on the behavior.

[zdanek]

If you confirm this as a bug and you will describe steps to reproduce and then expected behavior I can fix this as I'm currently making some of my tweaks around serial comm and know this piece of QGC code.

[spiderkeys]

I can confirm now that it happens whether there are manually created Comm Links or not.

Settings:

Comm Links:

Picocom + nsh:

• nsh works fine and is responsive before opening QGC
• Open QGC and a few seconds later garbage is emitted in picocom
• nsh becomes unresponsive
  
• Close picocom and try to reopen (while QGC is still open), ttyUSB0 resource is busy
  
• Close QGC and ttyUSB0 is accessible again and nsh is responsive again
  

[spiderkeys]

The FMU physical setup, for context:

[mrpollo]

I have no experience with devices, have you seen anything like this before @DonLakeFlyer?

[DonLakeFlyer]

Shouldn't happen if autoconnect is turned off. Keeping in mind that you need to reboot QGC after you turn autoconnect off for it to take affect.

[spiderkeys]

Can confirm that autoconnect is disabled across multiple QGC restarts, w.r.t. this issue.

[DonLakeFlyer]

Someone will need to debug through this to figure out what is going on. Maybe RTK code trying to connect?

[spiderkeys]

My guesses are similar to yours - either some individual device driver/module is trying to access FTDI devices, or the Firmware Setup subsystem is taking control of it. I've noticed that Firmware Setup also disregards the fact that no manual or autoconnect links are specified.

[DonLakeFlyer]

I forgot there was a setting to turn off RTK autoconnect. Only other thing I can think of is Qt NMEA code trying to connect to an external source.

[henrykotze]

This is perhaps not related, but I have seen similar behavior when I connect FMUv5 using USB and NXP UCAN32K via serial2USB. There were some weird behavior on the NSH console of the NXP board. I will need to test again to make double sure.

[zdanek]

I'm doing some RTK related changes (actually making RTK run with Android device :D) I think I can dig into it.