With #441 (NP2.0 support, currently in review), read_spikegadgets_neuropixels covers three of the seven (device, deviceSubType) pairs Trodes recognises (configuration.cpp:5246-5291):
(device, deviceSubType) |
Status |
("neuropixels1", "10") |
supported (NP1.0 standard) |
("neuropixels2", "1_SHANK") |
supported via #441 (extrapolated, not yet fixture-verified) |
("neuropixels2", "4_SHANK") |
supported via #441 (fixture-verified) |
("neuropixels1", "HD") |
missing (NP1.0 High Density) |
("neuropixels1", "NHP_SHORT") |
missing |
("neuropixels1", "NHP_MEDIUM") |
missing |
("neuropixels1", "NHP_LONG") |
missing |
("neuropixelsNRIC", ...) |
missing (different device, separate dispatch path) |
The bottleneck for the missing variants is that SpikeGadgets .rec files do not record the IMEC probe part number, so we can only resolve down to a family ((device, deviceSubType)) rather than to a specific SKU. If SpikeGadgets surfaced the part number from the probe's EEPROM the way SpikeGLX and the Open Ephys neuropixels-pxi plugin already do, several of the missing variants would land automatically as one-line dispatch entries.
In the meanwhile, we could read the Trodes source and implement similar remappings. But I would like to wait for users who have a real recording or an XML companion they can share as test data; without one I do not want to extrapolate, since each variant has enough edges to make a from-source-only implementation likely to be subtly wrong. Please leave a comment with the variant you record on and we can take it from there.
With #441 (NP2.0 support, currently in review),
read_spikegadgets_neuropixelscovers three of the seven(device, deviceSubType)pairs Trodes recognises (configuration.cpp:5246-5291):(device, deviceSubType)("neuropixels1", "10")("neuropixels2", "1_SHANK")("neuropixels2", "4_SHANK")("neuropixels1", "HD")("neuropixels1", "NHP_SHORT")("neuropixels1", "NHP_MEDIUM")("neuropixels1", "NHP_LONG")("neuropixelsNRIC", ...)The bottleneck for the missing variants is that SpikeGadgets
.recfiles do not record the IMEC probe part number, so we can only resolve down to a family ((device, deviceSubType)) rather than to a specific SKU. If SpikeGadgets surfaced the part number from the probe's EEPROM the way SpikeGLX and the Open Ephys neuropixels-pxi plugin already do, several of the missing variants would land automatically as one-line dispatch entries.In the meanwhile, we could read the Trodes source and implement similar remappings. But I would like to wait for users who have a real recording or an XML companion they can share as test data; without one I do not want to extrapolate, since each variant has enough edges to make a from-source-only implementation likely to be subtly wrong. Please leave a comment with the variant you record on and we can take it from there.