Summary
The rewritten CereLink has never been tested against two chained legacy analog NSPs, in either STANDALONE or CENTRAL CLIENT mode. Tracking as a known gap; we do not currently have the hardware.
At least one lab appears to run this configuration — https://github.com/BCM-Neurosurgery/CereLink/tree/bcm_dual_nsp maintains a fork with dual-NSP code.
Why this configuration specifically
A legacy analog NSP is the only device type carrying both front-end channels and physical I/O. Gemini hubs are front-end only; the Gemini NSP is I/O only. Chaining two doubles the I/O.
That makes it the one topology where a single contiguous per-instrument channel range has to span mixed channel types — and the per-instrument channel windowing added in #195 makes a specific, untested claim about it:
each NSP's procinfo.chancount covers its own FE and its own physical I/O, so dense packing places NSP0 at 1..chancount0 and NSP1 directly after, with no special-casing.
If that assumption is wrong, dual-NSP users get exactly the channel-aliasing bug #195 fixes for Gemini — one instrument's channels silently served as another's. That failure mode is quiet: reads succeed and return plausible values.
What to verify when hardware is available
procinfo.chancount for each NSP — does it include the physical I/O, or only front-end channels?- Do the two NSPs' channels occupy one contiguous range each, or are FE and I/O blocks interleaved across instruments?
get_channel_label() / bank assignments on NSP1 — do they match the device, or NSP0's?- Both protocol paths (3.11 and 4.1) and both modes.
The bcm_dual_nsp fork is worth diffing first; they have likely already encountered the real behaviour, and may be willing to test a build.
Related
Summary
The rewritten CereLink has never been tested against two chained legacy analog NSPs, in either STANDALONE or CENTRAL CLIENT mode. Tracking as a known gap; we do not currently have the hardware.
At least one lab appears to run this configuration — https://github.com/BCM-Neurosurgery/CereLink/tree/bcm_dual_nsp maintains a fork with dual-NSP code.
Why this configuration specifically
A legacy analog NSP is the only device type carrying both front-end channels and physical I/O. Gemini hubs are front-end only; the Gemini NSP is I/O only. Chaining two doubles the I/O.
That makes it the one topology where a single contiguous per-instrument channel range has to span mixed channel types — and the per-instrument channel windowing added in #195 makes a specific, untested claim about it:
If that assumption is wrong, dual-NSP users get exactly the channel-aliasing bug #195 fixes for Gemini — one instrument's channels silently served as another's. That failure mode is quiet: reads succeed and return plausible values.
What to verify when hardware is available
procinfo.chancountfor each NSP — does it include the physical I/O, or only front-end channels?get_channel_label()/ bank assignments on NSP1 — do they match the device, or NSP0's?The
bcm_dual_nspfork is worth diffing first; they have likely already encountered the real behaviour, and may be willing to test a build.Related