[bgptiste]

Follow-up to #3752, addressing the review comments on the Septentrio automatic RTK base configuration (port detection).

Changes

• Fallback restored: If no prompt is recognised at a given baud, the legacy setCOMSettings is tried and DefaultPorts is used when it succeeds.
• Broader prompt regex: \b([A-Z]{2,4}\d{1,2})> at the start of a line, so descriptors such as IPS1, IPR1, NTR1 and OTG1 are detected, with no match inside other text.
• Simplified confirmation logic: In the baud loop, setCOMSettings is only sent when the detected port starts with COM (case-insensitive), then the port is accepted. Removed the unreachable comparisons and the case-sensitive Contains("COM").
• setDataInOut uses plain RTCMv3 when the port is detected: Avoids leaving SBF/NMEA streams enabled on the connected port, which would use telemetry bandwidth alongside the corrections. On fallback to DefaultPorts, the connected port is unknown, so +RTCMv3 is appended instead to avoid overriding streams that other ports may be using.
• activeSeptentrioPort reset on disconnect (and initialised to null), so changing the RTCM level or constellations after connecting to another receiver or port no longer targets the old port.
• DetectPort buffer trimmed to its last 32 chars (once it exceeds 64) so the regex doesn't rescan a growing string.

Testing

• Mosaic-G5 over USB (tested in gps base: fix Septentrio automatic configuration for RTK base station (port detection) #3752)

[bgptiste]

@meee1, here's the follow-up to PR #3752.

I switched back to plain RTCMv3 when the port is detected.

In the fallback case, however, the connected port is unknown and we configure several candidate ports (USB1+USB2+COM1+COM2), some of which may be in use by something else. Plain RTCMv3 would override their streams there, so in that case only I append +RTCMv3 instead. The trade-off is that SBF/NMEA streams already enabled on the connected port keep running next to the corrections, but only in the fallback. Does that sound reasonable to you?

As for the setCOMSettings path, I haven't been able to test a serial connection at a non-default baud rate, as I don't have a USB-TTL adapter to connect the receiver's COM port to Mission Planner. I only tested over USB. Could you test it on your end if you have the hardware?

[meee1]

Thanks for the follow-up. Several of the #3752 review points are handled here:

• When no prompt is recognised at a baud the receiver acknowledges, the legacy fallback to DefaultPorts is used. At a wrong serial baud the acknowledgement fails and the scan moves on, and over TCP the scan no longer fails outright.
• The prompt regex now matches IP10>, IPS1> and BT01> as well as COMx/USBx.
• activeSeptentrioPort starts as null and is reset on disconnect, so later RTCM changes no longer go to a previous receiver's port. SetEnabledRTCM still falls back to DefaultPorts for null, so this is safe.
• Plain RTCMv3 on the detected port stops leftover SBF/NMEA streams using telemetry bandwidth.

One thing to fix before merge, inline:

1. Corrections reach only the port the PC is on (Septentrio.cs:102). This was point 3 of the #3752 review and is still open. Before #3752 the base sent RTCM to USB1+USB2+COM1+COM2+COM3 and set the baud on all three COM ports. With a detected port, setDataInOut and setRTCMv3Output now target only that port, so a PC on USB1 with a telemetry radio on COM2 stops sending corrections to the radio with no error. COM3 is also dropped from DefaultPorts and from the fallback setCOMSettings,COM1+COM2. Since #3752 is merged, this is a regression on master today, and this PR is the place to fix it.

Smaller things:

• Only USB has been tested. Serial at a non-default baud, TCP (the IP10> case) and Bluetooth have not, so those paths are unverified on hardware.
• No tests. DetectPort and ConfigureBaseReceiver are public and take an ICommsSerial, so a fake port could cover the baud scan (a receiver starting at 9600, as suggested on #3752), the prompt regex and the fallback without hardware.
• After trimming to the last 32 characters, the regex's ^ matches at the cut point, so a mid-line fragment like ABC12> could be read as a prompt. That is unlikely with gecm replies; trimming at a line break, or dropping ^, would remove it.
• The failing Build Release job is Sysid32Tests.LiveLinkReadsFragmentedFramesAndTargetsWithoutAliasing, a timing-sensitive MAVLink test this PR does not touch. A re-run should clear it.

Review by Claude Code (Claude Opus 5.5, model claude-opus-5-5, medium effort) on behalf of @meee1, from the diff at 1360675 and the Septentrio code it calls, compared with the behaviour before #3752. Not built or run against a receiver.

🤖 Generated with Claude Code

[meee1]

With a detected port, targetPorts is that one port (for example USB1), so RTCM is output only where the PC is connected, and SetEnabledRTCM later sets the messages on that port alone. Before #3752 this was setDataInOut,USB1+USB2+COM1+COM2+COM3,Auto,RTCMv3, with setCOMSettings and setRTCMv3Output on the same five ports. A base whose corrections go to the drone through a telemetry radio on COM2, while the PC is on USB1, now stops sending them to the radio with no error.

COM3 is also gone: it is not in DefaultPorts (USB1+USB2+COM1+COM2) nor in the fallback setCOMSettings,COM1+COM2.

Suggested fix: keep sending RTCM to the full set including COM3, using plain RTCMv3 on the detected port as this PR does, or make the target ports a setting.

[bgptiste]

Thanks for the review.

On the main point (RTCM only reaching the detected connected port), I covered this in #3752 (comment).

In short:

• setDataInOut and setRTCMv3Output only affect the ports named in the command, so RTCM/SBF/NMEA already configured on other ports is not overwritten or disabled.
• COM3/COM4 were intentionally removed because they don't exist on every model. On boards like the Mosaic-G5, targeting them makes the SBF commands fail and breaks the auto-configuration.

I do see your point about a PC on USB1 and a telemetry radio on COM2: that radio no longer gets corrections from the auto-configuration, and there is no error. But this was part of the goal of #3752, sending RTCM only on the port Mission Planner is actually connected to, to avoid side effects on interfaces the user didn't ask to touch (leftover streams, other devices sharing the receiver, ports that don't exist on every model).

If you'd still like to cover this case, I can append COM1+COM2 to the detected port (deduplicated) for setDataInOut and setRTCMv3Output, while keeping setCOMSettings on the detected port only.

Good catch on the ^ at the trim point, I'll drop it in the next commit.