Add Probe type

[rly]

Currently, the Device type is used to represent both a probe and the data acquisition system. It would be helpful to have a separate Probe type that inherits from Device and has a link to another Device, which represents the data acquisition system. That way the probe metadata is explicitly associated with the data acquisition system metadata.

We should also clarify the intended usage of Device and add it to the best practices document.

[rly]

A new Headstage, Amplifier, and DataAcquisitionSystem types, which all inherit from Device, would also be useful. They need to relate to one another such that it is clear how signals are transformed from the brain to the data acquisition system.

A typical extracellular ephys experiment includes: 1 to N probes (which each consists of 1 to N shanks, which each consists of 1 to N electrode contacts) Each probe is connected to a headstage, usually 1 to 1 Each headstage is connected to an amplifier and analog to digital converter (or these are bundled into the headstage), usually many headstages to a single amplifier box. All amplifiers are connected to a central data acquisition system.

All of these devices have their own settings/parameters that are useful for interpreting the data (e.g., hardware filters, software filters, gain, digitizing resolution, impedance, model number, version). These usually do not change within an experimental session. NWB stores these parameters with the data or the electrode, but a user/lab may wish to store the individual devices as neurodata types in NWB and additional configuration details.

Currently, each electrode (row in the electrodes table) links to an ElectrodeGroup which links to a Device. We can add additional, more refined Device types, e.g., for Probe, Headstage, DataAcquisitionSystem, where the type links to the next type in the chain from electrode to DataAcquisitionSystem. This is currently optimized for the use case of queries originating from TimeSeries (e.g., given an ElectricalSeries, get the Probe that was used to record it). This is not optimized for queries originating from the Probe (e.g., given a Probe, get all ElectricalSeries collected from it), but we cannot optimize both ways because that duplicates data, which runs the risk of inconsistent data. Bi-directional associations can be made in the API.

So I propose we create types for: DataAcquisitionSystem that inherits from Device. Amplifier that inherits from Device and has a link to the DataAcqusitionSystem that is connected to it. Headstage that inherits from Device and has a link to the Amplifier that is connected to it. Probe that inherits from Device and has a link to the Headstage that is connected to it. An ElectrodeGroup can then link to a Probe.

Example from my own work: DataAcquisitionSystem (inherits from Device)

• name: Plexon
• model: Omniplex A
• manufacturer: Plexon
• description: Plexon Omniplex A data acquisition system with recording channels 1-96, analog amplifier, analog eye-tracking output (x, y) on channels 126 and 127 via BNC input, and analog lever output on channel 128 via BNC input. Plexon V-probes were connected to 20X gain analog headstages. Signals were amplified at 1000X gain and then digitized. 16 individual TTL input ports were used for marking events. Wideband data (no software filters), high-pass filtered data, and low-pass filtered data (LFP) were acquired. All data were filtered with an analog 4-pole Bessel filter with an 8 kHz cutoff in the Plexon DigiAmp for anti-aliasing prior to digitization. Wideband data were acquired at 40 kHz. Wideband data were high-pass filtered using a 4-pole Bessel high-pass filter with 300 Hz cutoff and kept at 40 kHz as the spike signal for spike sorting. Wideband data were low-pass filtered using a 4-pole Bessel filter with a 200 Hz cutoff and downsampled to 1 kHz as the LFP.
• software_version: 14 note: the sampling rate and resolution are stored on the TimeSeries. hardware filtering is stored on the ElectrodeGroup.

Amplifier

• name: Amplifier
• gain: 1000
• serial number: unknown
• item number: unknown
• model: OmniAmp
• manufacturer: Plexon
• description: 64-channel amplifier with 1000x gain that receives analog signals from the headstage and transmits analog signals to the Omniplex main chassis.
• data_acq_system: link to DataAcquisitionSystem

Headstage (inherits from Device)

• name: V-Probe headstage
• gain: 20
• serial number: unknown
• item number: 52244
• model: HST/32V-G20
• manufacturer: Plexon
• description: 32-channel VLSI headstage, 20x gain
• amplifier: link to Amplifier

Probe (inherits from Device)

• name: V-Probe 1
• serial number: unknown
• item number: 92030-002
• model: PLX-VP-32-15SE(150)-(238-65)(460-10)-CT-300-(1)-CON/32m-V
• manufacturer: Plexon
• description: 32-channel V-Probe inserted acutely into the pulvinar. V-Probe, 32-chan w/ 15um elect dia; 150um inter-elect spacing; 65mm total probe length (10mm length, 460um diameter reinforcement tube); 238um probe diameter; w/ CON/32m-V connector interface; conical tip; 300um from tip to 1st electrode site
• headstage: link to Headstage (optional)

ElectrodeGroup

• groups together 32 electrodes from the electrodes table that belong to a single 32-channel probe
• device: link to Device

ElectrodesTable (currently not its own type but would be nice if it were)

• each row has an electrode as currently specified in NWB plus a field for electrode diameter
• each row currently has a link to an ElectrodeGroup (parent is nwbfile/general/extracellular_ephys)

We could also include details about the cabling but I think those are not as useful for interpreting the data.

[rly]

I am reviving this because it came up in a discussion today. Not urgent but I am recording my notes.

We should use ProbeInterface to the extent possible: https://github.com/SpikeInterface/probeinterface They have a data type for the probe type, as well as a mapping file that maps local channel x to probe electrode y. For example, a neuropixels 1 probe has 960 electrodes and the user selects 384 channels to record from. Assuming the neuropixels 1 probe has a standardized configuration that says that electrode 0 is at (0,0), electrode 1 is at (0, 40), etc., then the electrode positions and the local channel to probe electrode mapping determine the channel positions.

This is better than storing the channel positions alone because downstream users cannot use those alone to determine which electrodes on the probe were used. In addition, different labs may use different (x,y) referencing schemes for their electrodes, e.g. one lab might use the top left of the probe as (0,0) and another lab might use the bottom right as (0,0). For most probes, the mapping file is not important -- the mapping is one to one.

[bendichter]

I think these are all great ideas, and could be particularly powerful with external resources, e.g. Plexon -> https://ror.org/013rrw978

[oruebel]

I agree, this is all very interesting. This is interesting both from the perspective of providing more accurate metadata for analysis and also from the perspective of tool integration with ProbeInterface. Let's start by creating an extension for this

[bendichter]

@alejoe91, would you mind chiming in? In particulary, do you think there is any metadata we might want to extract from a ProbeInterface.Probe that would go better in a Probe object instead of the electrodes table?

[bendichter]

@rly maybe we could work on this an an extension? How about the name ndx-ecephys-devices

[alejoe91]

Let me also include @samuelgarcia in the loop.

In probeinterface we have several levels of abstraction (contact, shank, probe, probe-group, see docs). For commonly used probes, the probeinterface object carries info about:

• x, y, (z) locations in um
• contact shape and size
• probe "contour" (e.g. the shape of the silicon substrate)
• contact_id (aka electrode name)
• shank_id

All of these information will be important to include in the extension.

Regarding naming, I would avoid devices in favor of probes. While clearly probes are also devices, I think that device will/can include also acquisition devices (say Open Ephys Acquisition Board), while probes are neural probes. What about ndx-ecephys-probe?

[bendichter]

@alejoe91 the idea behind that name was that this extension would include headstage and amp, as @rly describes above. You might be right though that it would be better to create an extension specifically for interfacing with ProbeInterface.