Random signal jumps during FT8 TX with TCI

[kn7k]

Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

Image attached.
It is pretty random jumps, sometimes TX is clean and most of the times it looks like below

JTDX with TCI connection.
It is not just in ver26.8.3, observed the same in previous versions.

Sergey, KN7K

What did you expect?

Noise free TX

Steps to reproduce

TX with FT8, observe TX signal

AetherSDR version

26.8.3

Radio model & firmware

8600-4.1.5

Operating system

Windows

OS version and hardware

Win11

[aethersdr-agent]

Thanks Sergey — and thanks for noting it predates 26.8.3, that's a useful constraint.

I traced the TCI TX audio path end to end. The symptom (mostly-clean transmissions with random breaks/spurs, same on older builds) is consistent with a timebase/rate discontinuity in the TCI TX pipeline, not with a DSP or radio-side problem: FT8 is a constant-envelope continuous tone, so any dropped, doubled, or zero-padded block turns into wideband splatter for the duration of the discontinuity. There are three places in that path that can produce exactly this, and I can't pick between them without one line from your log — hence the questions at the bottom.

The path

JTDX doesn't push TX audio on its own; AetherSDR pulls it. TciServer runs a TX_CHRONO pacer (src/core/TciServer.cpp:417-445) that emits one header-only chrono frame per 21.333 ms, each asking for 2048 floats = 1024 stereo frames @ 48 kHz (kTxChronoSamples, src/core/TciServer.cpp:74-78, sendTxChronoFrame() at :3154-3170). JTDX answers with one binary TX_AUDIO frame per chrono. onBinaryMessage() (:2150-2329) classifies the payload, resamples 48 k → 24 k, applies TCI gain, and hands it to AudioEngine::feedDaxTxAudio(), which collapses to int16 mono and emits dax_tx VITA-49 packets immediately, unpaced (src/core/AudioEngine.cpp:9052-9088).

1. audio_stream_samples is falsely acknowledged (TciServer.cpp:1119-1123)

