Skip to content

Add device-side FIFO telemetry for DdD captures - #5

Open
JunliangRen wants to merge 1 commit into
harrypm:mainfrom
JunliangRen:ddd-fifo-telemetry
Open

Add device-side FIFO telemetry for DdD captures#5
JunliangRen wants to merge 1 commit into
harrypm:mainfrom
JunliangRen:ddd-fifo-telemetry

Conversation

@JunliangRen

@JunliangRen JunliangRen commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Summary

This adds optional FPGA FIFO telemetry for supported DdD protocol-v1 firmware and presents it as an HW Buffer indicator during capture.

The DdD backend polls the telemetry asynchronously and reports current and peak FIFO occupancy, back-pressure, overflow events, and lost words. Legacy DdD firmware and all other device backends remain unchanged.

Why add device telemetry?

The existing status bar mainly reports what MISRC-GUI can observe after samples have reached the host, such as RF and audio ring-buffer occupancy. Drop, error, and sequence counters can show that a capture fell behind or that the received stream became discontinuous, but they cannot show where the problem first appeared.

For example, the existing counters alone cannot distinguish between:

  • pressure or data loss in the FPGA FIFO before samples enter the host buffers;
  • a USB or host-ingress stall preventing the FPGA FIFO from being drained;
  • pressure later in the host processing or storage pipeline.

The optional firmware telemetry adds the missing device-side view. Comparing HW Buffer with the existing RF Buffer and Audio Buffer values helps narrow the affected stage:

  • FPGA FIFO pressure or overflow while the host buffers remain healthy indicates that the problem occurred before samples entered the application buffers;
  • a healthy FPGA FIFO combined with increasing host-buffer pressure points further downstream in the host pipeline.

This does not identify one exact cable, USB, scheduling, processing, or storage cause by itself, but it helps distinguish device-side pressure from host-side pressure and makes capture problems easier to diagnose.

Support for future devices

The status-bar UI consumes a small device-neutral view consisting of visibility, meter percentage, severity, and a short caption. DdD-specific telemetry parsing, FIFO geometry, counters, and thresholds remain inside the DdD implementation.

Other device backends do not opt in today, so their UI and behaviour are unchanged. In the future, hardware that can expose meaningful device-side telemetry can translate its own native measurements into the same status view without duplicating the status-bar UI or introducing DdD-specific assumptions into unrelated devices.

Not every device is expected to provide identical counters. This is an extension point that allows support to be added incrementally according to the telemetry each device can actually expose.

Screenshot

DdD protocol-v1 FPGA FIFO telemetry in MISRC-GUI

DdD protocol-v1 capture in a healthy state. The green HW Buffer meter shows the device-side FPGA FIFO status alongside the existing host-side RF Buffer and Audio Buffer counters.

Only the normal hardware state is shown here; no overflow or data loss was intentionally induced for the screenshot. Warning and error presentation paths are covered by unit tests.

Validation

  • Windows MinGW64 release build
  • Meson test suite: 4/4 passed
  • Unit coverage for FIFO telemetry parsing and aggregation
  • Unit coverage for asynchronous polling, invalid responses, and unsupported firmware
  • Unit coverage for healthy, back-pressure, overflow, and lost-word status presentation
  • Static and post-build guard checks
  • DdD-disabled syntax build to verify that other build configurations remain unaffected
  • Healthy capture tested with a physical DdD device

@harrypm

harrypm commented Sep 2, 2026

Copy link
Copy Markdown
Owner

So 2 issues.

As with the "legacy" rename this breaks the UI on common use this is why device names should always be short/simple for selection as this breaks scaling/sizing.

(I have been wrangling this to make it more flexible but more added adds extra work)

You are using a high DPI scale but not testing / viewing as 1/2 or 1/4 window sizes like attached below using a 1920x1080 panel.

image image

@JunliangRen

Copy link
Copy Markdown
Contributor Author

So 2 issues.

As with the "legacy" rename this breaks the UI on common use this is why device names should always be short/simple for selection as this breaks scaling/sizing.

(I have been wrangling this to make it more flexible but more added adds extra work)

You are using a high DPI scale but not testing / viewing as 1/2 or 1/4 window sizes like attached below using a 1920x1080 panel.

image image

Okay....Let me think how to adjust this to be better🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants