Offline CSV export under-counts analog channels (infers from first sample, which has only 1 value)

[tylerkron]

Summary

When exporting an SD log to CSV offline (--sd-parse <file> --sd-export-csv <out>) and the log file has no embedded device-config/status message, ExportSdSessionToCsvAsync infers the analog channel count by peeking the first sample:

var first = enumerator.Current;
analogCount = first.AnalogValues.Count;   // Program.cs ~line 1155

But the device's first stream message routinely carries only a single analog value (subsequent messages carry the full set). So analogCount is inferred as 1, and SdCardSampleSource then truncates every later sample to one analog channel, printing:

Warning: sample has 2 analog values but configured channel count is 1; extra channels will not appear in the CSV.

The result is silent data loss — the exported CSV contains only AI0, dropping all other analog channels.

Reproduction

# capture a 2-channel stream to a bin with no status frame, then export offline
--serial <port> --sd-capture-parse capture.bin --rate 100 --duration 2 --channels 3
--sd-parse capture.bin --sd-export-csv capture.csv

capture.csv has a single AI0 column despite two analog channels being enabled.

Notes

• Core's CsvExporter is not at fault — it faithfully writes exactly the channels the ISampleSource declares. The bug is the channel-count inference in the example app.
• Files that do contain a device-config frame (e.g. real --sd-download results) export all channels correctly, because analogCount comes from DeviceConfig.AnalogPortCount.

Suggested fix

Infer the analog count from the maximum AnalogValues.Count seen across a small prefix of samples (or the whole file), not the first sample — or default to the device's AnalogPortCount when any config is available.

Found during daqifi-core v1.2.0 pre-release hardware testing.

[tylerkron]

Root cause for the "first sample has only 1 value" premise is now tracked host-side in daqifi-core#425 — Core has no first-frame protection (the Core half of core#351 was never implemented), so the malformed frame reaches every consumer.

Device-side it's daqifi-nyquist-firmware#707, closed/fixed, but the fix post-dates FW 3.7.2, so field hardware still emits it.

Re-confirmed on bench Nq1 (FW 3.7.2, Core main @ 359bf74) during a capability sweep: the truncation warning and the resulting single-AI0 CSV reproduce exactly as described here. If core#425 lands, the inference in this issue still wants fixing (a log file could always be short), but the common trigger disappears.