if (trimmed.startsWith("audio_stream_samples:")) {
    // Samples per audio packet — acknowledge but we use fixed packet sizes
    replyText(ws, cmd.trimmed() + ";");

We echo the client's requested block size back verbatim — i.e. we confirm it — but the chrono pacer keeps its hardcoded 2048. Our ready burst advertises audio_stream_samples:2048 (src/core/TciProtocol.cpp:496-500), which is why WSJT-X, which takes that value, is well-behaved. A client that sets a different value gets an ack and then produces audio at a rate we're not requesting at. A 2× mismatch means the radio's dax_tx input is fed at 2× real time all transmission long, overflows, and drops — random breaks, envelope intact in between. tx_stream_audio_buffering: (:1124-1128) is acked and ignored the same way. This is my prime suspect precisely because you're on JTDX rather than WSJT-X.

2. The chrono catch-up burst is unbounded (TciServer.cpp:441-444)

m_txChronoAccumNs += m_txChronoClock.nsecsElapsed();
while (m_txChronoAccumNs >= kTxChronoPeriodNs) {
    sendTxChronoFrame(client);
    m_txChronoAccumNs -= kTxChronoPeriodNs;
}

The accumulator is correct on average, but after any event-loop stall (waterfall/panadapter repaint, a Windows scheduling hiccup) this loop fires the whole backlog at once. JTDX replies with a burst of blocks, and since feedDaxTxAudioInternal() packetizes and emits with no wall-clock pacing, hundreds of ms of audio lands on the radio in one shot. Note the Opus TX path already solved this problem for itself — OpusTxPacer with a bounded catch-up batch and a ~200 ms queue cap (AudioEngine.cpp:8511-8527); the DAX/TCI route has no equivalent. Worse, a client asked for more audio than it has ready typically answers with a zero-padded block, which puts a hole in the middle of the tone.

3. Mono/stereo is re-decided per block, on content (TciServer.cpp:2225-2255)

Each block is classified by comparing the first 128 float pairs: if ≥90% have L≈R it's treated as duplicated stereo (N floats = N/2 frames), otherwise as mono (N floats = N frames). There is no hysteresis and no session latch, so the decision can flip between consecutive blocks, and a flip changes that block's timebase by a factor of two. Any all-zero block — the TX lead-in, or a zero-padded block from mechanism 2 — trivially satisfies the "all pairs equal" test regardless of what the client actually sends. One flipped block inside a continuous FT8 tone is a textbook splatter event.

Proposed fix

• TciServer.cpp:1119-1128 — reply with the value actually in force (2048 / 50 ms) instead of echoing the request, or honor the client's value by deriving kTxChronoSamples/kTxChronoPeriodNs per session. A false ack is the worst of the three options.
• TciServer.cpp:441 — clamp the catch-up to 1–2 frames per tick and cap m_txChronoAccumNs at a bounded backlog, and pace dax_tx emission in feedDaxTxAudioInternal() the way OpusTxPacer paces Opus.
• TciServer.cpp:2225 — latch the mono/stereo decision for the TX session from the first non-silent blocks and never re-decide per block; skip silent blocks in the vote entirely.

What I need from you (any log file will do — this is logged at info level)

logTxAudioSummary() (TciServer.cpp:3172-3200) already prints exactly the numbers that discriminate these. It fires on every TX stop.

1. Could you attach the AetherSDR log from a session with a few bad transmissions, or just paste the TCI TX summary reason=stop ... lines? The requested48k= vs inputFramesSrc= vs output24k= fields settle mechanism 1 immediately (they should track each other; a ~2:1 ratio confirms the block-size mismatch).
2. Does the same splatter appear with WSJT-X over TCI instead of JTDX, at the same settings? If WSJT-X is clean, that's mechanism 1.
3. Does it get worse when the AetherSDR window is busy (multiple panadapters, fast waterfall) and better when the window is minimized or the waterfall is slowed? That would point at mechanism 2.

Marking awaiting-response — the analysis and fix plan above stand regardless, but the log line decides which one lands first.

---

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

---

_{📍 Citation health check (Foundry Constitution Principle I): 4 resolved, 8 unresolved against /Users/aetherclaude/workspace/AetherSDR at origin/main.}

Unresolved citations (8)

Citation	Reason
AudioEngine.cpp:8511-8527	file not found in workspace
TciServer.cpp:1119-1123	file not found in workspace
TciServer.cpp:1119-1128	file not found in workspace
TciServer.cpp:2225	file not found in workspace
TciServer.cpp:2225-2255	file not found in workspace
TciServer.cpp:3172-3200	file not found in workspace
TciServer.cpp:441	file not found in workspace
TciServer.cpp:441-444	file not found in workspace

[kn7k]

support-bundle-20260821-094759.zip

[kn7k]

I need more time to test it with WSJT and when AetherSDR window is busy (multiple panadapters, fast waterfall).

[aethersdr-agent]

Thanks Sergey — the bundle settles it. Handing to a maintainer.

What the bundle shows

The TCI TX summary I asked for isn't in there: logTxAudioSummary() logs under aether.cat, and your enabled-categories.txt has aether.cat: disabled. So no TCI diagnostics were captured (that's a separate gap, below). But aether.perf was enabled, and it gives a better answer than the TX summary would have.

uiLagMaxMs (src/core/PerfTelemetry.cpp:438-455) measures how far the GUI event loop overran its heartbeat. Across your ~36 h of 1-second perf windows:

GUI stall	count	note
> 25 ms	90,541 / 129,838 windows (70%)	≥1 missed TX_CHRONO tick
> 50 ms	16,893 (13%)	≥2 missed ticks
> 100 ms	36
max	1,675 ms

PerfStall kind=uiHeartbeat fires 18,868 times in aethersdr-2.log — during your active operating hours that's ~1,600/hour, one every ~2.2 s (median 53 ms, p99 80 ms). A 12.64 s FT8 transmission statistically contains ~5 of them.

Why that lands on the air as splatter

TciServer is constructed with no thread of its own — m_session->setTciServer(new TciServer(&m_radioModel, nullptr)) (src/gui/MainWindow_Session.cpp:2081). Unlike AudioEngine, which gets moveToThread(m_audioThread) (src/gui/MainWindow.cpp:1238), the TCI websocket ingest and the TX_CHRONO pacer run on the GUI event loop. So a waterfall/panadapter repaint stall is a TX-audio timing stall.

The pacer's catch-up is unbounded (src/core/TciServer.cpp:437-444):

