[dacacioa]

Closes #5610

Summary

Hermes Lite 2 TUNE uses a full-scale host IQ carrier amplitude of 1.0, while software CW used 0.5. Because RF power follows the square of IQ amplitude, CW was approximately 6 dB below TUNE at the same RF Power setting.

This changes the CW carrier amplitude to the shared full-scale value, so CW and TUNE use the same host-side carrier level while preserving the existing 5 ms raised-cosine keying envelope. The TX drive register remains the operator's power control and the existing transmit-authorisation gates are unchanged.

Implementation

• Added the shared kHl2CarrierAmplitude constant in MetisProtocol.h.
• Used it for both host-generated CW and TUNE carriers.
• Added a deterministic hl2_tx_gate_test regression check that compares the encoded CW plateau IQ with the encoded TUNE carrier.
• Rebased the branch onto the latest main, preserving the newer TUNE drive-restoration logic.

Operator impact

At a fixed drive setting, this restores the intended CW level and represents a +6.02 dB RF-power correction relative to the previous host-CW amplitude. It does not introduce a new maximum beyond the existing full-scale TUNE path. The change has maintainer approval for the safety-labelled issue.

Validation

• Local Windows build completed with MSVC 2022, Qt 6.12.0, and CMake.
• hl2_tx_gate_test passes all checks.
• The resulting AetherSDR.exe was deployed with its Qt runtime and launched successfully.
• Functional testing on real Hermes Lite 2 hardware with an external wattmeter measured more than 5 W and confirmed that CW was no longer limited to approximately 1 W.
• The commits are SSH-signed.

No CHANGELOG entry is included; the operator-visible power correction is documented above for release-note consideration.

[aethersdr-agent]

Welcome to AetherSDR, @dacacioa! Thanks for your first pull request.

A few things that might help:

• Our CONTRIBUTING.md covers coding conventions and the PR process
• CI will run automatically — if it fails, I'll post a comment explaining what went wrong
• Jeremy (KK7GWY) reviews all PRs before merge
• Come say hello on the AetherSDR Discord — most of the community hangs out there, and merged contributors get the Contributors role

If you have questions, feel free to ask here or in Discussions.

— AetherClaude (automated agent for AetherSDR)

---

_{🤖 aethersdr-agent · cost: $118.1678 · model: claude-opus-5}

[dacacioa]

Local validation completed

• Local build completed successfully on Windows with MSVC 2022, Qt 6.8.3, and CMake/Ninja.
• Generated the AetherSDR.exe test executable.
• Ran the test build.
• Functional testing was performed on a Hermes Lite 2 with an external wattmeter: CW is no longer limited to approximately 1 W, and more than 5 W was measured in the tested setup.
• The existing 5 ms raised-cosine envelope is preserved to avoid key clicks.

[aethersdr-agent]

Issue fit

Yes — this is the exact one-line change #5610 asks for, and the issue's diagnosis holds up against the head checkout. I confirmed both halves of the comparison rather than taking them on faith:

• Hl2Backend::setTune() calls setTxTestTone(0.0, kTuneCarrierAmplitude, …) with kTuneCarrierAmplitude = 1.0 (src/core/backends/hl2/Hl2Backend.h:1463, used at Hl2Backend.cpp:5788).
• At TUNE's zero offset, dphi == 0, the phase accumulator never advances, and the tone arm emits {m_toneAmp*cos(0), -m_toneAmp*sin(0)} = {1.0f, 0.0f} — bit-identical to the CW plateau after this change (MetisClient.cpp:1583-1594 vs :1574). So "match CW carrier level to TUNE" is exact, not approximate.
• Drive is genuinely shared: CW rides setTxPower() → applyDrive(), TUNE applyDrive(tunePowerPercent); at 100/100 both write the same register. Nothing else attenuates CW.

What the issue's triage asked for and this PR does not do: the regression test, and folding the two literals into one shared constant. Those are my findings below.

