Spun out of #2524 — reviewer agreed it's a separate concern.

Background

After #2524 lands, the DAX IQ stream registration on Windows / non-PipeWire Linux works correctly: iq_start (TCI) and iqEnableRequested (DaxIqApplet) both create a stream with the radio, the radio confirms the stream, registerIqStream() runs, PanadapterStream::iqDataReady fires at the expected rate, and consumers (TCI clients, DaxIqModel for the level meter) all wake up.

The problem is what's in the data path.

Symptom

End-to-end with #2524 applied, on a Flex 6700:

• TCI IQ binary frames flow as expected (header structure correct, frame count and size match the configured 48 kHz / float32 / stereo)
• A 30-second capture lands an 11.5 MB WAV (matches 48000 × 8 × 30 ≈ 11.5 MB exactly)
• Payload bytes are all zero. Verified via:

  $bytes = [IO.File]::ReadAllBytes($wav)
  ($bytes[44..1067] | Where-Object { $_ -ne 0 }).Count   # → 0

• The GUI's DaxIqApplet level meter is also flat at zero (consistent with feeding zero samples through processIqPacket() — RMS of zero is zero).

What the radio is reporting

The stream-status reply for the created DAX IQ stream:

stream 0x20000000 type=dax_iq daxiq_channel=1 pan=0x40000000 slice=0x0
       endpoint_type=Display
       daxiq_rate=48000
       client_handle=0x1B61E34B
       client_gui_handle=0x1B61E34B
       active=1
       ip=*.*.*.107
       payload_endian=little

Two fields stand out:

• endpoint_type=Display — Flex appears to distinguish between Display-endpoint streams (intended for SmartSDR-style display consumers — panadapter / waterfall) and DAX-endpoint streams (intended for raw IQ consumers via the DAX driver).
• client_gui_handle == client_handle — we are identifying as a GUI client.

Hypothesis: when a GUI client requests a dax_iq stream, the radio defaults to a Display-typed endpoint that mirrors what the panadapter visualisation already gets, and the per-sample IQ slot is left empty for that endpoint flavour. Real raw IQ goes to DAX-typed endpoints, which is what SmartSDR's standalone DAX-IQ utility subscribes to (a separate client process, non-GUI client identity).

What I'd appreciate guidance on

This isn't blocking #2524 — that PR fixes a real registration gap and is worth landing regardless. But the long-term question is: should AE-as-a-single-GUI-client be able to deliver DAX IQ samples to its own consumers (the level meter, TCI clients), and if so, how?

Three architectures I can imagine:

1. API parameter we're missing. Maybe stream create type=dax_iq ... accepts an endpoint_type=DAX (or similar) we should be passing. I couldn't find it in the FlexLib API reference (Radio.cs only sends the daxiq_channel= form), but the FlexLib client is itself part of SmartSDR-the-GUI-client, so it may not be the relevant reference.
2. A second AE-internal radio connection with a non-GUI client identity dedicated to DAX IQ subscription. More invasive but mirrors how SmartSDR-the-suite actually works (one GUI client + the DAX-IQ utility as a separate non-GUI client).
3. Document the limitation. If neither (1) nor (2) is feasible, document that AE-internal DAX IQ on Windows/Linux requires also running SmartSDR + the DAX-IQ utility for actual sample data, and the AE-internal applet is essentially "tells you when DAX IQ is configured but doesn't carry samples".

Do you (Jeremy / @aethersdr-agent) know which of these is right, or is there a fourth option I'm missing?

Reproduction

1. Apply Fix DAX IQ silently broken on Windows / non-PipeWire Linux #2524 (the registration fix)
2. Connect AE to a Flex 6700 (or any DAX-IQ-capable Flex)
3. Either:
   • Toggle channel 1 "On" in the DaxIqApplet, or
   • Send iq_start:0; from a TCI client
4. Observe radio's stream-status reply contains endpoint_type=Display
5. Check the captured/logged IQ payload — all zeros

73, Nigel G0JKN & Claude (AI dev partner)