m_txChronoAccumNs += m_txChronoClock.nsecsElapsed();
m_txChronoClock.restart();
while (m_txChronoAccumNs >= kTxChronoPeriodNs) {   // 21.333 ms per frame
    sendTxChronoFrame(client);
    m_txChronoAccumNs -= kTxChronoPeriodNs;
}

A 53 ms stall (your median) emits 3 chrono frames back-to-back; the 1,675 ms outlier emits 78. JTDX answers each with a TX_AUDIO block — and a client asked for more audio than it has ready returns a short or zero-padded block. Those blocks go straight through onBinaryMessage() (TciServer.cpp:2150-2329) to feedDaxTxAudio(), and feedDaxTxAudioInternal() (src/core/AudioEngine.cpp:8899-9080) packetizes and emits dax_tx VITA-49 with no wall-clock pacing at all. The Opus TX path already solved exactly this for itself — OpusTxPacer with kMaxPacketsPerDrain = 3 / kMaxQueuePackets = 20 on a 10 ms PreciseTimer (src/core/OpusTxPacer.h:20-21, AudioEngine.cpp:1875-1888). The DAX/TCI route has no equivalent.

FT8 is a constant-envelope continuous tone, so every one of those bursts is a phase/timebase discontinuity → wideband splatter for its duration. "Sometimes clean, most of the time not" is exactly the shape of a per-transmission dice roll against a stall that happens every ~2 s.

Secondary, same file: the mono-vs-stereo layout is re-decided per block from content (TciServer.cpp:2229-2240) — ≥90% of the first 128 float pairs with L≈R ⇒ treat as duplicated stereo. No hysteresis, no session latch. An all-zero block (TX lead-in, or a zero-padded block produced by the burst above) trivially passes that test, and a flip changes that block's timebase by 2×. This turns one burst event into a bigger discontinuity.

Not a factor (ruled out from the bundle): your client TX DSP chain is on (ClientCompTxEnabled True, ClientEqTxEnabled True, tube/limiter), but feedDaxTxAudioInternal explicitly bypasses it for TCI/DAX (AudioEngine.cpp:8919-8923). Radio-side and gain-path are clean.

Suggested change

1. MainWindow_Session.cpp:2081 — give TciServer its own thread, as AudioEngine has. This is the root fix: it takes the TX pacer off the repaint thread.
2. TciServer.cpp:437-444 — clamp catch-up to 1–2 frames per tick and cap m_txChronoAccumNs at a bounded backlog, instead of replaying the whole stall.
3. AudioEngine.cpp:9046+ — pace dax_tx emission the way OpusTxPacer paces Opus (bounded drain + queue cap), so a burst that does get through is smoothed rather than dumped.
4. TciServer.cpp:2229-2240 — latch the mono/stereo decision for the TX session from the first non-silent block; skip silent blocks in the vote.
5. Diagnostics gap: logTxAudioSummary() (TciServer.cpp:3172-3200) is the designated TCI TX support diagnostic but lives in aether.cat, which was off here — a support bundle from a TCI problem contains nothing about TCI. It belongs in (or mirrored to) aether.audio.summary, the category LogManager.cpp:65 describes as "Default support log summaries".

Workaround to try meanwhile

Since the trigger is GUI-thread load: you're running a 2-pane panadapter layout (PanadapterLayout 2h) at ~42 fps waterfall. Reducing to one panadapter, slowing the waterfall rate, or minimizing AetherSDR during TX should measurably reduce the events. If that visibly cleans up your transmissions, it confirms the diagnosis from your side too — but it's a workaround, not the fix.

Environment for the record: AetherSDR 26.8.3 (build Aug 16 2026, Qt 6.8.3), Windows 11 25H2, FLEX-8600 firmware 8600-4.1.5, JTDX over TCI on port 50001, AutoStartTCI True / AutoStartDAX False.

---

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

---

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

[kn7k]

Here is 1 cached with WSJT

[aethersdr-agent]

Thanks Sergey — the bundle changed the picture. Handing this to a maintainer.

Environment (from the bundle)

FLEX-8600, fw 4.1.5.39794 · AetherSDR 26.8.3 (Qt 6.8.3) · Win11 25H2 · JTDX over TCI (port 50001, TciTxGain 0.75) · slice 0 = 18.100 ANT1, slice 1 = 21.074 ANT2 · rfpower=37 · external PGXL amplifier in line (amplifier 0x594EF511 state=TRANSMIT_A, interlock reason=AMP:TG) · ATU TUNE_MANUAL_BYPASS. 18 transmissions logged across 09:27–09:47.

