gps base: fix Septentrio automatic configuration for RTK base station (port detection)

[bgptiste]

Issue

This pull request resolves an issue with port availability disparities across different Septentrio receivers when automatically configuring a receiver as an RTK base station for injecting corrections.

This feature was originally introduced in PR #3324.

In the initial implementation, a static set of ports was defined for RTCM stream outputs (RTK correction data):

USB1+USB2+COM1+COM2+COM3

However, hard-coding this list of ports raises two issues:

• Hardware differences between receivers: For example, Mosaic-H receivers provide serial ports USB1+USB2+COM1+COM2+COM3+COM4, whereas Mosaic-G5 receivers only support USB1+USB2+COM1+COM2. Attempting to target non-existent ports like COM3 on a Mosaic-G5 receiver will result in a command error, causing the automatic configuration to fail.
• Unnecessary multi-port output: Only one port is actively used to stream corrections. Unnecessarily broadcasting RTCM messages across unused ports can interfere with ports already reserved for other communications or setups.

Proposal

This PR introduces dynamic port detection to identify the active port used by the receiver to communicate with Mission Planner. This ensures that auto-configuration works reliably across all Septentrio receivers, regardless of their specific hardware port layout.

To achieve this, a ping command (gecm / getEchoMessage) is sent to the receiver, and the active port name is parsed directly from the prompt line in the response (e.g., USB1>), which is structured as follows:

$R: gecm
  EchoMessage [...]
USB1>

Since detection is powered by regular expressions, port names containing single or multi-digit identifiers (e.g., COM10) are dynamically matched for future-proof compatibility.

The detected port name is cached in LastDetectedPort for the duration of the active connection session (initialized during base receiver setup). This eliminates redundant detection cycles during subsequent configuration calls (such as adjusting RTCM message intervals or constellation selections).

If dynamic port detection fails or times out during setup, it gracefully falls back to targeting:

USB1+USB2+COM1+COM2

These four interfaces cover the standard default ports across Septentrio Mosaic receivers.

Testing executed

This fix has been tested and validated using the following hardware and software setup:

• Flight controller: Cube Orange+
• Autopilot firmware: ArduCopter v4.7.0
• Ground control station: Mission Planner v1.3.83 from the fix-septentrio-base-autoconfig branch
• Primary receiver (vehicle): Septentrio Mosaic-G5
• RTK base receivers tested (GCS serial/USB): Septentrio Mosaic-G5 and Mosaic-H

[bgptiste]

Hello @meee1, I'm just following up on my PR. Whenever you have a chance, I would really appreciate a review.
Thanks!

[fallenmi]

The new timeout fallback prevents the baud scan from reaching any non-default receiver speed. ConfigureBaseReceiver() first sets the host to 115200. If the receiver is actually at another baud, DetectPort() times out and returns the default string USB1+USB2+COM1+COM2; because that string contains USB, ConfigureBaudAndDetectPort() skips SendAck(), marks the receiver acknowledged, and breaks on the first iteration. It never tries 1200 through 460800.

I compiled exact base a2fcd74d and exact head 63f5b0bd against the same deterministic ICommsSerial receiver model. The device answers only at its configured baud and echoes the real Septentrio commands. With the receiver at 9600, base scans 115200, 1200, 2400, 4800, 9600, switches the receiver to 115200, and completes configuration. This head fails with FailedAckException; its complete baud history is 115200,115200,115200. A 57600 receiver fails identically, while the 115200 control succeeds.

Please distinguish a detected port from the timeout fallback. A timeout at the current baud must continue the scan (or otherwise prove communication before accepting the USB fallback); apply the fallback only after a live receiver has been established. Please add a fake-serial regression with a receiver initially at a non-default baud.

Disclosure: I used OpenAI Codex to compile and exercise the exact revisions and inspect the current PR and repository policy; I verified the result.