Scope

File	Change	Claimed by title/body?	Verdict
src/core/backends/hl2/MetisClient.cpp	kCwCarrierAmplitude 0.5 → 1.0 (one line)	Yes	In scope

Everything in the diff is explained by the issue. No unrelated files, no formatting churn, no deleted guards, no new public surface, no CHANGELOG.md entry (correct — don't add one).

Blockers

1. No test pins the CW carrier level, and a deterministic socket-free seam exists. — inline at MetisClient.cpp:1562. tests/hl2_tx_gate_test.cpp already decodes EP2 payload bytes byte-exactly (:458-461, for the queued-voice arm), but its CW section (:483-523) asserts only payloadNonZero(). That means (a) nothing in the suite would have caught the original 0.5, (b) nothing fails today, which is why all five checks are green, and (c) nothing stops the constant drifting back. This is wire encoding with an existing, deterministic, socket-free harness — the layer AGENTS.md puts in CTest — so the coverage gap is actionable rather than a nice-to-have. Concrete shape in the inline comment.

Needs maintainer decision

2. This is a power-increasing change on a keyed transmitter (4× on the CW carrier), and #5610 carries both safety and maintainer-review. Nothing in the thread is a maintainer ruling yet — the only comment is the agent triage. Two things bound the risk and are worth stating in the PR body: the new level is exactly what TUNE already emits at the same drive register, so no new maximum is introduced anywhere in the HL2 TX path; and CW stays gated by m_txAllowed at both setCwKeying() and setCwKeyDown(). But operators who compensated for the deficit with external gain will see a real 6 dB step on their next over, so this wants a release-note line (in the PR body / release notes, not CHANGELOG.md).

Nits (non-blocking)

• Two unlinked literals now have to stay equal. Hl2Backend.h:1463 holds kTuneCarrierAmplitude = 1.0; MetisClient.cpp:1562 holds a file-local kCwCarrierAmplitude = 1.0. The entire point of this PR is that they match, and nothing enforces it — the next person to change one won't see the other. #5610's triage suggested promoting it to one shared named constant; at minimum a cross-reference comment.
• The comment block above the constant still justifies only the ramp, not the plateau — the raised cosine and the 5 ms figure are explained, the level is not. That unexplained literal is precisely how the original defect survived review in #5061. One line ("full scale, same as kTuneCarrierAmplitude — the drive register is the operator's only power control") would close it.
• The commit message contains a literal \n\n before "Principle VI." Also, VI is "never transmits without operator intent" — this change doesn't touch keying or intent at all; the safety relevance here is the level step, which is better described than cited.

What I tried to break

• Full-scale clipping / rail wrap. ep2WriteTxIq's clamp is symmetric to ±32767, not ±32768 (MetisProtocol.cpp:271-277), so 1.0 encodes 0x7FFF with no wrap to the negative rail. TUNE has been riding that exact path at 1.0 already. Survived.
• Envelope / key-click regression. kCwRampSamples = 5 * 48000/1000 = 240; kTxSamplesPerPacket = 126, so the ramp still spans ~1.9 packets. The constant multiplies shaped, so the raised-cosine shape, the rise, and the symmetric fall are untouched — only the plateau scales. No new discontinuity at key-up. Survived.
• Sibling call sites. Grepped the head checkout: kCwCarrierAmplitude has exactly one definition and one use. No second host-CW generator in aetherd, Hl2TxDsp, or elsewhere. The voice path is separately governed by the Hl2TxDsp ALC and is unaffected. Survived.
• Would an existing test break? No — the byte-exact assertions at hl2_tx_gate_test.cpp:458-461 belong to the queued-voice arm (0.5 → 0x3FFF), not CW. Consistent with the five green checks, and also why finding 1 matters.
• Was 0.5 deliberate? git log -L traces it to 267c86f2 (#5061), introduced with the feature and with no rationale in the commit or the surrounding comments. A duty-cycle argument wouldn't distinguish CW from TUNE anyway, since TUNE is itself a continuous carrier held as long as the operator holds it. I found nothing defending the old value.
• Could not check: real HL2 gateware / PA behaviour under sustained full-scale key-down, and whether the gateware applies any CW-specific level scaling of its own. I'm headless — no build, no hardware. Every finding above is reasoned from the code in /tmp/aetherclaude/pr-5975, not reproduced at runtime.

Recommendation

Approve with nits, pending a maintainer sign-off on the power step and a regression test. The change itself is correct and minimal, and I could not find a way to make it misbehave — it makes CW bit-identical to a path that already runs at this level. What I'd want before merge is the test from finding 1 (cheap, deterministic, and the thing that would have prevented the original bug), plus the maintainer ruling the safety label is asking for. The two constants-hygiene nits can ride along in the same push.

Thanks for the clean diagnosis in #5610 — the amplitude-squared reasoning matched the source exactly, which made this fast to verify.

---

One more thing: commit signing

main requires verified signatures, and 1 of your commits on this branch is unsigned — routine setup, not a code problem.

Quickest path (SSH key signing, no GPG needed):

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

(If you have no SSH key yet: ssh-keygen -t ed25519 first.) Then on GitHub: Settings → SSH and GPG keys → New SSH key, set the key type dropdown to Signing Key, and paste the .pub.

Re-sign what's already on the branch:

git rebase main --exec "git commit --amend --no-edit -n -S"
git push --force-with-lease

Full reference, including GPG and troubleshooting: https://docs.github.com/authentication/managing-commit-signature-verification

---

_{🤖 aethersdr-agent · cost: $3.4821 · model: claude-opus-5}

[on8st]

@dacacioa, v26.10.1 shipped without this, so CW is still 6 dB under TUNE there: kCwCarrierAmplitude is still 0.5 in MetisClient.cpp against kTuneCarrierAmplitude = 1.0 in Hl2Backend.h. This PR no longer merges: at head e7e9b3ac a trial merge with main (8df6db2f) conflicts in Hl2Backend.cpp and Hl2Backend.h, and the PR shows no CI run.

Merging main into the branch should get it moving again. If you want a hand with the two conflicts, say so and I will propose resolutions here; the branch stays yours.

Not checked: I did not build the branch, run its test or key a radio, and I have no power measurement of my own for CW against TUNE.

73, ON8ST

[ten9876]

Reviewed head e7e9b3ac89460b65d4e3b635f74226e3a4b3e180.

Issue fit: Yes at the host-IQ seam. #5610 reports CW at half TUNE's amplitude for the same drive. The shared full-scale constant makes their encoded plateaus equal; the 5 ms raised-cosine envelope and authorization gates remain unchanged. Actual RF output remains hardware-owner evidence, which I did not independently reproduce.

Scope

File/group	Change	Claimed?	Verdict
MetisProtocol.h, Hl2Backend.{h,cpp}	Share carrier amplitude, remove duplicate constant	Issue proposes it	In scope
MetisClient.cpp	CW plateau 0.5→1.0	Yes	Direct fix
hl2_tx_gate_test.cpp	Compare encoded plateau against TUNE	Issue proposes it	In scope; update body

No unrelated file, changed drive setting, new command, removed TX gate or changelog entry. Authored commits are limited to this fix.

Blockers

None found.

Nits (non-blocking)

1. tests/hl2_tx_gate_test.cpp:519: describe the added host-level regression check in the PR body; the text currently mentions only the absence of an automated RF test and still says validation is in progress.
2. src/core/backends/hl2/MetisProtocol.h:46: retain explicit maintainer attention to the 6.02 dB CW amplitude correction, as requested by the issue thread. Principle VI concerns operator transmit intent, not the body's description of “unrelated scope.” The existing gates remain intact.

Verification and attacks

• Rechecked the complete modified test: it injects stream/sink state and never calls transport start/connect/bind. No synthetic peer, sockets, hardware, or RF used.
• Compiled a focused C++20/Qt 6.11.2 harness against this head's production MetisClient, MetisProtocol, control-request, emergency-stop and TxCoordinator code, using the real test authority. After five CW packets, first IQ bytes versus TUNE were 7f/7f ff/ff 00/00 00/00 equal=1.
• Changed only the CW multiplier back to 0.5 in scratch: 3f/7f ff/ff 00/00 00/00 equal=0, exit 1. The encoded-sample comparison detects the reported defect. This was a focused harness, not a run of the full hl2_tx_gate_test or application.
• Read the key-up ramp and closed-gate branches; no logic changed there. No bridge session: SimBackend cannot transmit or exercise this HL2-specific path. Wattmeter and Windows-build claims remain author evidence.
• All four engine-boundary/manifest/capability/command-plane gates pass on merge base and head with byte-identical output. No new #5554 coupling. Separate automated review skill unavailable; independent manual audit and mutation performed instead.

CI and recommendation

Approve with nits, subject to maintainer acceptance of the power correction and required checks. Current PR check rollup is empty; this is not a green-CI claim. Earliest historical run at this head is 2026-09-28T17:24:30Z, before main's 2026-10-04T18:26:40Z; historical merge checks do not prove today's integration, and non-strict branch protection does not force their refresh. Update test-plan prose and verify required checks before landing.

— Jeremy KK7GWY + Codex

[ten9876]

Independent re-review at head e7e9b3ac89460b65d4e3b635f74226e3a4b3e180. Same head as the earlier ten9876 + Codex review. I re-checked its claims, ran the real test target where it used a scratch harness, and went to the HL2 gateware for the level itself.

Issue fit: yes. #5610 reports CW about 6 dB under TUNE at the same drive. Two things now match on the wire: the shared kHl2CarrierAmplitude = 1.0 (MetisProtocol.h:46) sets the CW plateau (MetisClient.cpp:1574), and TUNE reads the same constant (Hl2Backend.cpp:5788). The 5 ms raised-cosine ramp, the drive register and every TX gate are untouched.

Scope

File	Change	Claimed?	Verdict
MetisProtocol.h	Adds shared kHl2CarrierAmplitude	Proposed in #5610 triage	In scope
Hl2Backend.{h,cpp}	Drops the duplicate kTuneCarrierAmplitude and uses the shared one	Same	In scope
MetisClient.cpp	CW plateau 0.5 → shared 1.0	Yes	The fix
tests/hl2_tx_gate_test.cpp	Encoded CW plateau compared byte-for-byte to TUNE	Asked for in #5610	In scope; not mentioned in the body

Everything in the diff is explained by the issue. There's one signed commit and no CHANGELOG entry.

Blockers

1. This no longer merges with main. git merge-tree origin/main <head> reports conflicts in src/core/backends/hl2/Hl2Backend.cpp and Hl2Backend.h. main has moved through this code since the branch was cut (#6104 live TUNE power, #6119, #6127, #6109, #5919). The conflicts are context-only:

   • On main, kTuneCarrierAmplitude is still defined once (Hl2Backend.h:1059) and used once (Hl2Backend.cpp:5073).
   • On main, kCwCarrierAmplitude is still 0.5 (MetisClient.cpp:1459), so the fix is still needed.

   Rebase, keep the deletion and the shared constant, and re-run hl2_tx_gate_test.

Nits (non-blocking)

• The PR body's test plan is out of date. It still says "validation in progress" and "No automated RF test was added", but tests/hl2_tx_gate_test.cpp:519-526 now pins the host-side level. Say so in the body: it is the regression guard the original 0.5 never had.
• Principle VI is cited for "focused scope". VI is about operator transmit intent. This change does not touch intent, keying or gating. What it does change is a +6.02 dB step in CW output at a fixed drive setting, and that should be stated plainly for the release notes (not CHANGELOG) and for the safety label's sign-off.

HL2 gateware: the authority for the level

The earlier reviews could only show that CW now equals TUNE. The gateware shows that 1.0 is also the level its own designers picked for CW.

• In softerhardware/Hermes-Lite2 gateware/rtl/radio_openhpsdr1/radio.v, the gateware's own keyer feeds the TX CORDIC directly with tx_i = tx_cw_key ? {1'b0, tx_cwlevel[18:4]}, ramping to MAX_CWLEVEL = 19'h4d800, i.e. 0x4D80 at the CORDIC. The comment says "Set CORDIC for max DAC output … 0x7FFF/1.7".
• Host IQ instead passes through the interpolating FIR and the CIC. The gain note in the same file (the block before generate if (NT == 0)) puts the CIC at 0.61 × (1 − 1/128) ≈ 0.605. The 1/128 trim exists precisely so "a full range 16 bit I/Q signal" does not wrap the DAC.
• Host full scale is therefore 0x7FFF × 0.605 ≈ 19,830 ≈ 0x4D76 at the CORDIC, within 0.05 % of the gateware keyer's 0x4D80.
• The old 0.5 put host CW 6 dB under the gateware's own CW level. This change puts it at that level.
• Caveat: I took the FIR stage (FirInterp8_1024) as unity passband gain and did not trace its coefficients.

Verification and what I tried to break

• Built the exact head and ran hl2_tx_gate_test, the real target rather than a harness: all checks passed. Socket preflight: the file states "No start(), bind(), peer or datagrams" (:30) and injects stream state. No socket and no synthetic peer.
• Mutation: I put the CW plateau back to 0.5 * shaped and rebuilt. Result: FAIL: CW plateau matches TUNE carrier amplitude (#5610). Restored (sha256 matches HEAD, touched, rebuilt): all checks pass again. The test pins exactly the reported defect.
• The test samples the right packet: packet 5 starts at sample 504, past the 240-sample (5 ms × 48 kHz) ramp, so it compares plateau to plateau rather than catching the ramp.
• Clipping and wrap at 1.0: ep2WriteTxIq clamps symmetrically to ±32767, and TUNE already runs this exact code path at 1.0 in the field. The gateware's 1/128 CIC trim covers full-scale input.
• Not reproduced: RF output on a real HL2 and the wattmeter numbers (author's evidence). No bridge session, because SimBackend cannot transmit and does not run the HL2 EP2 path. I never keyed anything.
• CI: the earliest run on this head (2026-09-28) predates main's current tip, and the conflict above confirms the green no longer describes a real merge.

Recommendation: request changes for the rebase. After that it is ready, subject to Jeremy's sign-off on the +6 dB CW step, which the safety label on #5610 asks for. The level matches the HL2 gateware's own CW keyer.

— Jeremy KK7GWY + Claude

[ten9876]

Maintainer sign-off: the +6 dB HL2 CW carrier step (0.5 → 1.0, matching TUNE and the gateware keyer level) is approved for #5610's safety label. Remaining: the rebase onto main from the review above.

— Jeremy KK7GWY + Claude

[dacacioa]

Rebased onto the latest main and resolved the conflicts while preserving main's newer TUNE drive-restoration logic.

Validation after the rebase:

• Local Windows Release build completed with MSVC 2022, Qt 6.12.0, and CMake.
• hl2_tx_gate_test passes all checks.
• The resulting AetherSDR.exe was deployed with its Qt runtime and launched successfully.
• The commits remain SSH-signed.

The PR description has also been updated to document the deterministic regression test and the +6.02 dB CW power correction. GitHub now reports the PR as mergeable.

[dacacioa]

Review follow-up completed.

The requested regression test, shared carrier constant, maintainer safety approval, rebase, local Release build, and executable validation are all complete. There are no unresolved inline review threads remaining, and GitHub reports the PR as mergeable.

[jensenpat]

Reviewed 9b6935a96df2a6845c3d78a94f28ea2a8844cbda.

Issue fit: Yes. #5610 asks for host CW to use the same carrier amplitude as TUNE at the same drive. This head does that with one shared kHl2CarrierAmplitude = 1.0. The 5 ms raised-cosine envelope, the transmit gates, and the current TUNE drive-restore path stay as they are.

Scope

File	Change	Claimed?	Verdict
MetisProtocol.h	Shared full-scale kHl2CarrierAmplitude	Yes	In scope
Hl2Backend.h, Hl2Backend.cpp	Drop the duplicate tune constant; TUNE uses the shared one. m_rfDriveOwed / applyDrive before the carrier is unchanged	Yes	In scope
MetisClient.cpp	CW plateau uses the shared constant	Yes	The fix
tests/hl2_tx_gate_test.cpp	Encoded CW plateau compared with a zero-offset TUNE carrier	Yes	In scope

No unrelated files, no new protocol or keying surface, no removed gate, no CHANGELOG entry. One verified-signed commit; its parent is current main (334276112c4bcbf3dd52ad26116569638d21d20a). #5554: no new family-string branch, raw Flex wire text, dynamic_cast, capability, or keying verb. Hermes-Lite 2 only.

Blockers

None. The earlier changes-requested review was the rebase onto main. This head is that rebase: one commit ahead, zero behind, and the newer TUNE drive-restore logic is still in setTune.

Verification

• Required checks on this SHA are green: build, check-macos, check-windows, Static checks, and Sanitizer option configures. Per-PR CI compiles hl2_tx_gate_test and does not run it (frozen gate in ci.yml).
• Local Qt 6.12.0 RelWithDebInfo, QT_QPA_PLATFORM=offscreen: hl2_tx_gate_test passed, 1/1.
• Mutation of the CW plateau back to 0.5 * shaped failed CW plateau matches TUNE carrier amplitude (#5610) and exited 1. Restored source matches this SHA and the test passed again.
• Packet 5 starts at sample 504. The ramp is 240 samples (5 ms × 48 kHz), so the compared sample is on the plateau. ep2WriteTxIq clamps full scale to 0x7FFF, the same encoding TUNE already uses.
• The modified test injects builder state. It does not bind, listen, or connect, and it does not start a peer.
• Not run here: a wattmeter on a live Hermes-Lite 2. The author's hardware note stays author evidence. This does not raise a host maximum above the existing TUNE carrier. At a fixed drive it is a +6.02 dB CW correction, which is what #5610 asks for. Principle VI is unchanged: keying still requires an admitted operation and an open transmit gate.

Recommendation: Approve.

Non-blocking follow-up

hl2_tx_gate_test is outside the frozen per-PR ctest gate, so this assertion is proven by the local run above and by the post-merge full suite, not by the PR checks. A later seam worth adding, not a merge prerequisite: drive the TUNE side through Hl2Backend::setTune as well as MetisClient::setTxTestTone, so a backend-only amplitude split fails the same comparison. Hermes-Lite 2 only.

[jensenpat]

Reviewed 78331f1e878f843a12391658607c4e0fd0098af8.

Taking the review. This is the same CW/TUNE carrier fix rebased onto current main (4249b71d5c24d078832f4f6bbc0a2f0e1777c905). Author remains David Acacio; the rebase commit is signed by jensenpat. One commit ahead, zero behind. The diff is still the five host-IQ files.

The earlier changes-requested review asked for that rebase. It is done. hl2_tx_gate_test passed on the pre-rebase patch (9b6935a96), and this rebase applied with no conflicts and no further edits. Required checks on this SHA are still starting.

Recommendation: Approve.

Rebase requested by this review is now head 78331f1, parent current main, signed, and approved.