feat: raw serial-over-TCP passthrough mode (exclusive-lease), so LAN clients like SPE Expert Controller can share the Pi's existing serial link

[w9fyi]

Summary

Feature request: a raw serial-over-TCP passthrough mode in expert-amp-server, so a native vendor/third-party client — specifically SPE Expert Controller for macOS, which supports connecting over TCP/IP to a "network/serial adapter" — can talk to the amp over the LAN through the Pi that's already running expert-amp-server, without needing a second physical connection or a separate device like the SPE-LAN-UNIT.

Motivation

My station setup has expert-amp-server on a Pi wired to the amp. Direct USB is my preferred physical transport (see PR #34's A/B thread — it's the reliable one; the SPE-LAN-UNIT introduces the 0x90 STATUS bug we already isolated there). The only reason I've used the LAN-unit at all is that it gets me a LAN-reachable connection to the amp, which matters because:

1. My USB-serial run to the Pi has shown RF susceptibility during TX (mentioned in my last comment on feat: promote Expert 2K-FA Third Series fan profile #34) — a LAN hop at the amp side avoids that.
2. I sometimes want to drive the amp from a proper native macOS client with real accessibility support (I'm a blind ham) instead of expert-amp-server's browser UI. SPE Expert Controller advertises full VoiceOver support (descriptive labels/hints, a spoken "Announce" status report) and connects over USB, RS-232, or TCP/IP.

Right now those two things are in tension: expert-amp-server's own API (:8088, HTTP/WebSocket) doesn't speak the amp's native serial protocol, so SPE Expert Controller can't point at it. The only way to get Expert Controller onto the LAN today is the SPE-LAN-UNIT's own TCP 7388 virtual-COM — which reintroduces the 0x90 bug and is a second piece of hardware in the chain.

Proposed feature

A raw TCP listener in expert-amp-server that exposes the amp's actual serial link over the LAN — effectively hosting the same kind of "virtual COM over TCP" the SPE-LAN-UNIT provides, but from the Pi against whatever physical transport expert-amp-server is already using (USB in my case).

The one thing this has to get right: the amp only tolerates one serial master at a time. We proved this directly on the LAN-unit's own TCP 7388 port — a second raw client connected concurrently with expert-amp-server's own bridge desynced/corrupted expert-amp-server's decoder (documented in my SPE-LAN-UNIT notes, happy to write up the repro if useful). A naive "always-on TCP relay running alongside the normal polling loop" would hit the exact same failure mode internally.

So I'd suggest an exclusive-lease passthrough, not true simultaneous multiplexing:

• While no raw client is connected, expert-amp-server behaves exactly as it does today (its own polling/API, normal decoding).
• The moment a client connects to the new raw TCP port, expert-amp-server pauses its own polling/writes for the duration of that connection and just pipes bytes bidirectionally between the socket and the physical serial port — a dumb pipe, safe specifically because only one side is ever actually talking to the amp at a time.
• On disconnect, internal polling resumes automatically.

This sidesteps building a real command-origin-tracking multiplexer (which would be a much bigger change) and matches what I actually need in practice — I'd never want the browser UI and Expert Controller both actively driving the amp at once anyway, I just want to choose which one, from the LAN, without swapping cables or SSHing in to stop/start services.

Why this over just running ser2net/socat alongside expert-amp-server

Same single-master problem applies to any external tool run concurrently against the same device node — it'd need expert-amp-server to fully release the port first anyway. Building the lease logic into expert-amp-server itself means it can coordinate that hand-off cleanly (stop polling, flush, hand over; resume cleanly on disconnect) rather than requiring me to manually stop/start systemctl units every time I want to switch clients.

Happy to test against real hardware once there's something to try, the same way I did for #32/#34/#36/#21 — I have both a direct-USB and an SPE-LAN-UNIT setup on hand to compare against.

73,
Justin — AI5OS

[w9fyi]

Implemented the exclusive-lease design and tested it on a real 2K-FA — including one limitation I want your read on

I built the passthrough described above and ran it against the amplifier. It works end to end with SPE Expert Controller over the LAN. But live TX testing turned up a real gap in my own design, and I'd rather put that in front of you now than after a review cycle.

Nothing is pushed. This is a working branch on my machine, offered for discussion first.

What it does

An exclusive lease, not a multiplexer. It reuses the steal-and-restore handshake SendWake already uses: retireCurrentSession closes the live port and waits on that session's portDone before handing over, and release signals an immediate reconnect. Bytes are forwarded verbatim in both directions. A second concurrent client is rejected and closed, and a session refuses to start while an automatic transaction already owns the actuator.

Two concurrency decisions worth flagging, since they're the parts most likely to bite:

A passthrough session is unbounded, so unlike SendWake it releases writeMu as soon as the steal completes and holds only lifecycleMu for the duration. Server writes are refused through a flag read and written only under writeMu, checked before lifecycleMu is touched. My first version held lifecycleMu naively, and that's a trap: SendWake takes writeMu → lifecycleMu while gatedWakeTransport holds coordinator.mu across the whole call, so a single POST /api/v1/actions/wake would have held both locks and wedged every actuation path — manual, fan, menu-debug, and overtemperature safety — until the external client disconnected. sync.Mutex.Lock() isn't context-aware, so request timeouts don't rescue it. There's a regression test that fails rather than hangs if that ordering ever regresses.

It also takes an ActuationCoordinator lease under a new ActuationOwnerRawPassthrough, so button and wake callers get the usual 409 before they reach the serial layer. Worth knowing: Acquire() is re-entrant for the same owner name, so a second passthrough connection also passed it and its Release() then cleared the first session's ownership. I serialize session setup now, but that re-entrancy may be worth a look on its own.

Overtemperature protection: tap-and-drop

I didn't want the feature to mean "protection is off while a client is connected," so the amp→client direction is decoded while being forwarded unmodified. A client that polls 0x90 keeps the server supplied with genuine provenance: "status-poll" telemetry at no extra cost on the wire.

Tapped frames are deliberately never handed to monitoring.Controller.Observe. It latches before attempting its toggle — the no-retry guarantee — so a tapped frame would spend its single attempt on a port it cannot reach. Instead the tap can only ever end the session: on reaching the trip threshold it closes the TCP connection, the server reclaims the port, and your normal authorized path acts on the next status reply with every existing gate satisfied. No byte injection, no gate weakened.

The trip is also conditional. applyStatusFrameFromSession is the sole caller of safetyController.Observe, so with status polling disabled the server could never act after reclaiming — tripping there would take away the operator's live control link and put nothing in its place. So it checks whether status polling is actually active first, and reports the gap instead of tripping. Display-derived trips additionally require a valid LCD checksum, since the display decoder only validates frame boundaries and this stream also carries replies to whatever the client sent.

Hardware verification

EXPERT 2K-FA, firmware Rel.08_06_26_A, direct USB (FTDI AB0PKCHL), 57600.

check	result
0x90 sent through the socket	real 76-byte reply: ,20K,S,R,x,2,03,2a,0r,M,0000, 0.00, 0.00, 0.0, 0.0, 88, 88, 86,N,N
Expert Controller connected	tap observed 488 status + 487 display frames (~2/s and ~1.5/s) — the app polls both
POST /actions/wake, /actions/button while leased	409 in 0.00 s, zero bytes to the amplifier
second concurrent client	closed immediately
disconnect	port reclaimed, polling resumed, provenance: status-poll

On a pty rig with a simulated amplifier I also confirmed zero server bytes reach the port across three consecutive leases, and that bytes are forwarded verbatim in both directions.

For the thermal trip I temporarily lowered the threshold to 25 °C with the amplifier in STANDBY at 31.1 °C. The session dropped, the server reclaimed the port, and the monitor read state: trip with latched: false, action: idle — it saw the condition and correctly declined to actuate, because the amplifier wasn't in OPERATE, and critically it did not burn the latch. To be precise about what's proven where: the actuation half (the reclaimed server actually sending 55 55 55 01 0D 0D) I've only confirmed on a pty rig with a simulated amplifier in OPERATE, not on the real amplifier hot and transmitting.

The limitation, and my question

SPE Expert Controller stops polling 0x90 while transmitting. So the tap goes blind, and overtemperature protection is inert during exactly the period the amplifier heats.

Same amplifier, same session, A/B:

during TX	with passthrough	server polling directly
status freshness	went stale, recentContact: false	0.8–1.1 s, mean 0.9 s
TX samples with no contact	42	0 of 40
PA current	frozen at 2.7 A (stale)	live, 1.1 → 16.3 A on voice peaks
decode errors / reconnects	0	0 / unchanged

The amplifier answers 0x90 perfectly well while transmitting — the client just stops asking. The frozen 2.7 A reading is the tell: it was the last value before the client went quiet, not a measurement. Real current was hitting 16 A.

Worth noting separately, since it's relevant to your ferrite advice on #34: this same test showed no RF ingress on the USB link through 40 s of transmit at the levels measured (35.1 V PA supply, peaks to 16.3 A) — zero decode errors, zero reconnects, uninterrupted 1-second-fresh telemetry. That susceptibility was my original reason for putting a LAN unit in the path, and it didn't reproduce here. I haven't swept every band and antenna combination, so I'm reporting the run, not declaring the problem solved.

So passthrough trades away overtemperature protection for the duration of each transmission. Low risk for SSB overs; materially worse for FT8 or RTTY duty cycles, where transmissions repeat and heat actually accumulates. The status endpoint reports the gap honestly, but honest-and-absent is still absent.

I can see two directions and I don't want to pick one unilaterally in a safety path:

1. Document it and rely on the firmware's own stepdown (75-77 °C) during transmit. No new risk, gap stays.
2. Have the server inject its own 0x90 when the tap goes quiet, swallowing the reply so the client never sees it. Keeps protection alive — but it puts a second writer on a link the amplifier expects one master on, which is exactly the class of change you've been careful about, and I'd want your call before building it.

Or something you'd prefer that I'm not seeing.

One upside worth mentioning: because the client's own 0x90 polling feeds the tap, the dashboard and HTTP API keep live protocol-native telemetry throughout a passthrough session. That's better than the SPE-LAN-UNIT path, where the server is blind.

Happy to open a PR if you want to look at the code, or to run whatever additional tests would help you decide on the TX question. Also happy to leave it here if you'd rather not take the feature at all — the finding stands either way.

73,
Justin — AI5OS

[FtlC-ian]

Justin, this is useful, and thank you again for doing the real 2K-FA testing before presenting it as finished.

We would like to keep the first version deliberately smaller than a protocol multiplexer. Would this shape still meet your Expert Controller use case?

• One exclusive raw TCP client. A second client is rejected without disturbing the active session.
• While leased, Expert Amp Server sends zero bytes of its own: no polls, buttons, wake sequence, fan navigation, menu debug, or injected 0x90 requests.
• Bytes remain unmodified in both directions, but the amplifier-to-client stream is passively copied into the existing status/display decoders. That lets the web UI and API keep tracking the amp whenever the external client supplies enough traffic.
• State obtained that way is identified as passthrough/tapped evidence and becomes honestly stale when the client stops polling. It is never treated as a complete or current safety input when it is not.
• No response swallowing or command-origin correlation. If we ever need those, that is a different, substantially larger proxy design.
• On disconnect, the raw session closes, all stream decoders/session evidence reset, and the normal server reader reclaims the port and resumes polling.

For the initial implementation, server-originated automatic actuation would be unavailable during the raw lease. We should either reject a passthrough session while overtemperature standby or automatic fan control is armed, or require those controls to be explicitly suspended and report that state clearly. We do not want a partly functioning safety path that appears stronger than it is. Your passive tap is still valuable for UI/API visibility, but we agree that injecting private 0x90 polls into another client's raw session is the wrong direction.

The TX result is also a little less alarming in one narrow respect: Expert Amp Server's existing overtemperature controller intentionally never sends the standby toggle during TX. The important questions are whether Expert Controller resumes status polling promptly in RX and whether tapped state is clearly marked stale while it does not. Your finding is still important, especially for long transmissions and dashboard visibility.

We are fixing #44 first because it changes the wake/coordinator lock boundary that this feature would build on. After that, implementation is flexible. If you want to open your current work as a draft PR rebased onto the fix, we would be glad to review it and help reshape it. If you would rather share the tests and hardware findings while we build the implementation, that is equally welcome. You have helped this project a lot, and we are happy to do the coding rather than turn this into homework for you.

There is also a useful future connection to the inexpensive ESP32 serial bridge we have been discussing. This passthrough exports a local serial link to a TCP client; the bridge requires the reverse direction, with Expert Amp Server dialing a remote TCP serial link. They are not the same feature, but a clean transport-neutral byte-stream boundary here could support both without duplicating lifecycle code.

[w9fyi]

Ian, this shape works for my use case, and I'd rather have the smaller version. Agreed on all of it: one exclusive client, zero server-originated bytes while leased, verbatim forwarding, passive tap for visibility only, no response swallowing, no command-origin correlation. And thank you for settling the TX question — I didn't want to make that call on my own judgement, and I'm glad not to be building the injection path at all.

Your point about the overtemperature controller never sending the standby toggle during TX is well taken, and I should have checked it before framing the gap the way I did.

Two things below where I need your decision rather than my preference, and one measurement I'm running for you.

Marking tapped state — you're right, and there's one knock-on I need you to rule on

Not cosmetic, and worse than I labelled it. Live on my Pi right now: a passthrough session up ten and a half hours, 62,714 tapped status frames, server has sent zero bytes of its own the whole time. GET /api/v1/status still reports:

provenance: "status-poll"    recentContact: true

Indistinguishable from a server poll, because protocol.StatusFromFrameWithTemperatureUnit hardcodes Provenance: "status-poll" (internal/protocol/status.go:159) and my tap passes the result straight to statusState.UpdateProtocolNative. Nothing downstream can tell. That's precisely the "appears stronger than it is" failure you're guarding against, and it's mine.

The encouraging part is that your requirement is already expressible in the codebase's own terms. provenance != "status-poll" is this project's existing "not authoritative" test — monitoring/controller.go:90, fanpolicy/policy.go:146 and :216, and runtime/status_state.go:115. Giving tapped frames a provenance of their own makes the safety controller and the fan policy refuse them at guards that already exist and are already tested, rather than at a new one I'd write and you'd have to take on trust.

The knock-on, which is yours to rule on. That fourth site is the catch. StatusState.Resolve uses the same string to decide whether to merge protocol-native fields into the API status at all — so a straight relabel doesn't only stop the safety path trusting tapped data, it stops the API and web UI seeing it, which is the visibility you asked to keep.

The one string is currently doing two jobs: "fresh enough to display" and "authoritative enough to act on." Passthrough seems to be the first caller that needs them apart. Two ways I can go:

1. Split them — Resolve merges clearly-labelled tapped state for display, monitoring and fanpolicy stay on the strict == "status-poll" test. Keeps the UI visibility, but touches a gate the safety controller depends on.
2. Don't split — tapped state simply doesn't surface in the API for the first version. Smaller and safer, at the cost of the visibility.

I lean toward the first but I don't think that's my call to make on a safety gate, and the second is a perfectly good v1. Tell me which and I'll build it.

Automatic actuation during a lease — I'll build it your way

I'll implement what you described: no server-originated automatic actuation while the lease is held, with the session either refused while overtemperature standby or automatic fan control is armed, or those explicitly suspended and reported. Between those two, I'd build the explicit-suspend variant unless you say otherwise, since it makes disarming a deliberate, visible act — but refusal is simpler and I'll do that if you prefer it.

Two pieces of information for you to price in, offered as input rather than argument.

What the branch currently does, so you know what's being replaced. Tap-and-drop never actuates during the lease; on reaching the threshold it ends the session, the server reclaims the port, and your existing authorized path acts on the next status reply with every gate satisfied. I verified the yield on the amplifier: trip lowered to 25 °C, amp in standby at 31.1 °C — session dropped, port reclaimed, monitor read state: trip with latched: false, action: idle, correctly declining because the amp wasn't in OPERATE, and importantly without burning the latch. If you see that as still falling on the wrong side of your line, I'm happy to take it out; you've thought about this safety path far longer than I have.

One practical consequence worth knowing. My Pi runs overtemperatureStandbyArmed: true and rawPassthroughEnabled: true together. Under a refuse-while-armed rule, every session is refused until I disarm overtemperature standby — so in practice I'd end up running Expert Controller with protection off rather than on. That may still be the right trade for a v1, and it's visible and honest, which is your main criterion. I only want to be sure it's a consequence you've chosen rather than one I sprang on you later.

Relatedly, and this one cuts in your favour: I left that session open for ten hours unattended while I was away from the shack. Nothing came of it — the amp was in standby and the client polled throughout — but a long unattended lease is exactly the case where your concern has the most force, and I'd rather say so than not.

Resume-after-TX

I've instrumented your first question so I can give you numbers instead of impressions. The tap counters in /api/v1/raw-passthrough are sufficient on their own: sampling statusFramesObserved and displayFramesObserved at 20 Hz dates frame arrivals to within 50 ms, with no change to the deployed server and no bytes added to the link. Transmissions are driven by spoken cues on the same clock, so resume lag is measured from unkey rather than inferred, across short (5 s) and long (40 s) transmissions so a fixed startup cost can be told apart from one that grows with transmission length.

That work already corrects something I told you. Over a 10.01-hour session the tap counted 60,059 status and 60,058 display frames — mean interval 0.6001 s on both channels, 1.667 Hz each, the two counters one frame apart across sixty thousand. Expert Controller interleaves one status and one display poll per cycle, in lockstep. Not the "~2/s and ~1.5/s" I estimated from frame totals last time. A counter delta over ten hours has no sampling bias in it, so that figure is solid.

The same session doubles as an unintended soak of the lease: continuous forwarding, no reconnects, no drops, no measurable cadence gaps, server RSS flat at 16.9 MB after 26 hours uptime.

I'll post the resume figures, including whether both channels stall together or only status.

Sequencing, and how you'd like to take the work

Agreed on #44 first, and it makes sense to me why — it moves the exact boundary this sits on. The branch's central decision is that a passthrough session releases writeMu and holds only lifecycleMu, with a refusal flag checked before lifecycleMu is touched, plus a regression test that fails rather than hangs if the ordering regresses. All of that wants rebasing onto your fix rather than working around it.

On how to proceed, I genuinely don't mind, so please pick whichever is less work for you:

• I rebase onto your ABBA deadlock: wake API vs serial readLoop wedges all actuation including overtemperature safety (reproduces on main) #44 fix and open it as a draft PR for you to reshape or rewrite as you see fit.
• I hand over the tests and hardware findings and you build it, which given the design changes above may well be cleaner than reshaping mine.

Your offer to do the coding is appreciated and I'm not trying to talk you out of it — you know the invariants here better than I do, and if starting fresh gives you a result you're more confident in, that's the better outcome.

One thing worth a look independently of this feature, in case it affects the #44 work: ActuationCoordinator.Acquire() is re-entrant by owner name, so a second passthrough connection also passed the lease and its Release() then cleared the first session's ownership. I serialize session setup on my branch, but the re-entrancy is upstream behaviour and may matter elsewhere.

And yes — the ESP32 bridge being the reverse direction is a good framing. If the byte-stream boundary ends up transport-neutral rather than socket-specific, dialling out should be able to reuse the same lifecycle. I'll keep it in mind without building for it.

73,
Justin — AI5OS

[FtlC-ian]

Justin, thank you for spelling out the knock-on effects. Here are our decisions and the tradeoffs behind them.

Tapped telemetry

We want option 1: split "displayable" evidence from "authoritative for actuation."

Frames passively observed during a raw lease should be exposed to the API and UI with a distinct provenance such as passthrough-tap. StatusState.Resolve may merge that state for display, but monitoring and fan policy must continue requiring direct server-polled evidence. Tapped state must never authorize fan navigation, overtemperature standby, or any other server actuation, and it must become stale normally when the external client stops polling.

The benefit is that the dashboard remains useful during passthrough without overstating what the server knows. The cost is separating two meanings currently carried by the status-poll string: fresh enough to display and authoritative enough to act upon. That touches an important boundary, so it needs explicit tests proving that passthrough-tap is visible through the API while being rejected by every actuation path.

Option 2, omitting tapped state from the API entirely, would be smaller but would discard useful, correctly labeled telemetry. We do not think that loss is necessary if the display/actuation boundary is made explicit and tested.

Automatic controls during a raw lease

For the first version, refuse passthrough while either automatic fan control or overtemperature standby is armed. Return a clear 409 identifying exactly which control must be disarmed. Do not silently suspend settings, automatically restore them later, or make passthrough appear active while a configured protection is unavailable.

Automatic suspension would be more convenient, but it creates another state machine: which settings were suspended, whether they are represented accurately in the API, and how they are restored after disconnects, crashes, or failed port reclamation. Refusal is less convenient, and it means the operator who chooses passthrough must knowingly run without those server-side automatic controls, but the resulting state is simple and honest.

Please remove the tap-and-drop behavior from the eventual implementation. It avoids writing during the lease, but it still gives tapped evidence a safety role, can unexpectedly terminate the external client's session, and depends on traffic that we now know stops during TX. Reclaiming the port and waiting for a subsequent direct poll also makes the timing and guarantee harder to explain than a clean refusal rule.

We also continue to reject injected 0x90 polling. That would preserve fresher telemetry, but it breaks the exclusive single-master model and requires command/reply correlation plus response swallowing. At that point this is a protocol proxy or multiplexer, not a raw byte-stream lease.

Sequencing

Your owner-name lease finding is valid. We should fix #44 using lease-instance identity so one same-named acquisition cannot release another acquisition's ownership. Passthrough remains deferred until after v0.4.8, so please keep the branch and tests, but do not spend time rebasing it yet. The soak results and resume-after-TX measurements are still valuable evidence for the later implementation.

The intended v1 invariant is therefore straightforward: one exclusive client, zero server-originated bytes while leased, verbatim forwarding, passively tapped and clearly labeled display telemetry, and no server automatic actuation during the lease.

[w9fyi]

Correcting my TX finding: the blind spot does not reproduce

Ian, I owe you a correction before anything else. I measured the resume-after-TX
question you asked, and in doing so found that the premise I gave you was wrong.

SPE Expert Amp Controller Plus does not stop polling 0x90 while transmitting
a carrier. Not in STANDBY, not in OPERATE, not across a 145-second continuous
key-down. The tap never goes blind, so there is no gap to resume from and no
resume lag to report.

I say "a carrier" deliberately. My original report was made on SSB voice and I
have not re-tested that mode; the section below sets out why that difference may
be the whole story, and how it cuts.

That matters to you specifically because I gave you the blind spot as a fact and
you reasoned from it. Your conclusion on injected 0x90 still stands on its own
argument — it breaks the exclusive single-master model and needs command/reply
correlation, which makes it a proxy rather than a lease — but one of the
supporting facts underneath it was mine and it was wrong.

The measurement

Five transmissions, 5 / 40 / 5 / 40 / 15 seconds, with 20–25 s receive windows
between, amp in OPERATE and genuinely amplifying at 23.4–23.8 A PA current.

transmission	status frames during TX	display frames during TX	verdict
short-1 (5 s)	9	8	did not stall
long-1 (40 s)	66	67	did not stall
short-2 (5 s)	8	8	did not stall
long-2 (40 s)	67	66	did not stall
medium-1 (15 s)	25	25	did not stall

Frame intervals during transmit: median 0.60 s, min 0.50 s, max 0.65 s — the
same cadence as the quiet-receive baseline before any transmission (median
0.60 s, n=52). The amplifier confirmed it was actually transmitting throughout:
tx=true in 197 of 200 status samples during long-1 and 199 of 200 during
long-2. 5,611 counter samples and 1,403 status samples, zero sampling errors.

This also answers your other question — whether both channels stall together or
only status. Neither stalls. They stay in lockstep, interleaved one frame apart,
exactly as the ten-hour soak showed.

Corroboration, including one run I did not intend

Three independent observations agree:

• A 30-second carrier with the amp in STANDBY: continuous frames, no gap longer
  than 1.5 s anywhere in a 40-second window.
• Short carriers (2 s, 3 s, 5 s, 6 s) in both amplifier states.
• A 145-second continuous carrier in OPERATE at 23.4–23.8 A, during which
  the tap counters climbed the entire time at 1.669 Hz — indistinguishable from
  baseline.

I should be straight about that last one: it was not planned. My test rig keys
the radio over the SmartSDR API, and a bug in my unkey path left the carrier up
after the script died. The amplifier reached 104 °F against a 149 °F trip, so
nothing was harmed, and the fix is in — but the run happened by accident and I
would rather say so than present it as designed. It is, as it happens, the most
conclusive evidence in the set.

What I cannot explain, and where I would not draw a conclusion

The A/B I reported on 2026-08-29 showed the opposite: stale status through
transmit, recentContact: false for 42 samples, PA current frozen at 2.7 A.
I cannot reconcile that with these measurements, and I do not want to invent a
reason.

It is the same application in both cases, so that is not the difference. One
uncontrolled variable remains and I can name it precisely: the earlier run was
SSB voice, everything above is a steady tune carrier. If the client suspends
0x90 polling only while it has voice audio flowing — or only in a
voice-configured transmit path — then both observations are true and the blind
spot is real but mode-specific.

That would matter to you in a specific way. A voice-only blind spot is the
benign version: SSB overs are short and the amplifier has time to shed heat
between them. The case you were actually worried about, FT8 and RTTY duty
cycles, is carrier-like, and carrier-like transmission is precisely what these
measurements show polling straight through.

I have not tested voice, so that is a hypothesis, not a finding. I can run the
same instrumented sequence on SSB with the mic open and settle it, and I am
happy to do that before you act on any of this. Until then the honest position
is that the earlier observation is unexplained rather than refuted.

What this changes for the design you set out

Less than it might appear, and mostly in your favour:

• Tapped telemetry stays worth having. With the client polling straight
  through transmit, passthrough-tap state remains fresh during exactly the
  period I had claimed it went dark. Your decision to expose it to the API and
  UI with a distinct provenance looks better, not worse.
• Staleness handling is still required. A client that polls continuously
  today may not tomorrow, and the guarantee should not depend on the client's
  goodwill. Marking tapped state and letting it go stale normally is the right
  invariant regardless of what any particular client does.
• Nothing here argues for injection. If anything it removes the last reason
  anyone might have wanted it.

Method, in case you want to reproduce or pick holes

Read-only against the deployed server: the monotonic counters at
GET /api/v1/raw-passthrough sampled at 20 Hz, which dates frame arrivals to
within 50 ms, with GET /api/v1/status sampled alongside at 5 Hz to record the
amplifier's own tx flag. No change to the server and no bytes added to the
serial link.

Transmissions are keyed by the test itself over the SmartSDR API rather than by
a spoken cue and a human hand, which removes reaction time from the
measurement — carriers land within 5 ms of their commanded length, verified
against an independent observer on a separate connection.

Happy to attach the raw JSONL logs and the analysis script if they are useful to
you, or to run any variation you would like to see — different modes, longer
transmissions, or a deliberate attempt to provoke the original behaviour. Given
your sequencing I am not treating any of this as urgent, and the branch is
untouched and unrebased as you asked.

73,
Justin — AI5OS

[FtlC-ian]

v0.4.8 is released and #44 is closed. Current main now uses lease-instance identity: concurrent same-named acquisitions fail, and a stale lease cannot release or write through a newer lease. Please rebase your existing passthrough branch onto current main and open it as a draft PR so we can review the implementation rather than duplicate your tested work.

The v1 contract remains:

• one exclusive passthrough client;
• zero server-originated serial bytes while the lease is held;
• verbatim bidirectional forwarding, with no injected 0x90, response swallowing, or command/reply correlation;
• passive status/display observation only, with status exposed as passthrough-tap for API/UI visibility but rejected as authority by fan policy, overtemperature standby, and every other server actuation path;
• normal staleness when the external client stops polling;
• no tap-and-drop behavior;
• a clear 409 before lease acquisition while automatic fan control or overtemperature standby is armed, identifying each control that must be disarmed;
• no silent suspension or later restoration of automatic settings;
• the new lease-token API and lock ordering from v0.4.8, with deterministic disconnect, duplicate-client, stale-release, and deadlock regression tests.

Your corrected carrier-TX measurements strengthen the usefulness of passive tapped telemetry but do not change these boundaries. The earlier SSB observation can remain unexplained unless it reproduces; it is not a prerequisite for the draft.

Please keep hardware-specific details in the PR verification notes, especially the long soak, exact frame counters, and proof that the server emitted zero bytes of its own while leased.