Primary finding: the radio's adaptive predistortion fails sanity on every sample of every transmission

The log window covers 55 APD sample events and 55 apd insanity reports — a 1:1 rate. Interleaved with keying:

09:28:30.039  xmit 1
09:28:33.368  apd sample_index=732   →  insanity "PA gain characteristic is nonmonotonic", ...
09:28:36.617  apd sample_index=733   →  insanity ...
09:28:39.882  apd sample_index=734   →  insanity ...
09:28:43.088  apd sample_index=735   →  insanity ...
09:28:43.711  xmit 0

That is 3–4 APD adaptation events per 13.6 s FT8 transmission, first at ~3.3 s after key-up, then every ~3.2–3.5 s — which is the same count and cadence as the discrete broadband jumps in your screenshot. equalizer_active=0 on every apd slice= status in the whole log, so the predistorter never converges; it re-samples, rejects its own PA model, and repeats. Recurring reasons: PA gain characteristic is nonmonotonic, Excessive uncorrected frequency error, Poor envelope amplitude distribution statistics, Excessive PA gain interpolation, and intermittently SMEAR/SMOOTH factor too high, EQ gain too high or too low.

This is radio/PGXL-side behaviour, not the TCI audio path — but it fits the symptom exactly, including "sometimes the TX is clean."

Decisive test, one toggle: turn APD off on the 8600 and run a few FT8 cycles. If the jumps stop, this is confirmed and the remaining work is on our side is visibility (below) plus an APD/drive-level conversation.

AetherSDR-side defects this exposed

1. apd insanity is silently discarded. apd insanity "reason", "reason" has no = anywhere, so the whole body lands in object; RadioModel.cpp:9671-9679 matches object.startsWith("apd ") and splits the trailing tokens into bare-flag keys, then FlexBackend::decodeApdStatus() (FlexBackend.cpp:995-1005) reads only enable / configurable / equalizer_active / equalizer_reset. The quoted reason list becomes junk keys and the transmitChanged emit is a no-op. No log line, no UI. The radio is telling us in plain English why the transmission is dirty and we throw it away. Suggested: parse the reason list, log at warning under aether.transmit, and surface a badge in the TX/AMP applet when apdEnabled && !apdEqualizerActive.

2. Three of eighteen transmissions abort ~0.5 s after key-up. 09:28:00.103 ON → 00.509 OFF, 09:31:00.113 → 00.660, 09:36:30.104 → 30.549. In each case the radio confirms state=TRANSMITTING first and then AetherSDR sends xmit 0 (RadioModel::sendCommand: "xmit 0"). At 09:28 it re-keys 2.85 s later mid-slot and runs to the normal slot end — a keyed-tone break mid-transmission, independent of the APD story. Whether this is JTDX sending trx:0,false or one of our own abort paths (TciServer.cpp:2133 confirmation timeout, :1950 release race, :749 disconnect) is not determinable from this bundle — see 3.

3. The TCI TX diagnostics are off by default. lcCat is registered at QtWarningMsg (LogManager.cpp:26), so logTxAudioSummary()'s qCInfo (TciServer.cpp:3172) — the requested48k / inputFramesSrc / output24k triple that would settle my earlier three hypotheses — is absent from this bundle, along with every other TCI line (0 aether.cat records in 156 MB of log). A support bundle filed against TCI should force that category on, or the TX summary should move to aether.audio.summary, which is default-on.

Status of the earlier TCI-pipeline analysis

Unchanged and unverified — the bundle neither confirms nor refutes it, because of 3. The three candidates stand as latent bugs regardless: false audio_stream_samples: ack (TciServer.cpp:1119), unbounded chrono catch-up burst (:441), and per-block content-based mono/stereo re-decision (:2225). They are no longer my leading explanation for this report.

Suggested maintainer split

• Now: parse + surface apd insanity (small, clearly correct, and it makes this class of report self-diagnosing).
• Now: default-on or force-on TCI logging for support bundles.
• Needs a log with aether.cat enabled: the 0.5 s TX aborts, and the three TCI-pipeline candidates.

---

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

---

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