Summary

The TCI WebSocket server implements VFO, mode, PTT, filter, and audio streaming, but two data flows are absent that are expected by TCI clients:

1. Spectrum / waterfall binary frames — The TCI protocol (ExpertSDR3 v1.5) defines a spectrum_event:on / spectrum_event:off subscription mechanism. Clients send spectrum_event:on; to request live panadapter data as binary frames. AetherSDR does not currently recognise this command or emit any spectrum binary frames, so clients receive no waterfall or frequency-domain data over TCI.

2. Signal meter readings — The rx_smeter broadcast is wired to MeterModel::sLevelChanged, but only fires once the radio delivers a meter update. Clients that connect before the first meter event receive a stale initial value (-130 dBm) with no further update until the radio emits one. There is no periodic flush or initial-state message to give newly connected clients a current reading.

Steps to reproduce

1. Start AetherSDR connected to a compatible radio.
2. Connect a TCI client (any ExpertSDR3-compatible client or a WebSocket tool).
3. Send spectrum_event:on; after the ready; handshake.
4. Observe: no binary spectrum frames are received.
5. Connect a fresh client and observe the rx_smeter value — it reflects -130 until the radio next updates the meter model.

Expected behaviour

• spectrum_event:on; causes the server to start forwarding panadapter spectrum rows to subscribed clients as binary frames (type = SPECTRUM, payload = float32 dBm bins, reserved fields carrying low/high edge Hz).
• Newly connected clients receive a current rx_smeter value promptly, not a stale placeholder.

Environment

• AetherSDR version: 26.5.2.1
• TCI protocol: ExpertSDR3 v1.5