High SWR Detected by Firmware

I am getting the same error PGXL High SWR Detected by Hardware. Please stop Transmission.

This is only happening on 160 band, all others are fine, and I can use the same antenna on other bands (as the SWR is low) or a dummy load and it works fine.

This is only happening on 160 with an antenna, or a dummy load.

73 Jeff WB4TT

Hello FlexRadio team,

Happy New Year 2026!
Even four years later, I am still occasionally seeing the message “High SWR Detected by Firmware.”
My setup is:
FR6600, SmartSDR v4.1.5
TGXL firmware v1.2.17
PGXL firmware v3.8.9
TX delay is configured so that the switching sequence is sufficiently long.
The issue appears during SO2R CQ operation (2BSIQ). When running CQ on only one band, I have not observed this behavior.
Is there already a known “cure” for this issue, or do you have any better recommendations or best practices to avoid it?
Thank you for your professional feedback.
73,
Simon S53K / NA3AA / CQ3A

Hi Bill,

thank you for your detailed report, and I’m very sorry to hear about your PGXL incident. That certainly sounds serious, and I hope FlexRadio will be able to identify the root cause precisely and get your amplifier fully restored.

Fortunately, my situation is significantly less dramatic.
In my case, I am experiencing repeated “High SWR Detected by Firmware” events, but without permanent hardware failure. RF output remains available afterward and the system continues to operate. Importantly, this behavior appears only in SO2R 2BSIQ CQ scenarios. During single-band CQ operation or conventional TX use, I have never seen this warning.

Based on observation, this does not appear to be a classical antenna SWR or RF path problem. Instead, it looks more like an artifact related to timing interactions and transient conditions within the Flex ecosystem, specifically under high-speed SO2R switching. Potential contributing factors may include:

• RF interlock / PTT sequencing timing margins
• TGXL band-switching latency and relay settling time
• short-duration impedance excursions during path transitions
• very brief, but firmware-detectable SWR excursions (“micro-spikes”)
• combined interaction timing between FLEX-6600, TGXL, and PGXL controllers

These kinds of edge conditions would not normally manifest in single-band operation, but are far more likely in an aggressive SO2R / 2BSIQ environment, where timing tolerances are stressed to their limits.

What I was hoping to receive from FlexRadio engineering here was clear technical guidance, for example:

• whether this is a known characteristic of current firmware
• whether specific delay, TX sequencing, or TGXL/PGXL parameters are recommended
• whether there is a preferred firmware matrix for SO2R stability
• or whether this behavior is being investigated as a candidate for firmware refinement

So far, regrettably, there has been no engineering-level response from Flex, which is disappointing given that SO2R is explicitly promoted as a supported operating scenario. For transparency: I posted this same technical inquiry in a Flex Facebook community — it was initially approved, then subsequently removed without explanation, which was… somewhat mysterious behavior.

Bill, thank you again for sharing your case. Please do keep us updated on what Flex Support concludes regarding your PGXL event. I know many of us operating serious SO2R stations are very interested in understanding where the system protection limits truly are, and whether these transient behaviors are expected or tunable.

73,
Simon S53K / NA3AA / CQ3A