Added a new option to advanced serial settings to force DTR low for E…

[wvarty]

Add configurable DTR setting to prevent ESP32 reset on serial connection

Description

QGroundControl's serial link implementation currently sets DTR high immediately after opening the port, which triggers a reset on ESP32 devices using USB serial chips (e.g., CP210x, CH340). This causes the ESP32 to reboot and lock up during telemetry connection.

This change adds a new "Force DTR Low" checkbox in the Serial Link advanced settings that allows users to force DTR low on port for devices that require it (like ESP32). Defaults unchecked for backward compatibility.

Changes:

• Added dtrForceLow property to SerialConfiguration class (defaults false)
• Modified SerialWorker::_onPortConnected() to set DTR based on configuration
• Added checkbox UI in SerialSettings.qml
• Implemented persistence in settings

Test Steps

1. Configure a serial link with an ESP32 device
2. Enable Advanced Settings, check "Force DTR Low"
3. Connect the link - ESP32 should not reset nor lock up
4. Verify telemetry communication works
5. Test with checkbox unchecked (default) - ensure existing non-ESP autopilot devices still work

Checklist:

• Review Contribution Guidelines.
• Review Code of Conduct.
• I have tested my changes (with an ESP32 TX, but I dont have other autopilots / telem modems to test with)

Related Issue

None

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[HTRamsey]

Can you provide an image of the serial setting

[Copilot]

Pull Request Overview

This PR adds a configurable DTR (Data Terminal Ready) setting to QGroundControl's serial link configuration to prevent ESP32 devices from resetting when establishing a serial connection. ESP32 devices using USB serial chips interpret DTR high as a reset signal, causing them to reboot and lock up during telemetry connection.

Key changes:

• Added dtrForceLow property to SerialConfiguration class with default value of false
• Modified serial worker to conditionally set DTR based on the new configuration option
• Added "Force DTR Low" checkbox to the Serial Link advanced settings UI

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/Comms/SerialLink.h	Added dtrForceLow property, getter/setter methods, and signal declaration
src/Comms/SerialLink.cc	Implemented settings persistence and modified DTR control logic in serial worker
src/UI/AppSettings/SerialSettings.qml	Added checkbox UI control for the new DTR setting

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[wvarty]

Can you provide an image of the serial setting

The new setting is Force DTR Low in the screenshot above.
Make sure to also turn off all the auto connect toggles (as per screenshot).

[wvarty]

The pull request CI generates binaries for the build, so if you want to test this out, you can download the installer / package for your arch below and give it a go:
Windows: https://github.com/mavlink/qgroundcontrol/actions/runs/18268655636#artifacts
MacOS: https://github.com/mavlink/qgroundcontrol/actions/runs/18268655635#artifacts
Linux: https://github.com/mavlink/qgroundcontrol/actions/runs/18268655639?pr=13482#artifacts

NOTES:
If using this on Windows, check the Force DTR Low checkbox
If using this on Linux, uncheck the Force DTR Low checkbox
Make sure you turn off all of the auto-connect toggles in the comms settings

[HTRamsey]

Based on your notes, should we just set defaults based on platform?

[wvarty]

Based on your notes, should we just set defaults based on platform?

Good question. The notes above are from my testing summary, describing behaviour specific to ESP-based devices (like ELRS TX modules), not general defaults.

The “Force DTR Low” checkbox is only required for devices that use an ESP32 USB interface, since those reset when DTR is asserted high. For most other serial devices (autopilots, modems, etc.), the existing behavior of setting DTR high should remain the default.

Windows seems to be the problematic platform here (as usual 😛), where DTR needs to be forced LOW if you are connecting to an ESP-based device. Ubuntu seems to work the opposite to windows, and if I check the Force DTR Low checkbox then attempt to connect to an ESP-based device, it triggers a lockup, so Ubuntu needs it unchecked.

The intent isn’t to set platform-based defaults, but instead to leave the behaviour exactly as it was prior to my change, while additionally giving users a way to configure this when connecting to ESP-based hardware that’s sensitive to DTR.

[wvarty]

Also worth noting:
I have tested a direct USB connection between QGC (this branch) and a Speedybee F405 wing FC.
The STM-based flight controllers dont seem to care if DTR is high or low, both will connect fine.

[DonLakeFlyer]

NOTES:
If using this on Windows, check the Force DTR Low checkbox
If using this on Linux, uncheck the Force DTR Low checkbox

All seems crazy as to how a user is going to know what to do here. Given the randomness of how all this works on the hardware/OS combination side it's hard to say what else to do though. It's kinda like "try one or the other and see what works". At least since it's under advanced most folks won't fart around with it. Should we mention something about ELRS in the UI. It seems like folks using that constantly run into piles or problems with it.

[wvarty]

Totally agree that this checkbox won't be very intuitive to the user unless they specifically know the context around it being needed for ESP devices.

If we do end up taking this proposed approach:

• I'll update the ELRS mavlink docs to call this out as a step needed if using QGC
• I can additionally consider added a note text to the UI here the explains what this is for? Happy to go either way here.

Alternatively, I can pause this checkbox approach and instead look into auto-detecting an ELRS device based on USB vendor ID data and auto-set DTR to false on Windows.

The latter approach may be tricky, and also may only work for ELRS hardware and not any generic ESP devices.

[DonLakeFlyer]

I'm ok with this is as. @HTRamsey Opinions?