SpikeInterface / SpikeInterface/probeinterface

Test data labeled NP1100 has electrode positions inconsistent with NP1100 catalogue geometry

Open
#407 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
85
Forks
49
Avg merge
13h 47m
Merged PRs (30d)
3

Description

Three probes in the test dataset OE_Neuropix-PXI-NP-Ultra/settings.xml are labeled probe_part_number="NP1100" (L75, L274, L473), but their electrode positions contradict the NP1100 specification. The XML positions show 48 um vertical spacing across a y range of 0-2256 um. According to the ProbeTable catalogue, NP1100 is a passive probe with only 384 total electrodes at 6 um pitch (y = 0-282 um), a single bank, and no electrode selection. This is an 8x mismatch in vertical spacing and the y range is off by an order of magnitude. Every other probe type in our test data (NP1, NP2, NP2 4-shank, NP-Opto, NP1110, NP1121) matches its catalogue geometry exactly.

I suspect the probe_part_number in the XML is wrong and these are actually NP1110 probes. The positions match NP1110 exactly: NP1110 (datasheet) has 6144 electrodes in an 8x768 grid at 6 um pitch with active electrode selection, and selecting every 8th row produces 48 rows at 48 um effective spacing = 2256 um. NP1110 is the only probe in the NP11xx family with more than 384 electrodes, making it the only one capable of producing the observed positions. The two part numbers differ by a single digit (NP1100 vs NP1110), and NP1100 is listed as non-commercial in the ProbeTable while NP1110 is commercial, so these may have been prototype units with an incorrect part number. Looking at the neuropixels-pxi plugin source, the part number is read directly from the probe's EEPROM chip via readProbePN() and passed through unchanged to the XML, so the mislabel would originate from the chip itself.

I propose that read_openephys raises an error when it encounters any probe whose XML positions don't match the catalogue geometry, and that we remove the NP1100 test data from our test suite. In the case of the NP1100 test data, the mismatch was caused by an incorrect part number on a non-commercial prototype, but in general both possible fallbacks (trusting the XML positions or trusting the catalogue) can be wrong, so I don't feel comfortable silently picking one. By raising an error we surface the problem to users. If this happens more often we can revisit and discuss a proper solution based on the cases reported. I am doing this on: https://github.com/SpikeInterface/probeinterface/pull/406

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the three NP1100 entries in tests/data/openephys/OE_Neuropix-PXI-NP-Ultra/settings.xml and trace how read_openephys handles their positions and part numbers. Review PR 406 for the work already in progress. The proposed outcome is to surface catalogue-geometry mismatches as errors and remove the inconsistent NP1100 test data, subject to the project's decision.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data, testing-qa
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.