DAQiFi
Discover, configure and read DAQiFi Nyquist data-acquisition hardware from an AI agent
Open source Open in the app JSON README (API)
About
Discover, configure and read DAQiFi Nyquist data-acquisition hardware from an AI agent
Details
- Kind
- MCP servers
- Topic
- No topic detected
- Publisher
- daqifi
- Origin
- official
- Category
- ferramentas
- Transport
- local
- Version
- 1.8.0
- Stars
- 4
- Last push
- 2026-09-08T22:56:47Z
- Repository state
- ativo
- Language
- C#
- License
- MIT
- Added
- 2026-09-08 22:05:06
- Updated
- 2026-09-08 22:05:06
- Origin id
io.github.daqifi/daqifi-mcp
README
# DAQiFi Core
> **Revolutionizing the data collection experience with convenient, portable device connectivity.**
>
> The official cross-platform .NET SDK for DAQiFi wireless data acquisition devices.
[](https://www.nuget.org/packages/Daqifi.Core)
[](https://www.nuget.org/packages/Daqifi.Core)
[](https://github.com/daqifi/daqifi-core/actions/workflows/ci.yml)
[](LICENSE)
**[daqifi.com](https://daqifi.com)** · **[DAQiFi Desktop](https://github.com/daqifi/daqifi-desktop)** · **[Report an issue](https://github.com/daqifi/daqifi-core/issues)**
---
## What is DAQiFi Core?
DAQiFi builds wireless data acquisition hardware designed to get out of the way so you can focus on the data, not the collection process.
**DAQiFi Core is how you integrate that hardware into your own .NET applications** — custom dashboards, automated test rigs, research pipelines, production-monitoring tools. Discover devices, connect over WiFi or USB, stream samples in real time, configure networks, push firmware updates — all from one async, strongly-typed .NET API.
Prefer a ready-made GUI? Check out [DAQiFi Desktop](https://github.com/daqifi/daqifi-desktop), which is built on top of this library.
Want to drive a device from an AI assistant? The repo also ships an **[MCP server](src/Daqifi.Mcp)** — point Claude, Cursor, Codex, or any MCP-aware client at it to discover, configure channels, drive digital I/O, PWM and analog outputs, set the sample rate, and run SD-card logging — then list, download, and CSV the recorded data back — through plain conversation.
## See it in 30 seconds
```shell
dotnet add package Daqifi.Core
```
```csharp
using Daqifi.Core.Device;
using Daqifi.Core.Channel;
// Connect — transport and device initialization handled for you.
await using var device = await DaqifiDeviceFactory.ConnectTcpAsync("192.168.1.100", 9760);
// Subscribe to decoded, per-channel samples
var ai0 = device.GetChannelsSnapshot().First(c => c.Type == ChannelType.Analog && c.ChannelNumber == 0);
ai0.SampleReceived += (_, e) => Console.WriteLine($"{e.Sample.Timestamp}: {e.Sample.Value} V");
// Enable channel 0, then stream at 100 Hz
device.EnableChannel(ai0);
device.StreamingFrequency = 100;
device.StartStreaming();
```
A real, working program — no GUI required. Prefer the raw protobuf frame instead? Subscribe to
`device.MessageReceived` — see [Streaming Data](docs/DEVICE_INTERFACES.md#streaming-data).
## Common applications
DAQiFi hardware is in the field for work like:
- **Research labs** — moon regolith testing and similar materials studies
- **Medical R&D** — prosthetic socket pressure testing
- **Industrial monitoring** — wireless multi-channel sensing
- **Engineering education** — SCPI command structure and LabVIEW compatibility
- **Test automation** — scripted benchtop measurements
More examples at [daqifi.com](https://daqifi.com).
## Where DAQiFi Core fits
| Layer | What it is |
|---|---|
| Hardware | Nyquist 1 / Nyquist 3 — wireless DAQ devices (and their on-device firmware) |
| **SDK** | **DAQiFi Core — this library** |
| App | [DAQiFi Desktop](https://github.com/daqifi/daqifi-desktop) — GUI built on this SDK |
| Agent | [MCP server](src/Daqifi.Mcp) — drive a device from Claude / Cursor / any MCP client: discover, configure channels, DIO/PWM/analog output, SD logging, and SD data retrieval |
| Your code | Custom apps, dashboards, pipelines, test rigs |
## What you can do
| Capability | What it gives you |
|---|---|
| **Auto-discovery** | Find any DAQiFi on WiFi or USB in seconds — no IP hunting, no config files |
| **One-line connect** | `DaqifiDeviceFactory.ConnectTcpAsync(...)` wraps transport setup and device init; retries are opt-in via `DeviceConnectionOptions` |
| **Real-time streaming** | Per-channel `IChannel.SampleReceived` events with decoded, scaled values — or subscribe to the raw protobuf frame directly; no polling loops to write |
| **Acquisition health** | Attach `AcquisitionStatistics` to a stream and read back the rate you are really getting, per-channel jitter, value range, and how far behind the device's clock the host is |
| **Record to CSV** | `device.RecordLiveSamplesToCsvAsync(writer)` writes a live stream to CSV as it arrives — no buffering the session in memory — and reports what reached the file and what was dropped |
| **Digital I/O** | Set any DIO pin as input or output and drive outputs high/low; inputs stream alongside analog data |
| **PWM outputs** | Drive PWM on capable DIO pins with per-channel duty cycle and a shared, device-wide frequency |
| **SD card operations** | List, download, delete, format, and start/stop SD logging over USB / serial |
| **Network configuration** | Push WiFi credentials and static LAN IPs from your app |
| **Firmware updates** | PIC32 and WiFi-module flashing with progress, cancellation, and automatic recovery to a clean re-flashable bootloader state on mid-flash failure |
| **Cross-platform** | .NET 9.0 and 10.0 on Windows, macOS, Linux |
## Quick recipes
### Connection options
Pick whichever transport fits your setup — each snippet is a standalone, copy-paste-ready starting point.
**TCP with a resilient retry preset** (5 retries, longer timeouts):
```csharp
await using var device = await DaqifiDeviceFactory.ConnectTcpAsync(
"192.168.1.100", 9760, DeviceConnectionOptions.Resilient);
```
**Serial / USB:**
```csharp
// Replace with your OS-specific port:
// Windows: "COM3" • macOS: "/dev/cu.usbmodem1" • Linux: "/dev/ttyACM0"
await using var device = await DaqifiDeviceFactory.ConnectSerialAsync("COM3");
```
**From a discovered device:**
```csharp
using var finder = new WiFiDeviceFinder();
var devices = await finder.DiscoverAsync(TimeSpan.FromSeconds(5));
await using var device = await DaqifiDeviceFactory.ConnectFromDeviceInfoAsync(devices.First());
```
### Custom retry options
```csharp
using Daqifi.Core.Communication.Transport;
var options = new DeviceConnectionOptions
{
DeviceName = "My DAQiFi",
ConnectionRetry = new ConnectionRetryOptions
{
MaxAttempts = 3,
ConnectionTimeout = TimeSpan.FromSeconds(10)
},
InitializeDevice = true
};
await using var device = await DaqifiDeviceFactory.ConnectTcpAsync("192.168.1.100", 9760, options);
```
> **Connecting takes control of the device.** A DAQiFi unit has a single global acquisition, and the
> default connect sequence stops it — so connecting to a device another session is already streaming
> silently ends that session's data. Use `DeviceConnectionOptions.Observing` for a secondary session
> that only needs to look, and `DaqifiDeviceRegistry` to avoid opening the same unit twice in one
> process. See
> [Connecting stops any stream already running](docs/DEVICE_INTERFACES.md#connecting-stops-any-stream-already-running).
### Device discovery
```csharp
using Daqifi.Core.Device.Discovery;
// WiFi — UDP broadcast on port 30303 by default
using var wifiFinder = new WiFiDeviceFinder();
wifiFinder.DeviceDiscovered += (_, e) =>
Console.WriteLine($"Found: {e.DeviceInfo.Name} at {e.DeviceInfo.IPAddress}");
var wifiDevices = await wifiFinder.DiscoverAsync(TimeSpan.FromSeconds(5));
// USB / Serial
using var serialFinder = new SerialDeviceFinder();
var serialDevices = await serialFinder.DiscoverAsync();
```
**On a home or multi-AP network, browse with mDNS as well.** UDP broadcast does not reliably
cross an access-point boundary — a device associated to a second AP is online and healthy, yet the
broadcast sweep returns nothing — so `MDnsDeviceFinder` browses the `_daqifi._tcp.local.` service
over multicast instead, which is the traffic consumer routers already reflect across APs, SSIDs and
VLANs. It produces the same `IDeviceInfo` shape, so anything that connects to a broadcast-discovered
device connects to an mDNS-discovered one unchanged.
```csharp
using var mdnsFinder = new MDnsDeviceFinder();
var mdnsDevices = await mdnsFinder.DiscoverAsync(TimeSpan.FromSeconds(5));
```
Run both — devices on firmware without an mDNS responder are still found over UDP broadcast, so the
two paths together cover more networks than either alone:
```csharp
using var finder = new AllTransportsDeviceFinder(
[new WiFiDeviceFinder(), new MDnsDeviceFinder(), new SerialDeviceFinder()],
identitySelector: device => device.SerialNumber);
var devices = await finder.DiscoverAsync(TimeSpan.FromSeconds(5));
```
The `identitySelector` is what collapses a board that answers on *both* network paths into a single
entry. Without one, the default per-transport identity prefers the MAC address, which the broadcast
reply carries and the mDNS advertisement does not, so the same board is reported twice — as two
entries that are both genuinely connectable, but still two.
Two caveats worth knowing: the device must be on firmware that advertises the service (see
daqifi-nyquist-firmware#345), and some hardened corporate or guest networks filter multicast
entirely — connect by IP address directly when they do.
Need fine-grained control? Pass a `CancellationToken` or override the discovery port:
```csharp
using var cts = new CancellationTokenSource();
cts.CancelAfter(TimeSpan.FromSeconds(10));
var devices = await wifiFinder.DiscoverAsync(cts.Token);
using var customFinder = new WiFiDeviceFinder(discoveryPort: 12345);
```
### Acquisition statistics
"Am I actually getting 1 kHz?" — attach an `AcquisitionStatistics` for the duration of a stream and
read a snapshot whenever you want the answer. It observes the same per-channel sample events
streaming already raises, so nothing changes for consumers that do not attach one.
```csharp
using Daqifi.Core.Device;
using var stats = new AcquisitionStatistics(device);
device.StreamingFrequency = 1000;
device.StartStreaming();
await Task.Delay(TimeSpan.FromSeconds(5));
device.StopStreaming();
var snapshot = stats.Snapshot();
foreach (var channel in snapshot.Channels)
{
Console.WriteLine(
$"{channel.Name}: {channel.SampleCount} samples, " +
$"{channel.MeasuredSampleRateHz:F1} Hz measured vs {channel.DeviceClockSampleRateHz:F1} Hz by the device clock, " +
$"{channel.MinValue:F3}..{channel.MaxValue:F3} V, worst gap {channel.MaxSampleInterval.TotalMilliseconds:F2} ms");
}
```
The two rates are reported side by side on purpose. Both dropping below the commanded rate means
samples went missing; the two disagreeing means the device's own clock is not keeping real time, and
it is `MeasuredSampleRateHz` that describes what your application actually received. `Reset()` starts
a fresh window mid-session, and `stats.Record(sample)` feeds one by hand from `StreamSamplesAsync`
instead of attaching.
### Record a live stream to CSV
Streaming and exporting used to be two halves with nothing between them. `RecordLiveSamplesToCsvAsync`
joins them: it writes rows through `CsvExporter` as frames decode, so the recording's memory does not
grow with its length, and it hands back what reached the file and what did not.
```csharp
using Daqifi.Core.Logging.Export;
device.StreamingFrequency = 100;
device.StartStreaming();
await using var writer = new StreamWriter("run.csv");
var result = await device.RecordLiveSamplesToCsvAsync(writer, duration: TimeSpan.FromSeconds(30));
device.StopStreaming();
Console.WriteLine($"{result.RowCount} rows from {result.SampleCount} samples");
if (result.DroppedSampleCount > 0)
{
Console.WriteLine($"{result.DroppedSampleCount} samples dropped — raise bufferCapacity or lower the rate");
}
```
The columns are the channels that were enabled when the call started, in device order. `duration`
elapsing is a clean finish — the last frame is written and the result comes back; cancelling the
`CancellationToken` is an abort and throws, so a recording cut short is never mistaken for a complete
one. Need the rows somewhere other than a `TextWriter`? Build a `LiveSampleSource` over
`StreamSamplesAsync` and hand it to `CsvExporter` (or any other `ISampleSource` consumer) yourself.
### Digital output
Digital channels default to inputs. Flip one to output and drive it — the level is applied
immediately, and flipping back to input releases the pin to high-impedance.
```csharp
using Daqifi.Core.Channel;
var channels = device.GetChannelsSnapshot();
var dio3 = channels.First(c => c.Type == ChannelType.Digital && c.ChannelNumber == 3);
device.SetDioDirection(dio3, ChannelDirection.Output);
device.SetDioValue(dio3, true); // drive high
device.SetDioValue(dio3, false); // drive low
device.SetDioDirection(dio3, ChannelDirection.Input); // back to a streamed input
```
Every `IStreamingDevice` method above (and the rest of the channel/PWM/analog-output/reboot surface)
has a cancellable `...Async` twin declared on the interface — see
[IStreamingDevice](docs/DEVICE_INTERFACES.md#istreamingdevice) for the full list.
### PWM output
PWM runs on capable DIO pins (`IDigitalChannel.IsPwmCapable` — channels 0, 3, 4, 5, 6 and 7 on
Nyquist hardware). Duty cycle is per channel; the frequency is shared by all PWM channels, since
one hardware timer drives them all.
```csharp
using Daqifi.Core.Channel;
var pwm = device.GetChannelsSnapshot()
.OfType<IDigitalChannel>()
.First(c => c.IsPwmCapable);
device.SetPwmDutyCycle(pwm, 25); // 1-100 percent
device.SetPwmFrequency(1000); // 6-50000 Hz, applies to every PWM channel
device.SetPwmEnabled(pwm, true); // start
device.SetPwmDutyCycle(pwm, 75); // duty changes take effect live
device.SetPwmEnabled(pwm, false); // stop — the pin is left high-impedance
```
### Network configuration
`DaqifiStreamingDevice` implements `INetworkConfigurable` for programmatic WiFi and LAN configuration. `Mode`, `Ssid`, and `Password` are always applied on every call; only `StaticIP`, `SubnetMask`, and `Gateway` honor `null` as "leave unchanged" — so DHCP-only callers can omit the static-IP fields without affecting their DHCP setup.
```csharp
using System.Net;
using Daqifi.Core.Device.Network;
var config = new NetworkConfiguration
{
Ssid = "MyNetwork",
Password = "secret",
Mode = WifiMode.ExistingNetwork,
StaticIP = IPAddress.Parse("192.168.1.42"),
SubnetMask = IPAddress.Parse("255.255.255.0"),
Gateway = IPAddress.Parse("192.168.1.1"),
};
await device.UpdateNetworkConfigurationAsync(config);
```
### Firmware updates
`IFirmwareUpdateService` orchestrates both PIC32 and WiFi-module flashing with explicit state transitions and `IProgress<FirmwareUpdateProgress>` for UI / CLI reporting.
- `UpdateFirmwareAsync(...)` — PIC32 firmware flashing from a local Intel HEX file
- `UpdateWifiModuleAsync(...)` — WiFi module flashing via an external tool runner. Automatically checks the device's current WiFi-chip firmware against the latest GitHub release and skips the flash if already up to date.
**Safe failure cleanup (PIC32).** If a PIC32 update fails — or is canceled — after flash has been written (`ErasingFlash`, `Programming`, or `Verifying`) and the HID bootloader is still connected, the service automatically re-erases the application flash so the device is never abandoned half-flashed: a half-flashed image would otherwise boot into garbage on the next power cycle, recoverable only by the physical button-hold procedure. The flow surfaces two extra states:
- `CleaningUp` — the re-erase is running; progress percent stays frozen at the failure point (never 100) so a percent-only UI can't mistake cleanup for success
- `Recovered` — terminal: the update **failed** (the call still throws), but the device is in a clean bootloader state and safe to simply re-flash
`FirmwareUpdateException.RecoveryGuidance` tells the operator whether to just re-run the update (`Recovered`) or power-cycle into bootloader mode first (cleanup couldn't run — the device may be half-flashed). `FirmwareUpdateException.FailedState` always reports where the original failure occurred, independent of cleanup outcome.
> **Note:** The default WiFi flash tool config uses `winc_flash_tool.cmd` conventions. On macOS / Linux, supply a compatible executable and argument template via `FirmwareUpdateServiceOptions`.
## Supported devices
| Device | Channels | Resolution | Range |
|---|---|---|---|
| **Nyquist 1** | 16 analog in | 12-bit | 0–5 V |
| **Nyquist 3** | 8 analog in | 18-bit | ±10 V |
These are auto-detected by part number during discovery. The SDK also recognizes and
supports **Nyquist 2** (`Nq2` → `DeviceType.Nyquist2`); it's left out of the spec table
above rather than listed with fabricated headline numbers. For any connected device the
authoritative channel counts, resolution, and ranges are reported by the hardware and
surfaced on `device.Metadata.Capabilities` after initialization.
Don't have one yet? **[See the DAQiFi lineup →](https://daqifi.com)**
## Connection types
- **WiFi** — discovered via UDP broadcast (port 30303)
- **Serial** — USB-connected, enumerated as serial ports
- **HID** — used during firmware updates (HidSharp backend)
## Requirements
- .NET 9.0 or .NET 10.0 on Windows, macOS, or Linux
- WiFi discovery: UDP port 30303 reachable (firewall may need configuring; admin may be required on Windows)
- Serial discovery: appropriate USB drivers for your platform
## Community & support
- [Open an issue](https://github.com/daqifi/daqifi-core/issues) for bugs or feature requests
- Reach the team via [daqifi.com](https://daqifi.com) for commercial integrations and custom hardware needs
## For maintainers
This library follows semantic versioning. Releases are automated via GitHub Actions:
1. Create a new GitHub Release
2. Tag it `vX.Y.Z` (pre-releases use `-alpha.1`, `-beta.1`, `-rc.1` suffixes)
3. Publishing to NuGet happens automatically on release
The same release also packs and publishes the **`Daqifi.Mcp`** MCP server as a .NET tool (`dotnet tool install -g Daqifi.Mcp`), and lists that version in the [official MCP Registry](https://registry.modelcontextprotocol.io) as `io.github.daqifi/daqifi-mcp` so MCP clients can find it without going through this README. The listing is published from `src/Daqifi.Mcp/.mcp/server.json`.
Semver here tracks **source** compatibility, not binary compatibility: appending a parameter
to a public positional record (with a default) is not treated as a breaking change requiring
a major bump, and is called out in release notes instead. Consumers who need binary
compatibility across versions should recompile against each release rather than swap the DLL
in place. See [ADR 0002](https://github.com/daqifi/daqifi-core/blob/main/docs/adr/0002-binary-compatibility-policy.md)
for the reasoning.
---
<p align="center">
Built by <a href="https://daqifi.com">DAQiFi</a> · Licensed under <a href="LICENSE">MIT</a>
</p>