Skip to content

Proposal: Add ProbeInterface Support for ONIX Source Plugin #358

@bparks13

Description

@bparks13

Hi there! I'm currently helping develop a new Open Ephys GUI plugin, ONIX Source, which streams Neuropixels data from an ONIX acquisition system. We already have a beta release and are aiming to maintain compatibility with the existing Neuropixels-PXI and OneBox plugins wherever possible.

Current Behavior

Using SpikeInterface, we're able to load neural data from ONIX recordings via si.read_openephys, since the stream structure is consistent. However, generating probe geometry using pi.read_openephys does not currently work for ONIX Source, as that function is tailored for PXI and OneBox plugins.

The main limitation stems from the lack of embedded probe metadata in the ONIX plugin's settings.xml file — unlike PXI/OneBox, which include additional details like part number and probe version in XML, allowing the function to infer the inter_sample_shift and probe contours.

Proposed Solution

Rather than modifying the XML structure for the plugin (and requiring changes to pi.read_openephys parsing logic), we propose the following:

  • Create an ONIX Source folder alongside each Record Node folder
  • Save a fully formatted ProbeInterface JSON file to this folder for each stream
  • Modify pi.read_openephys to:
    • Detect if the source is ONIX Source
    • Search for a corresponding JSON file in the ONIX folder (e.g., ../ONIX Source XXX/<stream_name>.json)
    • Stream names would have '-AP'/'-LFP' suffixes stripped to align with how ProbeInterface handles these as a single device
  • Load and return the probe group directly using:
from probeinterface import read_probeinterface
probegroup = read_probeinterface('/path/to/<stream_name>.json')
return probegroup

This avoids the need to embed detailed metadata in the XML file and ensures we preserve compatibility with existing workflows.

Benefits

  • No changes needed to ONIX's minimal XML structure
  • Cleaner separation of concerns (streaming vs. probe config)
  • Allows seamless use of pi.read_openephys for ONIX users

Let me know if this approach seems viable, or if there are edge cases we might be missing. I’d be happy to help implement or test the changes!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions