Fix Neuropixels handling in SpikeGadgetsRawIO

[h-mayorquin]

SpikeGadgetsRawIO crashes with ZeroDivisionError when opening any Neuropixels .rec file from Trodes 2.8.2 onwards (closes issue #1844 and maybe #1810). Trodes writes chanPerChip="0" on those headers to signal that the recording has no Intan chip layout, and the existing reader divides by that value without a guard. While investigating, I found a separate silent bug in the existing NP1 data on gin: it writes chanPerChip="32" despite using a Neuropixels probe, so the old divisibility check passed and the file went through _produce_ephys_channel_ids, producing fabricated chip-style channel ids that did not match any real hardware channel.

The fix switches the discriminator from chanPerChip to the SpikeConfiguration.device attribute, which Trodes writes as "intan", "neuropixels1", or "neuropixels2" (absent on legacy files, which were always Intan). The hwChan path is now the default for every recording, and the Intan chip-id synthesis runs only as an override when device confirms the recording is Intan and the chip math works out. That route fixes both the NP2 crash and the silent NP1 misrouting in one change.

[dkassybayeva]

If in old version channel ids were incorrect, does it mean the whole pre-processing, including kilosort, needs to be rerun for those sessions to get correct ids and probe positions?
I.e. does it affect channelmap.prb construction?

[alejoe91]

If in old version channel ids were incorrect, does it mean the whole pre-processing, including kilosort, needs to be rerun for those sessions to get correct ids and probe positions? I.e. does it affect channelmap.prb construction?

I don't think it will, but @h-mayorquin can confirm!

[RobertoDF]

If in old version channel ids were incorrect, does it mean the whole pre-processing, including kilosort, needs to be rerun for those sessions to get correct ids and probe positions? I.e. does it affect channelmap.prb construction?

I don't think it will, but @h-mayorquin can confirm!

Having sorted many sessions of the older version, I can say the channel ordering looked fine

[h-mayorquin]

Hi @dkassybayeva, let me be clear about what changed.

For Neuropixels 1, the ids and names in signal_channels are changing. They were incorrect: the reader was passing every recording through the same chip-interleaved-id path that the tetrode/Intan recordings need, and that path produces meaningless labels for Neuropixels (which has no Intan chips). Crucially, the data extraction path does not change. The output of get_analogsignal_chunk is byte-for-byte the same as before, and the same is true if you were extracting data via SpikeInterface's get_traces(). The only workflows that will be disrupted are those that were relying on specific channel id or name strings; workflows that select channels by positional index are not affected.

For your concrete question about Kilosort: as far as I am aware the channel map (channelmap.prb or the equivalent chanMap.mat) is purely positional, so if you are running Kilosort directly the sorting should not be affected. Are you running Kilosort directly, or through SpikeInterface? @RobertoDF you mentioned the channel ordering looked fine on the older code, does your pipeline go through SpikeInterface?

[h-mayorquin]

One more ask while I have you both here: would either of you be willing to share a short recording from your rig to add to our test set? That would be really helpful. Our current NP1 fixture is from Trodes 2.3.2 (where chanPerChip="32" for Neuropixels), so we do not have any fixture that exercises the exact configuration that has been reported (Trodes 2.8.x with chanPerChip="0"). In fact, anything you can spare would help: NP1, NP2, single-probe, single-shank, whatever your default rig produces, in any way you can send it. I can take care of stubbing and anonymizing the data.