Reported issues for DAQiFi

Pod holds 8 of 8 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to DAQiFi.

Most discussed

mcp: discover_devices clamps the timeout to a 250 ms floor, but serial identify takes ~830 ms — any short timeout silently returns no devices

DaqifiAgent.DiscoverAsync clamps the caller's timeout with Math.Clamp(timeoutMs, 250, 30_000). On real hardware the serial identify handshake takes ~830 ms, so every value in the lower two thirds of that advertised range — including the floor itself — returns an empty list, silently, and is indistinguishable from "no device is plugged in".

Found by bench-validating Daqifi.Mcp end-to-end against a real Nyquist (fw 3.7.2) over USB CDC, with the server built from origin/main…

Read the thread · 2026-08-06 · closed · outside contributor · 1 comment

CoreDeviceAdapter needs improvements for true drop-in replacement capability

Summary

The current CoreDeviceAdapter (v0.4.1) is not ready for production use as a drop-in replacement for existing MessageProducer/MessageConsumer implementations. During integration testing with a real-world desktop application, we discovered critical functionality gaps that prevent successful migration.

Issues Discovered

1. Message Format Incompatibility

Problem: CoreDeviceAdapter's MessageConsumer provides IInboundMessage<object> events, but existing applications expect…

Read the thread · 2025-08-06 · closed · outside contributor · 1 comment

feat(mcp): a stale Daqifi.Mcp install is silently missing the data path — surface version and staleness

Why

On 2026-09-07 a developer machine here had Daqifi.Mcp 0.28.0 installed while 1.7.0 was published — nine releases of drift, with nothing anywhere signalling it.

That is not cosmetic. 0.28.0 predates #524 ("an agent can read a measurement, not just configure one"), so it exposes 10 tools instead of 25, with no read_channel_values and no capture_samples. An agent driving that install can discover a device, connect, configure channels and start SD logging — but **cannot…

Read the thread · 2026-09-07 · closed · outside contributor · 0 comments

feat(mcp): publish Daqifi.Mcp to the MCP registry — the server exists but cannot be found

Why

Independent developers are hand-building MCP servers for bench instruments, because no instrument vendor ships one:

Read the thread · 2026-09-07 · closed · outside contributor · 0 comments

feat(mcp): live-data tools — an agent can configure everything and measure nothing

Type: Feature (MCP + Core API) Priority: High

What

The MCP server's 15 tools include no way to read a measurement. An agent can discover, connect, configure channels, drive DIO/PWM, set the sample rate, and start SD logging — but can never answer "what is the voltage on AI0?". grep StreamSamplesAsync|SampleReceived|LiveSample src/Daqifi.Mcp/ returns zero hits; the MCP README states it: "Data does not stream back to the agent in this version."

Core already has the entire…

Read the thread · 2026-08-12 · closed · outside contributor · 0 comments

bug(streaming): StreamSamplesAsync never completes on disconnect or dispose — await foreach hangs forever after an unplug

Type: Bug Priority: High

What

StreamSamplesAsync never completes when the device disconnects or is disposed. In src/Daqifi.Core/Device/Internal/LiveSampleStream.cs, the bounded channel's writer is completed only in the enumerator's own finally (:93) — nothing else ever calls TryComplete(). The stream subscribes to neither the drop detection this library worked hard to build (ConnectionStatus.Lost, #377/#382/#394) nor ErrorOccurred (#378), and…

Read the thread · 2026-08-12 · closed · outside contributor · 0 comments

mcp: set_sample_rate's device-cap guard is set-time only — a channel reconfigure leaves an over-cap rate live and reports it as valid

set_sample_rate's device-cap guard is enforced only at set time. A later configure_analog_channels / configure_digital_channels call refreshes the cap but never re-validates the rate that is already live, so widening the channel set leaves StreamingFrequency above the device's cap — and the configure call reports that now-invalid rate back to the agent as if it were fine.

Found by bench-validating Daqifi.Mcp end-to-end against a real Nyquist (fw 3.7.2, hw 2.0.0) over USB CDC. The…

Read the thread · 2026-08-06 · closed · outside contributor · 0 comments

api: an over-max sample rate throws in Core but clamps in the MCP layer — one condition, two contracts

Summary

Asking for a sample rate above the device's maximum produces three different behaviors depending on which layer you go through. Since firmware #524 the device itself rejects freq > current_max_rate_hz with SCPI -222 and does not start streaming — there is no silent clamping on the device side — so the layers above it should agree on how that condition is presented.

This is scope item 8 of #390, split out because #390 is now closed by #404. #404 already fixed part of it…

Read the thread · 2026-07-30 · closed · outside contributor · 0 comments

Most recent

The remaining reports are on the project's issue tracker.