Gets or sets the number of samples collected for each channel that are use to create a single AnalogInputDataFrame.
+
This property determines the number of analog samples that are buffered for each channel before data is propagated. For instance, if this
+value is set to 100, then 100 samples, along with corresponding clock values, will be collected from each of the input channels
+and packed into each AnalogInputDataFrame. Because channels are sampled at 100 kHz, this is equivalent to 1
+millisecond of data from each channel.
Gets or sets the data type used to represent analog samples.
+
If S16 is selected, each ADC sample is represented at a signed, twos-complement encoded
+16-bit integer. S16 samples can be converted to a voltage using each channels'
+AnalogIOVoltageRange selection. For instance, channel 0 can be converted using InputRange0.
+When Volts is selected, the voltage conversion is performed automatically and samples
+are represented as 32-bit floating point voltages.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Sends analog output data to an ONIX breakout board.
+
This data IO operator must be linked to an appropriate configuration, such as a ConfigureAnalogIO, using a shared DeviceName.
+
+
+
+
Inputs & Outputs
+
+
Send an matrix of samples to all enabled analog outputs.
+
If a matrix contains multiple samples, they will be written to hardware as quickly as
+communication allows. The data within each input matrix must have S16 when
+DataType is set to S16 or F32
+when DataType is set to Volts.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of 12xN sample matrices containing the analog data to write to
+channels 0 to 11.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of 12xN sample matrices containing the analog data that were written to
+channels 0 to 11.
+
+
+
+
+
+
+
+
+
+
Send an 12-element array of values to update all enabled analog outputs.
+
This overload should be used when DataType is set to S16 and values should be within -32,768 to 32,767, which
+correspond to -10.0 to 10.0 volts.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of 12x1 element arrays each containing the analog data to write
+to channels 0 to 11.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of 12x1 element arrays each containing the analog data to write to channels 0
+to 11.
+
+
+
+
+
+
+
+
+
+
Send an 12-element array of values to update all enabled analog outputs.
+
This overload should be used when DataType is set to Volts and values should be within -10.0 to 10.0 volts.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of 12x1 element arrays each containing the analog data to write
+to channels 0 to 11.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of 12x1 element arrays each containing the analog data to write to channels 0
+to 11.
Gets or sets the data type used to represent analog samples.
+
If S16 is selected, each DAC value is represented by a
+signed, twos-complement encoded 16-bit integer. In this case, the output voltage always
+corresponds to TenVolts. When Volts is selected, 32-bit floating point voltages between -10
+and 10 volts are sent directly to the DACs.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Specifies the axis map of a Bno055 compared to the default orientation.
+the datasheet.
+
The axis of the device can be reconfigured to the new reference axis to account for
+differences in its mounting position. The following values can be applied to the Bno055's
+AXIS_MAP_CONFIG register at address 0x41 in order to rotate the Bno055's coordinate system
+compared to the default orientation presented on page 24 of the Bno055 datasheet.
The axis of the device can be reconfigured to the new reference axis to account for
+differences in its mounting position. The following values can be applied to the Bno055's
+AXIS_MAP_SIGN register at address 0x42 to mirror specific axes in the Bno055's coordinate
+system compared to the default orientation presented on page 24 of the Bno055 datasheet.
+
+
+
Fields
+
+
+
+
Field & Value
+
Description
+
+
+
+
+ Default = 0
+
+
+
+
Specifies that all axes are positive (chip default).
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Acquisition clock count that is synchronous for all frames collected within an ONI context created using CreateContext.
+The acquisition clock rate is given by AcquisitionClockHz. This clock value provides a common, synchronized
+time base for all data collected with an single ONI context.
Local, potentially asynchronous, clock count. Aside from the synchronous Clock value, data frames also contain a local clock
+count produced within the oni.Hub that the data was actually produced within. For instance, a headstage may contain an onboard controller
+for controlling devices and arbitrating data stream that runs asynchronously from the AcquisitionClockHz. This value
+is therefore the most precise way to compare the sample time of data collected within a given oni.Hub. However, the delay between time of
+data collection and synchronous time stamping by Clock is very small (sub-microsecond) and this value can therefore
+be disregarded in most scenarios in favor of Clock.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
Gets or sets a value specifying if the output clock is active.
+
If set to true, the clock output will be connected to the clock output line. If set to false, the
+clock output line will be held low. This value can be toggled in real time to gate acquisition of
+external hardware.
Gets or sets the delay following acquisition commencement before the clock becomes active in
+seconds.
+
+Valid values are between 0 and and 3600 seconds. Setting to a value greater than 0 can be useful
+for ensuring data sources that are driven by the output clock start significantly after ONIX has
+begun acquisition for the purposes of ordering acquisition start times.
+
+
+The delay must be an integer multiple of the Acquisition Clock frequency. Therefore, the true delay
+cycle will be set to a value that is as close as possible to the requested setting while
+respecting this constraint. The value as actualized in hardware is reported by OutputClockData.
+
Gets or sets the output clock duty cycle in percent.
+
Valid values are between 10% and 90%. The output clock high and low times must each be an integer
+multiple of the Acquisition Clock frequency.
+Therefore, the true duty cycle will be set to a value that is as close as possible to the
+requested setting while respecting this constraint. The value as actualized in hardware is
+reported by OutputClockData.
Valid values are between 0.1 Hz and 10 MHz. The output clock high and low times must each be an
+integer multiple of the Acquisition Clock
+frequency. Therefore, the true clock frequency will be set to a value that is as close as possible
+to the requested setting while respecting this constraint. The value as actualized in hardware is
+reported by OutputClockData.
+
+
+
+
+
+
+
DigitalIO
+
+
DigitalIO is a ConfigureDigitalIO operator encapsulated by the ConfigureBreakoutBoard operator.
Gets or sets a value specifying the physical Harp clock input source.
+
In standard ONIX breakout boards, the Harp mini-jack connector on the side of the
+breakout is configured to receive Harp clock synchronization signals.
+
In early access versions of the ONIX breakout board, the Harp mini-jack connector is
+configured for output only, so a special adapter is needed to transmit the
+Harp clock synchronization signal to the breakout clock input zero.
+
+
+
+
Breakout = 0
+
+
+
+
ClockAdapter = 1
+
+
+
+
+
+
+
+
+
Heartbeat
+
+
Heartbeat is a ConfigureHeartbeat operator encapsulated by the ConfigureBreakoutBoard operator.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
Configures the ONIX breakout board's Harp
+sync input.
+
+This configuration operator can be linked to a data IO operator, such as HarpSyncInputData, using a shared DeviceName.
+
+
+Harp is a standard for asynchronous real-time data acquisition and experimental
+control in neuroscience. It includes a clock synchronization protocol which allows
+Harp devices to be connected to a shared clock line and continuously self-synchronize
+their clocks to a precision of tens of microseconds. This means that all experimental
+events are timestamped on the same clock and no post-hoc alignment of timing is necessary.
+
+
+The Harp clock signal is transmitted over a serial line every second.
+Every time the Harp sync input device in the ONIX breakout board detects a full Harp
+synchronization packet, a new data frame is emitted pairing the current value of the
+Harp clock with the local ONIX acquisition clock.
+
+
+Logging the sequence of all Harp synchronization packets can greatly facilitate post-hoc
+analysis and interpretation of timing signals. For more information see
+https://harp-tech.org/.
+
+
+
+
+
Inputs & Outputs
+
+
Configures a ONIX breakout board Harp sync input device.
+
This will schedule configuration actions to be applied by a StartAcquisition instance
+prior to data acquisition.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of ContextTask instances that hold configuration actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The original sequence modified by adding additional configuration actions required to configure
+a ONIX breakout board Harp sync input device.
Gets or sets a value specifying the physical Harp clock input source.
+
In standard ONIX breakout boards, the Harp mini-jack connector on the side of the
+breakout is configured to receive Harp clock synchronization signals.
+
In early access versions of the ONIX breakout board, the Harp mini-jack connector is
+configured for output only, so a special adapter is needed to transmit the
+Harp clock synchronization signal to the breakout clock input zero.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
Configures an ONIX headstage-64 on the specified port.
+
Headstage-64 is a 1.5g serialized, multifunction headstage for small animals. This headstage is
+designed to function with passive probes such as tetrode microdrives, silicon arrays, EEG/ECOG arrays,
+etc. It provides the following features:
+
64 analog ephys channels and 3 auxiliary channels sampled at 30 kHz per
+channel.
A BNO055 9-axis IMU for real-time, 3D orientation tracking.
Three TS4231 light to digital converters for real-time, 3D position tracking with
+HTC Vive base stations.
A single electrical stimulator (current controlled, +/-15V compliance, automatic
+electrode discharge).
Two optical stimulators (800 mA peak current per channel).
+
+
+
+
Inputs & Outputs
+
+
Configure all devices in the device group.
+
This will schedule configuration actions to be applied by a StartAcquisition instance
+prior to data acquisition.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of ContextTask instances that hold configuration actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The original sequence modified by adding additional configuration actions required to configure
+all the devices in the device group.
+
+
+
+
+
+
+
+
+
+
Properties
+
+
+
ConfigureHeadstage64 is an aggregate operator. Its properties comprise of the following operators' properties:
+
+
+
Bno055
+
+
Bno055 is a ConfigureBno055 operator encapsulated by the ConfigureHeadstage64 operator.
+If defined, it will override automated voltage discovery and apply the specified voltage to the
+headstage. If left blank, an automated headstage detection algorithm will attempt to communicate
+with the headstage and apply an appropriate voltage for stable operation. Because ONIX allows any
+coaxial tether to be used, some of which are thin enough to result in a significant voltage drop,
+its may be required to manually specify the port voltage.
+
+
+Warning: this device requires 5.5V to 6.0V, measured at the headstage, for proper operation.
+Supplying higher voltages may result in damage.
+
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
Configures a Nric1384 headstage on the specified port.
+
The Nric1384 Headstage is a 2.5g serialized, multifunction headstage for small animals built around the
+IMEC Nric1384 bioacquisition chip. This headstage is designed to function with passive probes of the
+user's choosing (e.g. silicon probe arrays, high-density tetrode drives, etc). It provides the
+following features:
+
384 analog ephys channels sampled at 30 kHz per channel and exposed via an array of
+12x ultra-high density Molex 203390-0323 quad-row connectors.
A BNO055 9-axis IMU for real-time, 3D orientation tracking at 100
+Hz.
Two TS4231 light to digital converters for real-time, 3D position tracking with HTC
+Vive base stations.
A single electrical stimulator (current controlled, +/-15V compliance, automatic
+electrode discharge).
+
+
+
+
Inputs & Outputs
+
+
Configure all devices in the device group.
+
This will schedule configuration actions to be applied by a StartAcquisition instance
+prior to data acquisition.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of ContextTask instances that hold configuration actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The original sequence modified by adding additional configuration actions required to configure
+all the devices in the device group.
+
+
+
+
+
+
+
+
+
+
Properties
+
+
+
ConfigureHeadstageNric1384 is an aggregate operator. Its properties comprise of the following operators' properties:
+
+
+
Bno055
+
+
Bno055 is a ConfigureBno055 operator encapsulated by the ConfigureHeadstageNric1384 operator.
Gets or sets the path to the ADC calibration file.
+
+Each chip must be provided with an ADC calibration file that contains chip-specific hardware settings that is
+created by IMEC during factory calibration. These files are used to set internal bias currents, correct for ADC
+nonlinearities, correct ADC-zero crossing non-monotonicities, etc. Using the correct calibration file is mandatory
+for the chip to operate correctly.
+
+
+Calibration files are chip-specific and not interchangeable across chips. Calibration files must contain the
+serial number of the corresponding chip on their first line of text. If you have lost track of a calibration
+file for your chip, email IMEC at neuropixels.info@imec.be with the chip serial number to retrieve a new copy.
+
Gets or sets the path to the gain calibration file.
+
+Each chip is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across chips. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are chip-specific and not interchangeable across chips. Calibration files must contain the
+serial number of the corresponding chip on their first line of text. If you have lost track of a calibration
+file for your chip, email IMEC at neuropixels.info@imec.be with the chip serial number to retrieve a new copy.
+
+If defined, it will override automated voltage discovery and apply the specified voltage to the headstage.
+If left blank, an automated headstage detection algorithm will attempt to communicate with the headstage and
+apply an appropriate voltage for stable operation. Because ONIX allows any coaxial tether to be used, some of
+which are thin enough to result in a significant voltage drop, its may be required to manually specify the
+port voltage.
+
+
+Warning: This device requires 3.8V to 5.5V for proper operation. Voltages higher than 5.5V can
+damage the headstage.
+
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
This configuration operator can be linked to a data IO operator, such as LoadTesterData,
+using a shared DeviceName. The load tester device can be configured
+to produce data at user-settable size and rate to stress test various communication links and test
+closed-loop response latency.
+
+
+
+
Inputs & Outputs
+
+
Configures a load testing device.
+
This will schedule configuration actions to be applied by a StartAcquisition instance
+prior to data acquisition.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of ContextTask instances that hold configuration actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The original sequence modified by adding additional configuration actions required to configure
+a load testing device.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
This configuration operator can be linked to a data IO operator, such as MemoryMonitorData, using a shared DeviceName.The memory
+monitor produces periodic snapshots of the system's first in, first out (FIFO) data buffer. This can
+be useful for:
+
Ensuring that data is being read by the host PC quickly enough to prevent real-time
+delays or overflows. In the case that the PC is not keeping up with data collection, FIFO memory use
+will increase monotonically.
Tuning the value of ReadSize to optimize real-time
+performance. For optimal real-time performance, ReadSize should be as
+small as possible and the FIFO should be bypassed (memory usage should remain at 0). However, these
+requirements are in conflict. The memory monitor provides a way to find the minimal value of value of
+ReadSize that does not result in excessive FIFO data buffering. This
+tradeoff will depend on the bandwidth of data being acquired, the performance of the host PC, and
+downstream real-time processing.
+
+
+
+
Inputs & Outputs
+
+
Configures a memory monitor device.
+
This will schedule configuration actions to be applied by a StartAcquisition instance
+prior to data acquisition.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of ContextTask instances that holds configuration actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The original sequence modified by adding additional configuration actions required to configure a memory monitor device.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
Gets or sets the path to the ADC calibration file.
+
+Each probe must be provided with an ADC calibration file that contains probe-specific hardware settings that is
+created by IMEC during factory calibration. These files are used to set internal bias currents, correct for ADC
+nonlinearities, correct ADC-zero crossing non-monotonicities, etc. Using the correct calibration file is mandatory
+for the probe to operate correctly.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the path to the gain calibration file.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
Configures a NeuropixelsV1e headstage on the specified port.
+
The NeuropixelsV1e Headstage is a 0.68g serialized, multifunction headstage for small animals. This
+headstage is designed to function with IMEC Neuropixels V1 probes. It provides the following features:
+
Support for a single IMEC Neuropixels 1.0 probe that features:
+
A single 1 cm long shank probe with a 70 x 24 µm shank cross-section.
Gets or sets the axis map that will be applied during configuration.
+
This value can be changed to compensate for the Bno055's mounting orientation.
+Specifically, this value can be set to rotate the Bno055's coordinate system compared
+to the default orientation presented on page 24 of the Bno055 datasheet.
Gets or sets the axis sign that will be applied during configuration.
+
This value can be changed to compensate for the Bno055's mounting orientation.
+Specifically, this value can be set to mirror specific axes in the Bno055's coordinate
+system compared to the default orientation presented on page 24 of the Bno055 datasheet.
Gets or sets the path to the ADC calibration file.
+
+Each probe must be provided with an ADC calibration file that contains probe-specific hardware settings that is
+created by IMEC during factory calibration. These files are used to set internal bias currents, correct for ADC
+nonlinearities, correct ADC-zero crossing non-monotonicities, etc. Using the correct calibration file is mandatory
+for the probe to operate correctly.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the path to the gain calibration file.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
If a port voltage is defined this will override the automated voltage discovery and applies the
+specified voltage to the headstage. To enable automated voltage discovery, leave this field empty.
+Warning: This device requires 3.8V to 5.0V, measured at the headstage, for proper operation.
+Voltages higher than 5.0V can damage the headstage.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
Gets or sets the path to the ADC calibration file.
+
+Each probe must be provided with an ADC calibration file that contains probe-specific hardware settings that is
+created by IMEC during factory calibration. These files are used to set internal bias currents, correct for ADC
+nonlinearities, correct ADC-zero crossing non-monotonicities, etc. Using the correct calibration file is mandatory
+for the probe to operate correctly.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the path to the gain calibration file.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
Configures a NeuropixelsV1f headstage on the specified port.
+
The NeuropixelsVf Headstage is a 1g serialized, multifunction headstage for small animals. This
+headstage is designed to function with IMEC Neuropixels V1 probes. It provides the following features:
+
Support for a 2x IMEC Neuropixels 1.0 probes, each of which features:
+
A single 1 cm long shank probe with a 70 x 24 µm shank cross-section.
Gets or sets the path to the ADC calibration file.
+
+Each probe must be provided with an ADC calibration file that contains probe-specific hardware settings that is
+created by IMEC during factory calibration. These files are used to set internal bias currents, correct for ADC
+nonlinearities, correct ADC-zero crossing non-monotonicities, etc. Using the correct calibration file is mandatory
+for the probe to operate correctly.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the path to the gain calibration file.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the path to the ADC calibration file.
+
+Each probe must be provided with an ADC calibration file that contains probe-specific hardware settings that is
+created by IMEC during factory calibration. These files are used to set internal bias currents, correct for ADC
+nonlinearities, correct ADC-zero crossing non-monotonicities, etc. Using the correct calibration file is mandatory
+for the probe to operate correctly.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the path to the gain calibration file.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
If a port voltage is defined this will override the automated voltage discovery and applies the
+specified voltage to the headstage. To enable automated voltage discovery, leave this field empty.
+Warning: This device requires 4.5V to 5.5V, measured at the headstage, for proper operation.
+Voltages higher than 6.0V can damage the headstage.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
Gets or sets the path to the gain calibration file for Probe A.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the path to the gain calibration file for Probe B.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the electrode configuration for Probe A.
+
Configuration is accomplished using a GUI to aid in channel selection and relevant configuration properties.
+To open a probe configuration GUI, select the ellipses next the ProbeConfigurationA variable
+in the property pane, or double-click ConfigureNeuropixelsV2eHeadstage to configure both
+probes and the ConfigurePolledBno055 simultaneously.
Gets or sets the electrode configuration for Probe B.
+
Configuration is accomplished using a GUI to aid in channel selection and relevant configuration properties.
+To open a probe configuration GUI, select the ellipses next the ProbeConfigurationB variable
+in the property pane, or double-click ConfigureNeuropixelsV2eHeadstage to configure both
+probes and the ConfigurePolledBno055 simultaneously.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
Gets or sets the path to the gain calibration file for Probe A.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the path to the gain calibration file for Probe B.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the electrode configuration for Probe A.
+
Configuration is accomplished using a GUI to aid in channel selection and relevant configuration properties.
+To open a probe configuration GUI, select the ellipses next the ProbeConfigurationA variable
+in the property pane, or double-click ConfigureNeuropixelsV2eBetaHeadstage to configure both
+probes and the ConfigurePolledBno055 simultaneously.
Gets or sets the electrode configuration for Probe B.
+
Configuration is accomplished using a GUI to aid in channel selection and relevant configuration properties.
+To open a probe configuration GUI, select the ellipses next the ProbeConfigurationB variable
+in the property pane, or double-click ConfigureNeuropixelsV2eBetaHeadstage to configure both
+probes and the ConfigurePolledBno055 simultaneously.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
Configures a NeuropixelsV2eBeta headstage on the specified port.
+
The NeuropixelsV2e-Beta Headstage is a 0.64g serialized, multifunction headstage for small animals. This
+headstage is designed to function with IMEC Neuropixels V2Beta probes. It provides the following features:
+
Support for dual IMEC Neuropixels 2.0-Beta probes, each of which features:
+
4x silicon shanks with a 70 x 24 µm cross-section.
1280 electrodes low-impedance TiN electrodes per shank.
Gets or sets the axis map that will be applied during configuration.
+
This value can be changed to compensate for the Bno055's mounting orientation.
+Specifically, this value can be set to rotate the Bno055's coordinate system compared
+to the default orientation presented on page 24 of the Bno055 datasheet.
Gets or sets the axis sign that will be applied during configuration.
+
This value can be changed to compensate for the Bno055's mounting orientation.
+Specifically, this value can be set to mirror specific axes in the Bno055's coordinate
+system compared to the default orientation presented on page 24 of the Bno055 datasheet.
Gets or sets the path to the gain calibration file for Probe A.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the path to the gain calibration file for Probe B.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the electrode configuration for Probe A.
+
Configuration is accomplished using a GUI to aid in channel selection and relevant configuration properties.
+To open a probe configuration GUI, select the ellipses next the ProbeConfigurationA variable
+in the property pane, or double-click ConfigureNeuropixelsV2eBetaHeadstage to configure both
+probes and the ConfigurePolledBno055 simultaneously.
Gets or sets the electrode configuration for Probe B.
+
Configuration is accomplished using a GUI to aid in channel selection and relevant configuration properties.
+To open a probe configuration GUI, select the ellipses next the ProbeConfigurationB variable
+in the property pane, or double-click ConfigureNeuropixelsV2eBetaHeadstage to configure both
+probes and the ConfigurePolledBno055 simultaneously.
+
+
+
+
+
+
+
Misc
+
+
+
These are properties of the aggregate operator, not of any constituent operator.
If a port voltage is defined this will override the automated voltage discovery and applies
+the specified voltage to the headstage. To enable automated voltage discovery, leave this field
+empty. Warning: This device requires 3.0V to 5.0V for proper operation. Voltages higher than 5.0V can
+damage the headstage
Configures a NeuropixelsV2e headstage on the specified port.
+
The NeuropixelsV2e Headstage is a 0.64g serialized, multifunction headstage for small animals. This
+headstage is designed to function with IMEC Neuropixels V2 probes. It provides the following features:
+
Support for dual IMEC Neuropixels 2.0 probes, each of which features:
+
Either 1x or 4x silicon shanks with a 70 x 24 µm cross-section.
1280 electrodes low-impedance TiN electrodes per shank.
Gets or sets the axis map that will be applied during configuration.
+
This value can be changed to compensate for the Bno055's mounting orientation.
+Specifically, this value can be set to rotate the Bno055's coordinate system compared
+to the default orientation presented on page 24 of the Bno055 datasheet.
Gets or sets the axis sign that will be applied during configuration.
+
This value can be changed to compensate for the Bno055's mounting orientation.
+Specifically, this value can be set to mirror specific axes in the Bno055's coordinate
+system compared to the default orientation presented on page 24 of the Bno055 datasheet.
Gets or sets the path to the gain calibration file for Probe A.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the path to the gain calibration file for Probe B.
+
+Each probe is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across probes. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are probe-specific and not interchangeable across probes. Calibration files must contain the
+serial number of the corresponding probe on their first line of text. If you have lost track of a calibration
+file for your probe, email IMEC at neuropixels.info@imec.be with the probe serial number to retrieve a new copy.
+
Gets or sets the electrode configuration for Probe A.
+
Configuration is accomplished using a GUI to aid in channel selection and relevant configuration properties.
+To open a probe configuration GUI, select the ellipses next the ProbeConfigurationA variable
+in the property pane, or double-click ConfigureNeuropixelsV2eHeadstage to configure both
+probes and the ConfigurePolledBno055 simultaneously.
Gets or sets the electrode configuration for Probe B.
+
Configuration is accomplished using a GUI to aid in channel selection and relevant configuration properties.
+To open a probe configuration GUI, select the ellipses next the ProbeConfigurationB variable
+in the property pane, or double-click ConfigureNeuropixelsV2eHeadstage to configure both
+probes and the ConfigurePolledBno055 simultaneously.
+
+
+
+
+
+
+
Misc
+
+
+
These are properties of the aggregate operator, not of any constituent operator.
If a port voltage is defined this will override the automated voltage discovery and applies
+the specified voltage to the headstage. To enable automated voltage discovery, leave this field
+empty. Warning: This device requires 3.0V to 5.5V for proper operation. Voltages higher than 5.5V can
+damage the headstage
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
Gets or sets the path to the ADC calibration file.
+
+Each chip must be provided with an ADC calibration file that contains chip-specific hardware settings that is
+created by IMEC during factory calibration. These files are used to set internal bias currents, correct for ADC
+nonlinearities, correct ADC-zero crossing non-monotonicities, etc. Using the correct calibration file is mandatory
+for the chip to operate correctly.
+
+
+Calibration files are chip-specific and not interchangeable across chips. Calibration files must contain the
+serial number of the corresponding chip on their first line of text. If you have lost track of a calibration
+file for your chip, email IMEC at neuropixels.info@imec.be with the chip serial number to retrieve a new copy.
+
Gets or sets the path to the gain calibration file.
+
+Each chip is linked to a gain calibration file that contains gain adjustments determined by IMEC during
+factory testing. Electrode voltages are scaled using these values to ensure they can be accurately compared
+across chips. Therefore, using the correct gain calibration file is mandatory to create standardized recordings.
+
+
+Calibration files are chip-specific and not interchangeable across chips. Calibration files must contain the
+serial number of the corresponding chip on their first line of text. If you have lost track of a calibration
+file for your chip, email IMEC at neuropixels.info@imec.be with the chip serial number to retrieve a new copy.
+
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
Configures the ONIX breakout board's output clock.
+
The output clock provides a 3.3V logic level, 50 Ohm output impedance, frequency divided copy
+of the Acquisition Clock that is used to generate
+Clock values for all data streams within an ONIX system. This clock runs at a
+user defined rate, duty cycle, and start delay. It can be used to drive external hardware or can be
+logged by external recording systems for post-hoc synchronization with ONIX data.
+
+
+
+
Inputs & Outputs
+
+
Configures a clock output.
+
This will schedule configuration actions to be applied by a StartAcquisition
+instance prior to data acquisition.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of ContextTask instances that holds configuration
+actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The original sequence modified by adding additional configuration actions required to
+configure a clock output device./>
Gets or sets a value specifying if the output clock is active.
+
If set to true, the clock output will be connected to the clock output line. If set to false, the
+clock output line will be held low. This value can be toggled in real time to gate acquisition of
+external hardware.
Gets or sets the delay following acquisition commencement before the clock becomes active in
+seconds.
+
+Valid values are between 0 and and 3600 seconds. Setting to a value greater than 0 can be useful
+for ensuring data sources that are driven by the output clock start significantly after ONIX has
+begun acquisition for the purposes of ordering acquisition start times.
+
+
+The delay must be an integer multiple of the Acquisition Clock frequency. Therefore, the true delay
+cycle will be set to a value that is as close as possible to the requested setting while
+respecting this constraint. The value as actualized in hardware is reported by OutputClockData.
+
Gets or sets the output clock duty cycle in percent.
+
Valid values are between 10% and 90%. The output clock high and low times must each be an integer
+multiple of the Acquisition Clock frequency.
+Therefore, the true duty cycle will be set to a value that is as close as possible to the
+requested setting while respecting this constraint. The value as actualized in hardware is
+reported by OutputClockData.
Valid values are between 0.1 Hz and 10 MHz. The output clock high and low times must each be an
+integer multiple of the Acquisition Clock
+frequency. Therefore, the true clock frequency will be set to a value that is as close as possible
+to the requested setting while respecting this constraint. The value as actualized in hardware is
+reported by OutputClockData.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
Gets or sets the axis map that will be applied during configuration.
+
This value can be changed to compensate for the Bno055's mounting orientation.
+Specifically, this value can be set to rotate the Bno055's coordinate system compared
+to the default orientation presented on page 24 of the Bno055 datasheet.
Gets or sets the axis sign that will be applied during configuration.
+
This value can be changed to compensate for the Bno055's mounting orientation.
+Specifically, this value can be set to mirror specific axes in the Bno055's coordinate
+system compared to the default orientation presented on page 24 of the Bno055 datasheet.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
Configures an array of Triad Semiconductor TS4231 lighthouse receivers for 3D position tracking using
+a pair of SteamVR V1 base stations.
+
This configuration operator can be linked to a data IO operator, such as TS4231V1PositionData, using a shared DeviceName to stream 3D
+position data from light-house receivers when SteamVR V1 base stations have been installed above the
+arena.
+
+
+
+
Inputs & Outputs
+
+
Configures a TS4231 receiver array.
+
This will schedule configuration actions to be applied by a StartAcquisition instance
+prior to data acquisition.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of ContextTask instances that holds configuration actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The original sequence modified by adding additional configuration actions required to configure a TS4231 array.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
Configures a UCLA Miniscope V4 on the specified port.
+
The UCLA Miniscope V4 is a miniaturized fluorescent microscope for performing single-photon calcium
+imaging in freely moving animals. It has the following features:
+
A Python-480 0.48 Megapixel CMOS image sensor.
A BNO055 9-axis IMU for real-time, 3D orientation tracking.
An electrowetting lens for remote focal plane adjustment.
An excitation LED with adjustable brightness control and optional exposure-driven
+interleaving to reduce photobleaching.
+
+
+
+
Inputs & Outputs
+
+
Configure all devices in the device group.
+
This will schedule configuration actions to be applied by a StartAcquisition instance
+prior to data acquisition.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of ContextTask instances that hold configuration actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The original sequence modified by adding additional configuration actions required to configure
+all the devices in the device group.
+
+
+
+
+
+
+
+
+
+
Properties
+
+
+
ConfigureUclaMiniscopeV4 is an aggregate operator. Its properties comprise of the following operators' properties:
+
+
+
Bno055
+
+
Bno055 is a ConfigurePolledBno055 operator encapsulated by the ConfigureUclaMiniscopeV4 operator.
Gets or sets the axis map that will be applied during configuration.
+
This value can be changed to compensate for the Bno055's mounting orientation.
+Specifically, this value can be set to rotate the Bno055's coordinate system compared
+to the default orientation presented on page 24 of the Bno055 datasheet.
Gets or sets the axis sign that will be applied during configuration.
+
This value can be changed to compensate for the Bno055's mounting orientation.
+Specifically, this value can be set to mirror specific axes in the Bno055's coordinate
+system compared to the default orientation presented on page 24 of the Bno055 datasheet.
Gets or sets a value indicating whether the excitation LED should turn on only when the camera
+shutter is open.
+
If set to true, the excitation LED will turn on briefly before, and turn off briefly after, the
+camera begins photon collection on its photodiode array. If set to false, the excitation LED will
+remain on at all times.
Gets or sets the liquid lens driver voltage (Volts RMS).
+
The imaging focal plane is controlled by using a MAX14574 high-voltage liquid lens driver. This
+chip produces pulse-width modulated, 5 kHz alternative electric field that deforms the miniscope's
+liquid lens in order to change the focal plane. The strength of this field determines the degree
+of deformation and therefore the focal depth. The default setting of 47 Volts RMS corresponds to
+approximately mid-range.
+If defined, it will override automated voltage discovery and apply the specified voltage to the miniscope.
+If left blank, an automated headstage detection algorithm will attempt to communicate with the miniscope and
+apply an appropriate voltage for stable operation. Because ONIX allows any coaxial tether to be used, some of
+which are thin enough to result in a significant voltage drop, its may be required to manually specify the
+port voltage.
+
+
+Warning: this device requires 4.0 to 5.0V, measured at the miniscope, for proper operation. Supplying higher
+voltages may result in damage.
+
+ This is a device configuration operator. Device configuration operators are not recommended for interfacing with off-the-shelf ONIX hardware. Use aggregate configuration operators to do that instead.
+
Gets or sets a value indicating whether the excitation LED should turn on only when the camera
+shutter is open.
+
If set to true, the excitation LED will turn on briefly before, and turn off briefly after, the
+camera begins photon collection on its photodiode array. If set to false, the excitation LED will
+remain on at all times.
Gets or sets the liquid lens driver voltage (Volts RMS).
+
The imaging focal plane is controlled by using a MAX14574 high-voltage liquid lens driver. This
+chip produces pulse-width modulated, 5 kHz alternative electric field that deforms the miniscope's
+liquid lens in order to change the focal plane. The strength of this field determines the degree
+of deformation and therefore the focal depth. The default setting of 47 Volts RMS corresponds to
+approximately mid-range.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
Encapsulates a single ONI context and orchestrates interaction with ONI-compliant hardware.
+
The Open Neuro Interface (ONI) hardware
+specification and API describe a general purpose acquisition system architecture and programming
+interface for communication with a host PC. One requirement of ONI is that a host application must
+hold a "context" that contains handles for hardware communication, data acquisition parameters, etc.
+for a particular hardware controller, such as the ONIX PCIe card. ContextTask fulfills
+this role for this library. Additionally, once data acquisition is started by the StartAcquisition operator, ContextTask performs the following:
+
It automatically reads and distributes data from hardware using a dedicated acquisition
+thread.
It allows data to be written to devices that accept them.
It allows reading from and writing to device registers to control their operation (e.g. Enable or AnalogHighCutoff).
+Additionally, this operator exposes important information about the underlying ONI hardware such as
+the device table, clock rates, and block read and write sizes. In summary, ContextTask forms a complete interface for all hardware interaction within the library: all
+physical interaction with the ONIX system passes through this class.
+
This property describes the frequency of ONI controller's acquisition clock, which is used to
+generate the Clock counter value included in all data frames
+produced by Data IO operators in this library (e.g. NeuropixelsV1eData or Bno055Data). The value of this property is determined during hardware initialization.
Gets the number of bytes read per cycle of the ContextTask's acquisition thread.
+
This option allows control over a fundamental trade-off between closed-loop response time and
+available bandwidth. A minimal value, which is determined by MaxReadFrameSize, will provide the lowest response latency, so long as data
+can be cleared from hardware memory fast enough to prevent buffering. Larger values will both
+reduce system call frequency and reduce the number of function calls per unit time performed by
+Bonsai, and therefore, increase available bandwidth. Larger values may improve processing
+performance for high-bandwidth data sources. The optimal value depends on the host computer and
+hardware configuration and must be determined via testing (e.g. using MemoryMonitorData).
Gets the number of bytes that are pre-allocated for writing data to hardware.
+
This value determines the amount of memory that is pre-allocated for calls to Write(uint, IntPtr, int), Write<T>(uint, T), and
+Write<T>(uint, T[]). A larger size will reduce the frequency of
+dynamic memory allocation system calls but increase the expense of each of those calls. The minimum
+size of this option is determined by MaxWriteFrameSize. The effect on
+real-time performance is typically not as large as that of BlockReadSize
+because this parameter defines a readily-available pool of memory for the creation of output data
+frames, but does not determine when they are written to hardware. Data is written to hardware as
+soon as an output frame has been created. In contrast data is read from hardware whenever more than
+ReadSize bytes have accumulated in the input buffer.
Gets the size of the largest data frame produced by any device with the acquisition system in bytes.
+
This number describes the the size, in bytes, of the largest ONI Data Frame
+produced by any device within the current device table that generates data. Therefore, it also
+defines the lower bound for the value of BlockReadSize. The value of this property
+is determined during hardware initialization.
Gets the size of the largest data frame consumed by any device with the acquisition system in bytes.
+
This number describes the the size, in bytes, of the largest ONI Data Frame
+consumed by any device within the current device table that accepts data. Therefore, it also
+defines the lower bound for the value of BlockWriteSize. The value of this property
+is determined during hardware initialization.
This property describes the frequency of the clock governing the ONI controller. The value of this
+property is determined during hardware initialization.
Creates a ContextTask that orchestrates data acquisition for an ONIX system.
+
ONIX is built on top of the Open Neuro Interface
+(ONI) hardware specification and API. One of ONI's requirements is the creation of a "context"
+that holds information needed for communication between a host computer and ONI-compliant hardware.
+The context holds data such as the device driver that will be used to communicate with hardware, what
+devices (e.g. headstages and their internal components) are currently connected, how
+often data should be read by the host computer, etc. CreateContext creates this required
+ONI context for a single ONIX system. The ONIX system that the context serves is uniquely identified
+within a host computer by the Driver used to communicate with hardware and the Index, which is a enumeration that is translated by the driver into a physical interface
+(e.g. a particular PCIe slot) within the host computer.
+
+
+
+
Inputs & Outputs
+
+
Generates a sequence that creates a new ContextTask object.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
A sequence containing a single instance of the ContextTask class. Cancelling the
+sequence will dispose of the created context.
Gets or sets the index of the host interconnect between the ONI controller and host computer.
+
For instance, 0 could correspond to a particular PCIe slot or USB port as enumerated by the
+operating system and translated by an ONI
+device driver translator. A value of -1 will attempt to open the default index and is useful
+if there is only a single ONI controller managed by the specified selected Driver in
+the host computer.
Acquisition clock count that is synchronous for all frames collected within an ONI context created using CreateContext.
+The acquisition clock rate is given by AcquisitionClockHz. This clock value provides a common, synchronized
+time base for all data collected with an single ONI context.
Local, potentially asynchronous, clock count. Aside from the synchronous Clock value, data frames also contain a local clock
+count produced within the oni.Hub that the data was actually produced within. For instance, a headstage may contain an onboard controller
+for controlling devices and arbitrating data stream that runs asynchronously from the AcquisitionClockHz. This value
+is therefore the most precise way to compare the sample time of data collected within a given oni.Hub. However, the delay between time of
+data collection and synchronous time stamping by Clock is very small (sub-microsecond) and this value can therefore
+be disregarded in most scenarios in favor of Clock.
Provides an abstract base class for all device configuration operators.
+
ONI devices usually require a specific sequence of configuration and parameterization
+steps before they can be interacted with. The DeviceFactory provides
+a modular abstraction for flexible assembly and sequencing of both single and multi-
+device configuration.
Provides a type converter to convert a device name to and from other representations.
+It also provides a mechanism to find existing devices declared in the workflow.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Acquisition clock count that is synchronous for all frames collected within an ONI context created using CreateContext.
+The acquisition clock rate is given by AcquisitionClockHz. This clock value provides a common, synchronized
+time base for all data collected with an single ONI context.
Local, potentially asynchronous, clock count. Aside from the synchronous Clock value, data frames also contain a local clock
+count produced within the oni.Hub that the data was actually produced within. For instance, a headstage may contain an onboard controller
+for controlling devices and arbitrating data stream that runs asynchronously from the AcquisitionClockHz. This value
+is therefore the most precise way to compare the sample time of data collected within a given oni.Hub. However, the delay between time of
+data collection and synchronous time stamping by Clock is very small (sub-microsecond) and this value can therefore
+be disregarded in most scenarios in favor of Clock.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Produces a sequence of Harp clock synchronization signals sent to the Harp input in the ONIX breakout
+board.
+
+This configuration operator can be linked to a data IO operator, such as HarpSyncInputData, using a shared DeviceName.
+
+
+Harp is a standard for asynchronous real-time data acquisition and experimental
+control in neuroscience. It includes a clock synchronization protocol which allows
+Harp devices to be connected to a shared clock line and continuously self-synchronize
+their clocks to a precision of tens of microseconds. This means that all experimental
+events are timestamped on the same clock and no post-hoc alignment of timing is necessary.
+
+
+The Harp clock signal is transmitted over a serial line every second.
+Every time the Harp sync input device in the ONIX breakout board detects a full Harp
+synchronization packet, a new data frame is emitted pairing the current value of the
+Harp clock with the local ONIX acquisition clock.
+
+
+Logging the sequence of all Harp synchronization packets can greatly facilitate post-hoc
+analysis and interpretation of timing signals. For more information see
+https://harp-tech.org/.
+
+
+
+
+
Inputs & Outputs
+
+
Generates a sequence of HarpSyncInputDataFrames, each of
+which contains information about a single Harp clock synchronization event.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Acquisition clock count that is synchronous for all frames collected within an ONI context created using CreateContext.
+The acquisition clock rate is given by AcquisitionClockHz. This clock value provides a common, synchronized
+time base for all data collected with an single ONI context.
Local, potentially asynchronous, clock count. Aside from the synchronous Clock value, data frames also contain a local clock
+count produced within the oni.Hub that the data was actually produced within. For instance, a headstage may contain an onboard controller
+for controlling devices and arbitrating data stream that runs asynchronously from the AcquisitionClockHz. This value
+is therefore the most precise way to compare the sample time of data collected within a given oni.Hub. However, the delay between time of
+data collection and synchronous time stamping by Clock is very small (sub-microsecond) and this value can therefore
+be disregarded in most scenarios in favor of Clock.
Specifies the Harp 3.5-mm audio jack connector on the side of the ONIX breakout board.
+
+
+
+
+
+
+ ClockAdapter = 1
+
+
+
+
Specifies SMA clock input 0 on the ONIX breakout board.
+
In early access versions of the ONIX breakout board, Harp 3.5-mm audio jack connector was
+configured for output only, so a special adapter was needed to transmit the Harp clock
+synchronization signal to the breakout clock input zero.
Controls a headstage-64 onboard electrical stimulus sequencer.
+
This data IO operator must be linked to an appropriate configuration, such as a ConfigureHeadstage64ElectricalStimulator, using a shared DeviceName.
+Headstage-64's onboard electrical stimulator can be used to deliver current controlled
+micro-stimulation through a contact on the probe connector on the bottom of the headstage or the
+corresponding contact on a compatible electrode interface board.
+
+
+
+
Inputs & Outputs
+
+
Start an electrical stimulus sequence.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of boolean values indicating the start of a stimulus sequence when true.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of boolean values that is identical to source
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Gets or sets the electrical stimulator's power state.
+
If set to true, then the electrical stimulator's ±15V power supplies will be turned on. If set to false,
+they will be turned off. It may be desirable to power down the electrical stimulator's power supplies outside
+of stimulation windows to reduce power consumption and electrical noise. This property must be set to true
+in order for electrical stimuli to be delivered properly. It takes ~10 milliseconds for these supplies to stabilize.
Controls a headstage-64 onboard optical stimulus sequencer.
+
This data IO operator must be linked to an appropriate configuration, such as a ConfigureHeadstage64OpticalStimulator, using a shared DeviceName.
+Headstage-64's onboard optical stimulator can be used to drive current through laser diodes or LEDs
+connected to two contacts on the probe connector on the bottom of the headstage or the corresponding
+contacts on a compatible electrode interface board.
+
+
+
+
Inputs & Outputs
+
+
Start an optical stimulus sequence.
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of boolean values indicating the start of a stimulus sequence when true.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of boolean values that is identical to source
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Gets or sets the Maximum current per channel per pulse in mA.
+
This value defines the maximal possible current that can be delivered to each channel.
+To get different amplitudes for each channel use the ChannelOneCurrent and
+ChannelTwoCurrent properties.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Acquisition clock count that is synchronous for all frames collected within an ONI context created using CreateContext.
+The acquisition clock rate is given by AcquisitionClockHz. This clock value provides a common, synchronized
+time base for all data collected with an single ONI context.
Local, potentially asynchronous, clock count. Aside from the synchronous Clock value, data frames also contain a local clock
+count produced within the oni.Hub that the data was actually produced within. For instance, a headstage may contain an onboard controller
+for controlling devices and arbitrating data stream that runs asynchronously from the AcquisitionClockHz. This value
+is therefore the most precise way to compare the sample time of data collected within a given oni.Hub. However, the delay between time of
+data collection and synchronous time stamping by Clock is very small (sub-microsecond) and this value can therefore
+be disregarded in most scenarios in favor of Clock.
This data IO operator must be linked to an appropriate configuration, such as a ConfigureMemoryMonitor, using a shared DeviceName.
+
+
+
+
Inputs & Outputs
+
+
Generates a sequence of MemoryMonitorDataFrame objects, which contains information
+about the system's first-in, first-out (FIFO) hardware data buffer.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Acquisition clock count that is synchronous for all frames collected within an ONI context created using CreateContext.
+The acquisition clock rate is given by AcquisitionClockHz. This clock value provides a common, synchronized
+time base for all data collected with an single ONI context.
Local, potentially asynchronous, clock count. Aside from the synchronous Clock value, data frames also contain a local clock
+count produced within the oni.Hub that the data was actually produced within. For instance, a headstage may contain an onboard controller
+for controlling devices and arbitrating data stream that runs asynchronously from the AcquisitionClockHz. This value
+is therefore the most precise way to compare the sample time of data collected within a given oni.Hub. However, the delay between time of
+data collection and synchronous time stamping by Clock is very small (sub-microsecond) and this value can therefore
+be disregarded in most scenarios in favor of Clock.
Provides an abstract base class for configuration operators responsible for
+registering all devices within a logical group in the internal device manager.
+
+This class allows configuration of logical groups of devices that share some common functionality
+and/or require a specific sequence of interdependent configuration steps prior to acquisition. For
+instance, devices on a headstage can be combined with a device on the controller
+that is used to set the port voltage and monitor headstage communication status
+(e.g. ConfigureHeadstage64). Alternatively, devices that share some common functionality
+from the user's perspective, but share no actual interdependent configuration from the perspective of
+the hardware, can be grouped for ease of use (e.g. ConfigureBreakoutBoard).
+
+
+These device groups are the most common starting point for configuration
+of an ONIX system, and the MultiDeviceFactory provides a modular abstraction for flexible
+assembly and sequencing of device groups.
+
Specifies the bank of electrodes within each shank.
+
+
+
Fields
+
+
+
+
Field & Value
+
Description
+
+
+
+
+ A = 0
+
+
+
+
Specifies that Bank A is the current bank.
+
Bank A is defined as shank index 0 to 383 along each shank.
+
+
+
+
+
+
+ B = 1
+
+
+
+
Specifies that Bank B is the current bank.
+
Bank B is defined as shank index 384 to 767 along each shank.
+
+
+
+
+
+
+ C = 2
+
+
+
+
Specifies that Bank C is the current bank.
+
Bank C is defined as shank index 768 to 960 along each shank. Note that Bank C is not a full contingent
+of 384 channels; to compensate for this, electrodes from Bank B (starting at shank index 576) are used to
+generate a full 384 channel map.
A 20-bit counter on the probe that increments its value for every frame produced.
+The value ranges from 0 to 1048575 (2^20-1), and should always increment by 1 until it wraps around back to 0.
+This can be used to detect dropped frames.
LFP data has 32 rows (channels) with columns representing the samples acquired at 2.5 kHz. Each sample is a
+10-bit, offset binary value encoded as a ushort.
Spike-band data has 384 rows (channels) with columns representing the samples acquired at 30 kHz. Each sample is a
+10-bit, offset binary value encoded as a ushort.
Gets or sets a string defining the ChannelConfiguration in Base64.
+This variable is needed to properly save a workflow in Bonsai, but it is not
+directly accessible in the Bonsai editor.
All electrodes are set to the same reference, which can be either
+External or Tip.
+Setting to External will use the external reference, while
+Tip sets the reference to the electrode at the tip of the probe.
Buffer size sets the number of super frames that are buffered before propagating data.
+A super frame consists of 384 channels from the spike-band and 32 channels from the LFP band.
+The buffer size must be a multiple of 12.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Buffer size sets the number of super frames that are buffered before propagating data.
+A super frame consists of 384 channels from the spike-band and 32 channels from the LFP band.
+The buffer size must be a multiple of 12.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Specifies the bank of electrodes within each shank.
+
+
+
Fields
+
+
+
+
Field & Value
+
Description
+
+
+
+
+ A = 0
+
+
+
+
Specifies that Bank A is the current bank.
+
Bank A is defined as shank index 0 to 383 along each shank.
+
+
+
+
+
+
+ B = 1
+
+
+
+
Specifies that Bank B is the current bank.
+
Bank B is defined as shank index 384 to 767 along each shank.
+
+
+
+
+
+
+ C = 2
+
+
+
+
Specifies that Bank C is the current bank.
+
Bank C is defined as shank index 768 to 1151 along each shank.
+
+
+
+
+
+
+ D = 3
+
+
+
+
Specifies that Bank D is the current bank.
+
Bank D is defined as shank index 1152 to 1279 along each shank. Note that Bank D is not a full contingent
+of 384 channels; to compensate for this, electrodes from Bank C (starting at shank index 896) are used to
+generate a full 384 channel map.
Gets or sets a string defining the ChannelConfiguration in Base64.
+This variable is needed to properly save a workflow in Bonsai, but it is not
+directly accessible in the Bonsai editor.
All electrodes are set to the same reference, which can be
+External or any of the tip references
+(Tip1, Tip2, etc.).
+Setting to External will use the external reference, while
+Tip1 sets the reference to the electrode at the tip of the first shank.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Frame count is a 20-bit counter on the probe that increments its value for every frame produced.
+The value ranges from 0 to 1048575 (2^20-1), and should always increment by 1 until it wraps around back to 0.
+This can be used to detect dropped frames.
This property determines the number of samples that are collected from each of the 384 ephys
+channels before data is propagated. For instance, if this value is set to 30, then 384x30 samples,
+along with 30 corresponding clock values, will be collected and packed into each NeuropixelsV2eDataFrame. Because channels are sampled at 30 kHz, this is equivalent to 1
+millisecond of data from each channel.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Buffer size sets the number of super frames that are buffered before propagating data.
+A super frame consists of 384 channels from the spike-band and 32 channels from the LFP band.
+The buffer size must be a multiple of 12.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
A 20-bit counter on the chip that increments its value for every frame produced. The value ranges from 0 to
+1048575 (2^20-1), and should always increment by 13 (one count is taken per super-frame and there are 13 frames
+in a super frame) until it wraps around back to 0. This can be used to detect dropped frames.
LFP data has 32 rows (channels) with columns representing the samples acquired at 2.5 kHz. Each sample is a
+10-bit, offset binary value encoded as a ushort.
Spike-band data has 384 rows (channels) with columns representing the samples acquired at 30 kHz. Each sample is a
+10-bit, offset binary value encoded as a ushort.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Generates a sequence of Bno055DataFrames that is driven by an
+input sequence.
+
This will attempt to produce a sequence of Bno055DataFrames that is updated whenever
+an item in the source sequence is received. This rate is be limited by the
+hardware and has a maximum meaningful rate of 100 Hz.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Specifies the physical port that a headstage is plugged into.
+
ONIX uses a common protocol to communicate with a variety of devices using the same physical connection. For this reason
+lots of different headstage types can be plugged into a headstage port.
Produces a sequence of port status information frames.
+
This data IO operator must be linked to an appropriate headstage or miniscope configuration (e.g. ConfigureNeuropixelsV2eBeta) using a shared DeviceName.
+
+
+
+
Inputs & Outputs
+
+
Generates a sequence of PortStatusFrame objects, which contains information
+about the the a headstage port communication status.
+
A PortStatusFrame will be produced only in exceptional circumstances. For
+instance, when the headstage becomes disconnected, a packet fails a CRC check, etc.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Acquisition clock count that is synchronous for all frames collected within an ONI context created using CreateContext.
+The acquisition clock rate is given by AcquisitionClockHz. This clock value provides a common, synchronized
+time base for all data collected with an single ONI context.
Local, potentially asynchronous, clock count. Aside from the synchronous Clock value, data frames also contain a local clock
+count produced within the oni.Hub that the data was actually produced within. For instance, a headstage may contain an onboard controller
+for controlling devices and arbitrating data stream that runs asynchronously from the AcquisitionClockHz. This value
+is therefore the most precise way to compare the sample time of data collected within a given oni.Hub. However, the delay between time of
+data collection and synchronous time stamping by Clock is very small (sub-microsecond) and this value can therefore
+be disregarded in most scenarios in favor of Clock.
Gets or sets the number of samples collected for each channel that are used to create a single Rhd2164DataFrame.
+
This property determines the number of samples that are buffered for each electrophysiology and auxiliary channel produced by the Rhd2164 chip
+before data is propagated. For instance, if this value is set to 30, then 30 samples, along with corresponding clock values, will be collected
+from each of the electrophysiology and auxiliary channels and packed into each Rhd2164DataFrame. Because channels are sampled at
+30 kHz, this is equivalent to 1 millisecond of data from each channel.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Abstract base for configuration operators responsible for registering a single device within the
+internal device manager.
+
ONI devices usually require a specific sequence of configuration and parameterization steps before
+they can be interacted with. The SingleDeviceFactory provides a modular abstraction
+allowing flexible assembly and sequencing of of all device-specific configuration code.
This is a fully-qualified numerical hardware address of a device within the device table produced
+by an Open Neuro Interface (ONI) compliant
+acquisition system. This value is usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a fixed address with a piece of hardware such as a
+headstage. This address is used for hardware communication.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Starts data acquisition and frame distribution on a ContextTask.
+
The Open Neuro Interface (ONI) hardware
+specification and API describe a general purpose acquisition system architecture and programming
+interface for communication with a host PC. One requirement of ONI is a sequence of events that must
+occur in order to start synchronized data acquisition. StartAcquisition performs these
+required actions on one or more ContextTasks provided in its input
+sequence. Once acquisition is started, devices managed by a particular ContextTask will
+start to produce data in a format called an ONI Data Frame. The output
+sequence of this operator is therefore a IGroupedObservable<TKey, TElement>, where
+
Tkey
+Is the address of a particular hardware device within a single ContextTask.
+
TElement
+Is a ONI Frame produced by the device with address Tkey.
+
+These pre-sorted frame sequences can be interpreted by downstream Data I/O operators (e.g. AnalogInput or Bno055Data) that convert ONI Data Frames into
+data types that are are more amenable to processing within Bonsai workflows.
+
+
+
+
Inputs & Outputs
+
+
Starts data acquisition and frame distribution on a ContextTask and returns the
+sequence of all received oni.Frame objects, grouped by device address.
+
+
+
+
+
+
+
+
+
+
+
+
The sequence of ContextTask objects on which to start data acquisition and frame
+distribution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
A sequence of data frames produced by each ContextTask in the input sequence and
+grouped by device address.
Gets or sets the number of bytes read per cycle of the ContextTask's acquisition
+thread.
+
This option allows control over a fundamental trade-off between closed-loop response time and
+available bandwidth. A minimal value, which is determined by MaxReadFrameSize, will provide the lowest response latency, so long as data
+can be cleared from hardware memory fast enough to prevent buffering. Larger values will both
+reduce system call frequency and reduce the number of function calls per unit time performed by
+Bonsai, and therefore, increase available bandwidth. Larger values may improve processing
+performance for high-bandwidth data sources. The optimal value depends on the host computer and
+hardware configuration and must be determined via testing (e.g. using MemoryMonitorData).
Gets or sets the number of bytes that are pre-allocated for writing data to hardware.
+
This value determines the amount of memory that is pre-allocated for calls to Write(uint, IntPtr, int), Write<T>(uint, T), and
+Write<T>(uint, T[]). A larger size will reduce the frequency of
+dynamic memory allocation system calls but increase the expense of each of those calls. The minimum
+size of this option is determined by MaxWriteFrameSize. The effect on
+real-time performance is typically not as large as that of BlockReadSize
+because this parameter defines a readily-available pool of memory for the creation of output data
+frames, but does not determine when they are written to hardware. Data is written to hardware as
+soon as an output frame has been created. In contrast data is read from hardware whenever more than
+ReadSize bytes have accumulated in the input buffer.
Produces a sequence of decoded optical signals produced one or more SteamVR V1 base station(s).
+
+This data IO operator must be linked to an appropriate configuration, such as a ConfigureTS4231V1, using a shared DeviceName.
+
+
+The data produced by this class contains individual base station pulse/sweep codes and timing
+information. These data provide rapid updates that constrain the possible position of a sensor and
+therefore can be combined with orientation information in a downstream predictive model (e.g. Kalman
+filter) for high-accuracy and robust position tracking. To produce naïve position estimates, use the
+TS4231V1PositionData operator instead of this one.
+
+
+
+
+
Inputs & Outputs
+
+
Generates a sequence of TS4231V1DataFrame objects, each of which contains information on a single
+lighthouse optical sweep or pulse.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Acquisition clock count that is synchronous for all frames collected within an ONI context created using CreateContext.
+The acquisition clock rate is given by AcquisitionClockHz. This clock value provides a common, synchronized
+time base for all data collected with an single ONI context.
Local, potentially asynchronous, clock count. Aside from the synchronous Clock value, data frames also contain a local clock
+count produced within the oni.Hub that the data was actually produced within. For instance, a headstage may contain an onboard controller
+for controlling devices and arbitrating data stream that runs asynchronously from the AcquisitionClockHz. This value
+is therefore the most precise way to compare the sample time of data collected within a given oni.Hub. However, the delay between time of
+data collection and synchronous time stamping by Clock is very small (sub-microsecond) and this value can therefore
+be disregarded in most scenarios in favor of Clock.
Produces a sequence of 3D positions from an array of Triad Semiconductor TS4231 receivers beneath a
+pair of SteamVR V1 base stations.
+
+This data IO operator must be linked to an appropriate configuration, such as a ConfigureTS4231V1, using a shared DeviceName.
+
+
+The data produced by this class contains naïve geometric estimates of positions of photodiodes
+attached to each TS4231 chip. This operator makes the following assumptions about the setup:
+
Two SteamVR V1 base stations are used.
The base stations have been synchronized with a patch cable and their modes set to
+‘A’ and ‘b’, respectively.
The base stations are pointed in the same direction.
The Z-axis extends away the emitting face of lighthouses, X along the direction of
+the text on the back label, and Y from bottom to top text on the back label.
+This operator collects a sequence of oni.Frame objects from each TS3231 receiver that
+are used to determine the ray from each base station to the TS3231's photodiode. A simple geometric
+inversion is performed to determine the photodiodes 3D position from the values P and
+Q. It does not use a predictive model or integrate data from an IMU and is therefore
+quite sensitive to obstructions and will require post-hoc processing to correct systematic errors
+due to optical aberrations and nonlinearities. The the TS4231V1Data operator provides
+access to individual lighthouse signals that is useful for a creating more robust position estimates
+using downstream processing.
+
+
+
+
+
Inputs & Outputs
+
+
Generates a sequence of TS4231V1PositionDataFrame objects, each of which contains
+the 3D position of single photodiode.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Gets or sets the position of the first base station in arbitrary units.
+
The units used will determine the units of Position and
+must match those used in Q. Typically this value is used to define the origin and
+remains at (0, 0, 0).
3D position of a single photodiode within a TS4231 sensor array.
+
A sequence of 12 oni.Frame objects produced by a single TS4231 sensor are required to
+geometrically calculate the position of the sensor's photodiode in 3D space.
Acquisition clock count that is synchronous for all frames collected within an ONI context created using CreateContext.
+The acquisition clock rate is given by AcquisitionClockHz. This clock value provides a common, synchronized
+time base for all data collected with an single ONI context.
Acquisition clock count that is synchronous for all frames collected within an ONI context created using CreateContext.
+The acquisition clock rate is given by AcquisitionClockHz. This clock value provides a common, synchronized
+time base for all data collected with an single ONI context.
Gets or sets the data type used to represent pixel intensity values.
+
The UCLA Miniscope V4 uses a 10-bit image sensor. To capture images that use the full
+ADC resolution, this value can be set to U10.
+This comes at the cost of limited codec support and larger file sizes. If U8 is selected, the two least significant bits of
+each pixel sample will be discarded, which greatly increases codec options and reduces
+file sizes.
The device name provides a unique, human-readable identifier that is used to link software
+elements for configuration, control, and data streaming to hardware. For instance, it can be used
+to link configuration operators to data IO operators within a workflow. This value is
+usually not set manually, but is assigned in a MultiDeviceFactory to correspond to a
+fixed address with a piece of hardware such as a headstage. This address is used for software
+communication.
Device configuration operators belong in a top-level chain of operators between CreateContext and StartAcquisition to configure devices contained by ONIX hardware hubs.
Core operators form a motif that serves as the basis of every workflow that interfaces with ONIX hardware. The motif involves CreateContext and StartAcquisition operators sandwiching one or multiple configuration operators.
Device configuration operators are not recommended for using off-the-shelf Open Ephys hardware. Use aggregate configuration operators instead. Aggregate configuration operators confer the following benefits:
+
+
The address and name properties of aggregate configuration operators undergo automatic configuration which reduces the risk of erroneous configuration.
+
The workflow is less cluttered with configuration operators as one aggregate configuration operator corresponds to multiple device operators. This improves workflow legibility and expedites the workflow scripting process.
+
+
+
Device configuration operators belong in a top-level chain of operators between CreateContext and StartAcquisition to configure devices contained by ONIX hardware hubs.
To begin, the first thing to do is to open up the Bonsai editor. This can be done by starting Bonsai and clicking on the New File button on the left side. Alternatively, if you have previously opened or saved a file in Bonsai, there will be a list of recently opened files on the right side; any of those can be chosen and they will be opened in the editor automatically.
+
+
From the editor, operators can be selected on the left side and placed into the workspace. Before going into details on how to place operators, we will instead go over the different types of operators, some examples of ONIX-specific operators in each category, and some common categories of properties that can be modified across operators.
Welcome to the user guide! The next few pages are dedicated to users who are unfamiliar with ONIX
+and Bonsai, and will teach them what ONIX is, how to download and install Bonsai, open a new file,
+place operators (and understand what an operator is), reorder a workflow, run a workflow, and
+finally visualize data.
+
For those who are already familiar with Bonsai and ONIX and are looking for a particular device or headstage
+to learn about and how to utilize, visit the Hardware Guides.
The CreateContext operator initializes the acquisition context, and it should be the first operator you add to your workflow as it provides access to the hardware device table for all other configuration operators. There are several different ways to find this operator and add it to the workflow:
+
+
From the Bonsai editor, navigate to the toolbox on the left side of the screen and expand the Source section. Next, expand the OpenEphys.Onix1 section, and find the CreateContext line. The operator can then be added by either double-clicking it, or dragging and dropping the operator into the workflow.
+
+
+
Click on the textbox at the top of the toolbox on the left, or from Ctrl + E to focus on the textbox, and type CreateContext to search for the operator. Same as (1), the operator can be placed by double-clicking or dragging and dropping; additionally, if the CreateContext string is highlighted Enter can be pressed to place the operator immediately.
+
+
+
Hover over the image of the CreateContext workflow below, and click on the clipboard icon in the top-right corner of the workflow image to copy the workflow to the clipboard. Navigate back to Bonsai, and paste the copied workflow into the active editor. Pasting can be done via Ctrl + V, or right-clicking in the editor and choosing Paste.
+
+
+
CreateContext Workflow
+
This is a nominally functional workflow that provides access to the ONI context, from which all operators can then be linked to and configured, while also demonstrating how a Breakout Board can be configured before finishing the configuration chain by placing a StartAcquisition operator:
To download Bonsai, select between the portable download and the installer download here.
+
+
The Portable download (.zip) installs a sandboxed version of Bonsai. Portable environments enable users to switch between different environments to prevent package conflicts or confusion between similar packages.
+
+
To install from the Portable download, extract the downloaded file. You can start the portable Bonsai by running the Bonsai.exe that is inside the extracted folder.
+
+
+
The Installer download (.exe) installs Bonsai and all its dependencies globally.
+
+
To install from the Installer download, run the downloaded Bonsai-X.X.X.exe file and agree to the involved licenses. You can start the globally installed Bonsai by launching it from the Bonsai Setup window after installing or searching for it in your OS's search function, for example.
+
+
+
+
+
Tip
+
When using multiple environments, create and name shortcuts such that different Bonsai environments are easier to find and distinguish.
+
+
Open Bonsai Package Manager
+
The Bonsai package manager can be accessed from Bonsai's landing window or its workflow editor:
+
or
+
Install Packages in Bonsai
+
The following packages required to run the workflows in this documentation are:
+
+
Bonsai.StarterPack: the "standard library" for Bonsai that contains tools that are used in almost every workflow.
+
OpenEphys.Commutator: Bonsai package for controlling Open Ephys commutators.
+
OpenEphys.Onix1.Design: An extension of the OpenEphys.Onix1 library that includes graphical user interfaces (GUIs).
It is good practice to periodically check for package updates. To do this, open the package manager and:
+
+
Click the Update tab.
+
Set Package source to All.
+
Leave the search bar blank if you want to check for updates for all packages.
+Alternatively, if you want to check for an update for a particular package, you may type that package's name in the search bar to expedite the update retrieval process.
+
Click Update All if you want to perform all available updates.
+Alternatively, click on a package and click Update if you want to perform a subset of the available updates.
Leave the search bar blank if you want to see all installed packages.
+Alternatively, if you want to uninstall a particular package, you may type that package's name in the search bar.
+
Click a package and click Uninstall to uninstall a packages.
+
+
+
Next Steps
+
Now that Bonsai has been installed and configured, it is time to start constructing a workflow to capture data from your ONIX system. The following sections give a high-level understanding of how Bonsai is organized, and some of the ONIX-specific concepts that will be useful for learning how to work with the operators. If you are familiar with Bonsai, you might want to skip to the Tutorials section.
Continue browsing Getting Started and check out specific operators on the left to see how to configure each operator, as well as some ways to visualize data. Each page will have a fully functional workflow that can be copied into Bonsai to provide an easy starting point for generating data.
+
For more technical information on each operator, head to the OpenEphys.Onix1 to see a more developer-focused view of each operator.
+
More complex and in-depth tutorials for placing multiple operators and moving towards generating data in an experimental setting can be found in the Tutorials.
In Bonsai, a "workflow" is composed of "operators" that are connected together to form a data processing graph. Each operator is classified into as a Source, Transform, Condition, Sink, or Combinator based upon how it behaves. ONIX operators fall in the following categories:
There are specific categories of properties that define when an operator's properties can be modified.
+
Configuration properties only have effect when a workflow is started and are used to initialize the hardware state. If they are changed while a workflow is running they will have no effect.
+
Acquisition properties can be manipulated when the workflow is running and will have an immediate effect on hardware. For instance stimulus waveform parameters can be modified in real-time and sent to the device multiple times while the workflow is running to shape stimulation patterns.
Once all operators have been placed and linked correctly, and all Configuration properties have been set, it is now possible to run a workflow. Note that some aspects of Bonsai are only available in specific contexts; for instance, the GUIs mentioned above can only be opened when a workflow is not running. Once a workflow is running, these GUIs are not accessible, but visualizers for certain operators can be opened to view the streaming data.
+
Running a workflow can be done in one of two ways: (1) Press the Start button at the top of the Bonsai editor, and (2) Press F5. Upon starting a workflow, a context will be created, and all devices will be configured based on the Configuration properties. Any *Data operators will then begin streaming data, and can be visualized.
When running a workflow in Bonsai, operators are evaluated from left to right, and top to bottom. In a workflow, each node represents an operator defining an sequence of values. Nodes can be connected to other nodes, from left to right. Each connection indicates that the downstream operator on the right subscribes, or "listens", to the notifications of the upstream operator on the left. The table below provides some useful information to effectively use the workflow editor. It provides information on how to add connections between operators, remove connections, reordering operators horizontally and vertically, as well as some shortcuts to aid in placing operators more efficiently.
+
Aside from determining the order of execution, the order of operators within a workflow determines which editing actions can be taken. In the table below, the "first" operator is always the one that is on the left side, or on the bottom for multiple rows of operators. If the first operator clicked is on the right side, or on the top, these actions will not work.
+
+
+
+
Goal
+
Clicks / Keystrokes
+
Description
+
+
+
+
+
Connect two operators
+
Click and hold the first operator, drag the cursor to the second operator, and release
+
While dragging the cursor, it will temporarily change to a red symbol until there is a valid target (e.g., the second operator), where it will change to an up arrow
+
+
+
Connect two operators
+
Right-click the first operator, and select Create Connection. Select the second operator
+
While moving the cursor, it will change to an up arrow. A valid operator target will change color when hovering over it
+
+
+
Connect two operators on placement
+
Click on an operator in the editor to select it, then place an operator using either method (1) or (2) above
+
If an operator is currently selected in the editor when a new operator is added, whether it is added by clicking and dragging, double-clicking, or pressing Enter, the newly placed operator will be connected to the first operator automatically
+
+
+
Disconnect two operators
+
Click the first operator to select it, hold Shift, click and hold the first operator, drag to the second operator, and release
+
While dragging the cursor, it will temporarily change to a red symbol until there is a valid target (e.g., the second operator), where it will change to an up arrow
+
+
+
Disconnect two operators
+
Right-click the first operator, and select Remove Connection. Select the second operator
+
While moving the cursor, it will change to an up arrow. A valid operator target will change color when hovering over it
+
+
+
Move row of operators up
+
Hold Alt, click and hold the first operator, drag upwards to an operator in another row, and release
+
This action does not require that the operator be selected prior to performing the action. The second operator that is highlighted when the button / mouse are released will now be under the first operator
+
+
+
Change order of operators in a row
+
Hold Ctrl, click and hold the first operator, drag to the right to the second operator, and release
+
This action does not require that the operator be selected prior to performing the action. This can change the order of any two operators that are a part of the same row; it is not constrained to adjacent operators. Note that if the new placement of the operators is not valid (such as giving a Source operator an input), it will knock the operator of the current row and remove any connections
+
+
+
+
+
Note
+
In the context of OpenEphys.Onix1, all workflows start with (top line) a CreateContext operator connected to an arbitrary number of Configure* operators, finished with a StartAcquisition operator. Subsequent rows will contain the corresponding *Data operators for capturing data from the hardware has been configured above.
+
+
+
Accessing GUIs
+
Some operators, specifically many of the Configure* operators, can have a GUI attached to the operator that allows for easy manipulation of Configuration properties in a graphical environment. These GUIs can be accessed by double-clicking on an operator; if there is a GUI assigned to it, then it will be opened up in a new window. Please note that not all operators have GUIs, but if you think that an operator would benefit from having this functionality added please reach out to us.
+
+
Note
+
GUIs are not part of the base OpenEphys.Onix1 library. To take advantage of this added functionality, you must install the accompanying OpenEphys.Onix1.Design library using the Bonsai package manager.
+
+
A number of Bonsai operators also come with GUIs, but similar to OpenEphys.Onix1, the corresponding *.Design library must be installed before it can be leveraged.
To visualize data from any *Data operator, typically the variable that needs to be visualized must first be output from the operator. To do this, right-click on any *Data operator and select the first option; this will be something similar to Output (OpenEphys.Onix1.*DataFrame). From the drop-down list, select the corresponding data variable to be visualized. Doing so will create a new operator in the workflow.
+
Select this new operator and right-click it, search for the Select Visualizer option and choose a visualizer from that drop-down menu. Note that some data types will require a secondary operator to be connected directly after it, such as a RollingGraph operator. If so, this secondary operator must be right-clicked and the appropriate visualizer must be selected here.
+
+
Note
+
Some visualizers come as Bonsai operators and can be found in the Bonsai.Design.Visualizers package, which can be installed in the Bonsai package manager. These operators must be placed in the workflow and be linked to a data operator to visualize the data properly.
The following excerpt from the Breakout Board example workflow demonstrates analog
+IO functionality by computing a ~1Hz sawtooth pattern, outputting it to the analog IO port, and
+reading it back from the analog IO port. It also saves analog input data.
+
+
+
Analog outputs
+
+
+
The RampGenerator operator generates a sequence of single precision floating point values which
+comprises ~1Hz sawtooth waveform from -10 to 10. The AnalogOutput updates the
+analog output port upon receiving a value in the upstream sequence. In the Breakout Board example
+workflow:
+
+
The AnalogOutput's DeviceName property is set to "BreakoutBoard/AnalogIO". This links the
+AnalogOutput operator to the corresponding configuration operator.
+
The AnalogOutput's DataType property is set to "Volts". The RampGenerator operator computes
+a sawtooth pattern that consists floats in units of volts, so AnalogOutput must be set
+to "Volts" to accept this input. Of course, the RampGenerator could be used to produce a
+sequence of signed 16-bit DAC codes. In that case, DataType property would be set to "S16".
+
+
Although a voltage ramp is sent to all the channels, only channel 0 was selected to be a output, so
+this is the only channel that will be affected. If other channels are configured as output (see
+Breakout Board Configuration), they will also ramp their voltage. The RampGenerator is a
+GroupWorkflow that contains multiple
+Bonsai operators. Examine RampGenerator's internals by pressing Ctrl + Enter
+when the node is selected:
+
+
+
+
Tip
+
To understand how the RampGenerator works, double click each
+nodes in the workflow while its running to visualize how data is transformed
+as it flows through each operator. Additionally, the F1 key can be
+pressed while a node is selected ot bring up its documentation.
+
+
+
Analog inputs
+
Analog input data is recorded from all analog IO channels, regardless of each channels'
+AnalogIO setting. Because analog inputs and outputs share pins on the breakout board,
+this enables a loopback of signals from the analog output through the analog input so that a copy of
+the output signal being sent to external hardware can be saved automatically. The example workflow
+does exactly this on analog IO channel 0.
The AnalogInput's DeviceName is set to "BreakoutBoard/AnalogIO". This links the AnalogInput
+operator to the corresponding configuration operator.
+
The AnalogInput's BufferSize is set to 50. Therefore, each frame will contain a 50-element
+Clock vector and a 12-channel x 50-sample AnalogData matrix. The analog inputs are sampled at
+100 kHz per channel so this corresponds to 500 µs of data. That's lower than the minimal latency
+introduced by the BlockReadSize setting. Therefore, the chosen value for BufferSize will not
+impose a significant effect on processing latency. The buffer will be filled essentially every
+time hardware is accessed and propagated instantly.
+
The AnalogInput's DataType is set to Volts. This means that samples will be represented as
+units of units of voltage in a single-precision floating point type.
+
+
The MemberSelector
+operators each select a member from the AnalogInputDataFrame, Clock and AnalogData which
+contain the AcquisitionClockHz-based sample times and sample
+values, respectively. The
+MatrixWriter operators saves the
+selected members to files with the following format: analog-clock_<timestamp>.raw and
+analog-data_<timestamp>.raw, respectively.
+
+
Tip
+
The easiest way to add a
+MemberSelector to
+the output of an operator is to right-click the node and hover over Output in the resulting
+context menu to examine the output type. A MemberSelector can be added by
+left-clicking the desired expanded property of the Output type.
The output clock is useful for driving external hardware in sync with data
+acquisition (e.g. a camera that accepts a "TTL" input to trigger
+exposure). The output clock has the following physical properties:
+
+
Real-time clock gate
+
Frequency range: 0.1 Hz to 10 MHz
+
Start delay: 0 to 3600 seconds
+
Duty Cycle: 10 - 90%
+
Output impedance: 50 Ohms
+
Output current drive: 64mA
+
+
+
Tip
+
For performance at high frequencies (above ~100 kHz), a 50-Ohm coaxial cable
+should be used it the signal should be terminated into 50-Ohms to prevent
+reflections. The high output current drive makes this clock capable of driving
+long cables.
+
+
These can all be configured using the ConfigureBreakoutBoard operator.
+In the example workflow, the output clock is configured to produce a 1 MHz, 50%
+duty cycle clock whose start time, phase, and frequency is hardware synchronized
+with with the ONIX Acquisition
+Clock.
+
Because the clock is generated using a simple frequency divider, not all
+configuration settings can be exactly realized in hardware. For this reason, the
+following excerpt from the breakout board example
+workflow demonstrates how to save the
+hardware-realized clock parameters
+to a csv file.
+ To learn more about the top-level configuration motif in every workflow involving
+ ONIX hardware, visit the Configuration Chain
+ Tutorial.
+
+
+
+
Creating an Acquisition Context
+
+
+ The CreateContext operator
+ creates a ContextTask that
+ defines the device driver and index where the hardware exists. The
+ Driver property is set to "riffa", which is the name of the PCIe device used by ONIX.
+ In this case, the Index property is set to 0 because there is only a single ONIX system.
+ If a second system is used on the same computer, a second CreateContext operator
+ would be required in its own configuration chain, with its Index property set to 1.
+
+
+
Configuring the Breakout Board
+
The ConfigureBreakoutBoard operator groups the properties
+for all the devices that the breakout board supports. Each device in the
+property pane can be expanded to expose individual properties that govern their
+behavior.
+
+
Tip
+
The Properties section of the ConfigureBreakoutBoard
+operator provides documentation on the effect of all of the breakout board's
+configuration settings.
+
+
To examine and edit the breakout board's properties, click on the Breakout Board node to select it. The properties pane will appear immediately right of
+the workflow editor. Expanding each of the devices within the properties pane
+provides access to their configuration settings. The following video
+demonstrates how properties were edited for the example workflow:
+
+
Namely, the following properties were changed form their default values in the
+breakout board example workflow:
+
+
The BreakoutBoard's AnalogIO Direction0 property is set to Output.
+
The BreakoutBoard's MemoryMonitor Enable property is set to True.
+
The BreakoutBoard's OutputClock Gate property is set to True.
+
+
When the workflow is started, the current time (based on
+Coordinated Universal Time)
+is saved, along with global hardware parameters governing data acquisition. This is
+accomplished using a TimeStamp operator
+to capture the computer's wall clock time. This
+Timestamp is saved along with ContextTask's properties (e.g.,
+AcquisitionClockHz, BlockReadSize, BlockWriteSize) to a csv
+file (start-time_<timestamp>.csv) when the the workflow is started.
+
+
+
Starting Acquisition
+
+
+ After starting a workflow, the StartAcquisition
+ operator begins data acquisition with the hardware that has been configured. In the Breakout Board
+ example workflow, data is collected from the Breakout Board only, so the rate of data being
+ produced by the hardware will be ~2.5 MB/s. The StartAcquisition's ReadSize property is set to
+ 2048 bytes, meaning data collection will wait until
+ 2048 bytes of data have been produced by the hardware. At 2.5 MB/s the
+ hardware will produce 2048 bytes every ~800 μs. This is a hard
+ bound on the latency of the system. If lower latencies were required, the hardware would need to
+ produce data more quickly or the ReadSize would need to be reduced.
+
+
+
The StartAcquisition's WriteSize property is set to 2048 bytes. This
+ determines the amount of memory that is preallocated for temporarily holding data before it is
+ sent to hardware. It is less critical to performance unless the rate that data be written to the
+ hardware is comparable to the rate that the hardware produces data, which is not a common scenario.
+
The following excerpt from the Breakout Board example workflow demonstrates digital inputs functionality by responding to button presses and saves digital inputs data.
+
+
+
The DigitalInput operator generates a sequence of DigitalInputDataFrames. Although the digital inputs are sampled at 4 Mhz, these data frames are only emitted when the port status changes (i.e., when a pin, button, or switch is toggled). The digital input ports on the Breakout Board operate at a 3.3V logic levels but are also 5V tolerant. In the Breakout Board example workflow, the DigitalInput's DeviceName property is set to "BreakoutBoard/DigitalInput". This links the DigitalInput operator to the corresponding configuration operator.
+
The CsvWriter operator writes the Clock, DigitalInputs, and Buttons members from the DigitalInputDataFrame to a file with the following name format: digital-input_<timestamp>.csv. Because CsvWriter is a sink operator, its output sequence is equivalent to its input sequence. In other words, its output is equivalent to DigitalInput's output. Therefore, it's possible to use MemberSelector operators on the CsvWriter to select members from DigitalInputDataFrame. This is most easily performed by clicking the relevant members that appear by hovering over the "Output" option that appears in the context menu that appears after right-clicking the CsvWriter node. The members selected in the workflow, DigitalPortState and BreakoutButtonState, are enumerators with values that correspond to bit positions of the breakout board's digital ports. When DigitalPortState or OpenEphys.Onix1.BreakoutButtonState is connected to a HasFlags operator, the names that appear in the HasFlags's Value property's dropdown menu correspond to bit positions in the respective digital input port. In this workflow, the top HasFlags operator checks if Triangle or X are True.
The following excerpt from the breakout board example workflow
+demonstrates digital outputs functionality by computing a ~10Hz binary digital counter and
+outputting that counter to the digital output port.
+
+
+
The Timer operator generates a sequence
+of 64-bit signed integers
+in ~100ms intervals. The Int
+operator emits an integer (with a value of 1 in our case) when an item is received from the upstream
+sequence. The Accumulate operator
+increments a value by the values of items in its upstream sequence. The Accumulate operator emits
+this value when an item is received from the upstream sequence.
+
The DigitalOutput operator updates the digital output part when sends data in
+the sequence computed by the upstream operators to update the digital output port. The digital
+outputs are updated when an item is received from the upstream sequence. Although Accumulate
+produces a 32-bit integer that counts from 0 to 2147483647, the DigitalOutput operator only uses
+the lower 8-bits to update the digital output state. In the Breakout Board example workflow, the
+DigitalOutput's DeviceName property to "BreakoutBoard/DigitalOutput". This links the
+DigitalOutput operator to the corresponding configuration operator.
Harp is a standard for asynchronous real-time data
+acquisition and experimental control in neuroscience. It includes a clock
+synchronization protocol which allows Harp devices to be connected to a shared
+clock line and continuously self-synchronize their clocks to a precision of tens
+of microseconds. The Harp clock signal is transmitted over a serial line every
+second. Every time the Harp sync input device in the ONIX breakout board detects
+a full Harp synchronization packet, a new data frame is emitted pairing the
+current value of the Harp clock with the local ONIX acquisition clock.
+
Harp is typically used in behavioral equipment such as audio generation devices,
+nose-poke loggers, servos, rotary encoders and cameras. The breakout board's
+harp input allows complete, hardware level synchronization of the Harp and Onix
+ecosystems. This means that all experimental events are timestamped on the same
+clock and no post-hoc alignment of timing is necessary.
+
The following excerpt from the Breakout Board example
+workflow demonstrates saving data from the Harp input
+port on the breakout board.
The following excerpt from the Breakout Board example workflow
+demonstrates heartbeat functionality.
+
+
+
The HeartbeatData operator generates a sequence of
+HeartbeatDataFrames. HeartbeatData emits HeartbeatDataFrames at a regular
+interval defined during Breakout Board Configuration using the
+ConfigureBreakoutBoard's Heartbeat BeatsPerSecond property (in our case 10
+Hz). In the Breakout Board example workflow, the HeartbeatData's DeviceName property is set to
+"BreakoutBoard/Heartbeat". This links the HeartbeatData operator to the corresponding
+configuration operator. The
+MemberSelector
+operator selects the Clock member from the HeartbeatDataFrame so the user can visualize Clock
+data from the HeartbeatDataFrame.
The following excerpt from the Breakout Board example workflow demonstrates memory monitor functionality and saves memory monitor data.
+
+
+
The MemoryMonitorData operator generates a sequence of MemoryMonitorDataFrames. MemoryMonitorData emits MemoryMonitorDataFrames at a regular interval defined during Breakout Board Configuration using the ConfigureBreakoutBoard's MemoryMonitor SamplesPerSecond property (in our case 10 Hz). In the Breakout Board example workflow, the MemoryMonitorData's DeviceName property is set to "BreakoutBoard/MemoryMonitor". This links the MemoryMonitorData operator to the corresponding configuration operator. The CsvWriter operator saves the Clock, BytesUsed, and PercentUsed members to a file with the following format: memory-use_<timestamp>.csv. Because CsvWriter is a sink operator, its output sequence is equivalent to its input sequence. In other words, its output is equivalent to MemoryMonitorData's output. Therefore, it's possible to use a MemberSelector operator on the CsvWriter to select members from the MemoryMonitorDataFrame. The MemberSelector operator selects the PercentUsed member from the MemoryMonitorDataFrame so the user can visualize PercentUsed data from the MemoryMonitorDataFrame.
+
+
Note
+
The MemoryMonitorDataFrame operator generates a
+data stream that is most useful in the context of closed-loop performance. It tells the user if data
+is being consumed rapidly enough by the host PC to keep up with data production by the hardware. The
+hardware FIFO is a buffer that is required to deal with the fact that computers with normal
+operating systems cannot perform operations with strict regularity. When there are hiccups in
+acquisition, the hardware FIFO picks up the slack, but should then be cleared immediately. To get
+the lowest latencies, the BlockReadSize should be as small as possible while the memory use
+percentage remains around 0%.
+
+
+
Warning
+
If the hardware FIFO's PercentUsed is non-zero for long time periods, or is increasing, the
+StartAcquisition's BlockReadSize setting is too small (see the breakout board configuration). A small
+BlockReadSize will mean that the host computer does not have to wait long for enough data to
+become available to propagate it forward, but will reduce overall bandwidth by increasing the
+frequency at which the host computer checks if data is available and performs hardware reads.
The breakout board acts as the central interface for headstages, miniscopes, and
+auxiliary IO to communicate with the computer. It provides the following
+features:
+
+
Headstage IO: 2x high-bandwidth, general-purpose headstage communication ports
+
Digital Input: 8 bits GPI and button state, 5V tolerant, 4 MHz/channel.
In the following example workflow, we will explore all of the breakout board's
+functionality. The workflow below can by copy/pasted into the Bonsai editor
+using the clipboard icon in the top right. This workflow:
+
+
Captures data from the breakout board's analog and digital inputs and streams them to disk.
+
Generates signals to drive the breakout board'ss analog and digital outputs.
+
Receives synchronization messages from the integrated Harp input.
+
Controls the clock output for driving synchronizing external hardware with data acquisition.
+
Monitors and saves hardware memory buffer use information.
+ The following excerpt from the Headstage 64 example workflow demonstrates Bno055 functionality, saves Bno055 data, and commutates the Headstage 64 if there is a proper commutator connection.
+
+
+
+
+
+
+
+ The Bno055Data operator generates a sequence of Bno055DataFrames. The DeviceName property is set to "Headstage 64/Bno055Data". This links the Bno055Data operator to the corresponding configuration operator.
+
+
+
+ The CsvWriter operator writes the entire Bno055DataFrame to a file with the following format: bno055_<timestamp>.csv. Because CsvWriter is a sink operator, its output sequence is equivalent to its input sequence (i.e., Bno055Data's output). This means that the Quaternion property (originally from Bno055Data) can be selected from the CsvWriter operator by right-clicking the operator and selecting the proper Output property.
+
+
+
+ Quaternion values are passed to the "AutoCommutator" IncludeWorkflow operator, which will automatically commutate the headstage if there is a proper commutator connected. "AutoCommutator" comes from the OpenEphys.Commutator Bonsai package. Its properties allow you to enable/disable the LED on the commutator using the LedEnable property, set the COM port using the PortName property, and set the orientation of the Bno055 orientation sensor using the headstage RotationAxis property. The RotationAxis is already correctly set for the Headstage 64. However, the correct COM port value varies from system to system. You must find and set the correct COM port to which your commutator is connected in your system.
+
+
+
+
NOTE
+
To remove automated commutation, simply delete the last node by selecting it and pressing Delete.
+ To learn more about the top-level configuration motif in every workflow involving
+ ONIX hardware, visit the Configuration Chain
+ Tutorial.
+
+
+
+
Creating an Acquisition Context
+
+
+ The CreateContext operator
+ creates a ContextTask that
+ defines the device driver and index where the hardware exists. The
+ Driver property is set to "riffa", which is the name of the PCIe device used by ONIX.
+ In this case, the Index property is set to 0 because there is only a single ONIX system.
+ If a second system is used on the same computer, a second CreateContext operator
+ would be required in its own configuration chain, with its Index property set to 1.
+
+
+
Configuring the Breakout Board and Headstage64
+
The ConfigureBreakoutBoard operator configures the Onix Breakout Board. In the Headstage64 example tutorial, it is configured to enable digital inputs to serve as a trigger for the Headstage64's electrical and optical stimulation and to enable monitoring of the percentage of memory occupied. This is accomplished by leaving all of the ConfigureBreakoutBoard properties set to their default values except its Memory MonitorEnable property is set to True.
+
The ConfigureHeadstage64 operator is used to configure the Headstage64. In the Headstage64 example tutorial, it is configured to enable streaming of electrophysiology data from a Rhd2164 amplifier, orientation data from the on-board Bno055 IMU, and position data from the Ts4231. This is accomplished in the Headstage64 example workflow by leaving all of the ConfigureHeadstage64 properties set to their default values.
+
When the workflow is started, the current time (based on
+Coordinated Universal Time)
+is saved, along with global hardware parameters governing data acquisition. This is
+accomplished using a TimeStamp operator
+to capture the computer's wall clock time. This
+Timestamp is saved along with ContextTask's properties (e.g.,
+AcquisitionClockHz, BlockReadSize, BlockWriteSize) to a csv
+file (start-time_<timestamp>.csv) when the the workflow is started.
+
+
+
Starting Acquisition
+
+
+ After starting a workflow, the StartAcquisition
+ operator begins data acquisition with the hardware that has been configured. In the Headstage64
+ example workflow, data is collected from the Headstage64 only, so the rate of data being
+ produced by the hardware will be ~4.1 MB/s. The StartAcquisition's ReadSize property is set to
+ 2048 bytes, meaning data collection will wait until
+ 2048 bytes of data have been produced by the hardware. At 4.1 MB/s the
+ hardware will produce 2048 bytes every ~500 μs. This is a hard
+ bound on the latency of the system. If lower latencies were required, the hardware would need to
+ produce data more quickly or the ReadSize would need to be reduced.
+
+
+
The StartAcquisition's WriteSize property is set to 2048 bytes. This
+ determines the amount of memory that is preallocated for temporarily holding data before it is
+ sent to hardware. It is less critical to performance unless the rate that data be written to the
+ hardware is comparable to the rate that the hardware produces data, which is not a common scenario.
+
The following excerpt from the Breakout Board example workflow demonstrates memory monitor functionality and saves memory monitor data.
+
+
+
The MemoryMonitorData operator generates a sequence of MemoryMonitorDataFrames. MemoryMonitorData emits MemoryMonitorDataFrames at a regular interval defined during Breakout Board Configuration using the ConfigureBreakoutBoard's MemoryMonitor SamplesPerSecond property (in our case 10 Hz). In the Breakout Board example workflow, the MemoryMonitorData's DeviceName property is set to "BreakoutBoard/MemoryMonitor". This links the MemoryMonitorData operator to the corresponding configuration operator. The CsvWriter operator saves the Clock, BytesUsed, and PercentUsed members to a file with the following format: memory-use_<timestamp>.csv. Because CsvWriter is a sink operator, its output sequence is equivalent to its input sequence. In other words, its output is equivalent to MemoryMonitorData's output. Therefore, it's possible to use a MemberSelector operator on the CsvWriter to select members from the MemoryMonitorDataFrame. The MemberSelector operator selects the PercentUsed member from the MemoryMonitorDataFrame so the user can visualize PercentUsed data from the MemoryMonitorDataFrame.
+
+
Note
+
The MemoryMonitorDataFrame operator generates a
+data stream that is most useful in the context of closed-loop performance. It tells the user if data
+is being consumed rapidly enough by the host PC to keep up with data production by the hardware. The
+hardware FIFO is a buffer that is required to deal with the fact that computers with normal
+operating systems cannot perform operations with strict regularity. When there are hiccups in
+acquisition, the hardware FIFO picks up the slack, but should then be cleared immediately. To get
+the lowest latencies, the BlockReadSize should be as small as possible while the memory use
+percentage remains around 0%.
+
+
+
Warning
+
If the hardware FIFO's PercentUsed is non-zero for long time periods, or is increasing, the
+StartAcquisition's BlockReadSize setting is too small (see the breakout board configuration). A small
+BlockReadSize will mean that the host computer does not have to wait long for enough data to
+become available to propagate it forward, but will reduce overall bandwidth by increasing the
+frequency at which the host computer checks if data is available and performs hardware reads.
+ The Onix system reports when a headstage port connection enters or leaves an aberrant state. Such aberrant states include loss
+ of communication lock, detection of parity or CRC error, reception of a badly formatted packet, etc.. Knowing the time
+ and type of a communication failure is a good first step to track down its cause. The following excerpt from the
+ Headstage 64 example
+ workflow demonstrates port status functionality and saves timestamped port status data.
+
+
+
+
+
+
+
+ Headstage port status data is produced in Bonsai by the PortStatus operator which generates a sequence of PortStatusFrames. PortStatus emits a
+ PortStatusFrame whenever PortStatusCode changes value. PortStatus's
+ DeviceName property is set to "Headstage64/PortController". This links the
+ PortStatus operator to the breakout board's port controller.
+
+
+
+ The TimeStamp operator
+ generates a sequence of UTC timestamped items from its input sequence. The CsvWriter operator writes Timestamp as
+ well as Clock and StatusCode members from PortStatusFrame to a file with the
+ following name format: port-status_<timestamp>.csv.
+
+
+
+
NOTE
+
The PortStatus datastream is always enabled. ConfigureHeadstage64 has no
+ Enable property for the PortStatus operator like other Data I/O operators that can be used
+ with the Headstage 64.
The following excerpt from the Headstage64 example workflow demonstrates the Rhd2164 functionality by streaming and saving data from the Rhd2164 device.
BufferSize is set to 30. Each Rhd2164DataFrame will contain a [1 x 30 sample] Clock vector, a [64 channel x 30 sample] AmplifierData matrix, and a [3 channel x 30 sample] AuxData matrix. This corresponds to 1.2 ms of data per data frame.
+
The Headstage64Data's DeviceName property is set to "Headstage64/Rhd2164". This links the Rhd2164Data operator to the corresponding configuration operator.
+
+
The relevant properties are extracted from the Rhd2164DataFrame by right-clicking the Rhd2164Data operator, and choosing the following Output members: Clock, AmplifierData, and AuxData. The MatrixWriter operators saves the selected members to files with the following format: rhd2164-clock_<timestamp>.raw, rhd2164-amplifier_<timestamp>.raw, and rhd2164-aux_<timestamp>.raw, respectively.
+ The following excerpt from the NeuropixelsV1e Headstage example workflow demonstrates Bno055 functionality, saves Bno055 data, and commutates the NeuropixelsV1e Headstage if there is a proper commutator connection.
+
+
+
+
+
+
+
+ The PolledBno055Data operator generates a sequence of Bno055DataFrames. The DeviceName property is set to "NeuropixelsV1eHeadstage/PolledBno055Data". This links the PolledBno055Data operator to the corresponding configuration operator.
+
+
+
+ The CsvWriter operator writes the entire Bno055DataFrame to a file with the following format: bno055_<timestamp>.csv. Because CsvWriter is a sink operator, its output sequence is equivalent to its input sequence (i.e., PolledBno055Data's output). This means that the Quaternion property (originally from PolledBno055Data) can be selected from the CsvWriter operator by right-clicking the operator and selecting the proper Output property.
+
+
+
+ Quaternion values are passed to the "AutoCommutator" IncludeWorkflow operator, which will automatically commutate the headstage if there is a proper commutator connected. "AutoCommutator" comes from the OpenEphys.Commutator Bonsai package. Its properties allow you to enable/disable the LED on the commutator using the LedEnable property, set the COM port using the PortName property, and set the orientation of the Bno055 orientation sensor using the headstage RotationAxis property. The RotationAxis is already correctly set for the NeuropixelsV1e Headstage. However, the correct COM port value varies from system to system. You must find and set the correct COM port to which your commutator is connected in your system.
+
+
+
+
NOTE
+
To remove automated commutation, simply delete the last node by selecting it and pressing Delete.
+ To learn more about the top-level configuration motif in every workflow involving
+ ONIX hardware, visit the Configuration Chain
+ Tutorial.
+
+
+
+
Creating an Acquisition Context
+
+
+ The CreateContext operator
+ creates a ContextTask that
+ defines the device driver and index where the hardware exists. The
+ Driver property is set to "riffa", which is the name of the PCIe device used by ONIX.
+ In this case, the Index property is set to 0 because there is only a single ONIX system.
+ If a second system is used on the same computer, a second CreateContext operator
+ would be required in its own configuration chain, with its Index property set to 1.
+
+
+
Configuring the NeuropixelsV1e Headstage
+
The NeuropixelsV1eHeadstage operator is used to configure the Neuropixels V1e Headstage; this can enable streaming of electrophysiology data from a Neuropixels 1.0 probe and orientation data from a Bno055 IMU. This is accomplished in the example workflow by leaving all of the NeuropixelsV1eHeadstage properties set to their default values.
+
Default values for the headstage are:
+
+
Enabling the first 384 electrodes for streaming (electrodes 0 through 383)
+
+
This is also known as the Bank AChannel Preset
+
+
+
Setting AP Gain to 1000x
+
Setting LFP gain to 50x
+
Enabling the Spike Filter
+
Setting the Reference to External
+
+
+
Important
+
The workflow will not run unless gain calibration and ADC calibration files are provided. Click the NeuropixelsV1eHeadstage operator, expand NeuropixelsV1e in the properties pane, then choose the appropriate files by selecting either GainCalibrationFile or AdcCalibrationFile and clicking the ... button.
+
+
+
Tip
+
For additional details on how to manually configure the headstage, such as enabling specific electrodes for recording, or modify AP / LFP gain, check out the NeuropixelsV1e GUI page.
+
+
When the workflow is started, the current time (based on
+Coordinated Universal Time)
+is saved, along with global hardware parameters governing data acquisition. This is
+accomplished using a TimeStamp operator
+to capture the computer's wall clock time. This
+Timestamp is saved along with ContextTask's properties (e.g.,
+AcquisitionClockHz, BlockReadSize, BlockWriteSize) to a csv
+file (start-time_<timestamp>.csv) when the the workflow is started.
+
+
+
Starting Acquisition
+
+
+ After starting a workflow, the StartAcquisition
+ operator begins data acquisition with the hardware that has been configured. In the NeuropixelsV1e Headstage
+ example workflow, data is collected from the NeuropixelsV1e Headstage only, so the rate of data being
+ produced by the hardware will be ~20.6 MB/s. The StartAcquisition's ReadSize property is set to
+ 4096 bytes, meaning data collection will wait until
+ 4096 bytes of data have been produced by the hardware. At 20.6 MB/s the
+ hardware will produce 4096 bytes every ~200 μs. This is a hard
+ bound on the latency of the system. If lower latencies were required, the hardware would need to
+ produce data more quickly or the ReadSize would need to be reduced.
+
+
+
The StartAcquisition's WriteSize property is set to 2048 bytes. This
+ determines the amount of memory that is preallocated for temporarily holding data before it is
+ sent to hardware. It is less critical to performance unless the rate that data be written to the
+ hardware is comparable to the rate that the hardware produces data, which is not a common scenario.
+
The NeuropixelsV1e headstage has a graphical user interface when the OpenEphys.Onix1.Design package is downloaded. For more information on how to install that library, check out the Installation page.
+
Overview
+
For NeuropixelsV1eHeadstage, the GUI allows for an easy way to change settings and visualize the effect. From the GUI, you can:
For NeuropixelsV1e, there will always be 384 channels enabled across the entire probe. Therefore, when enabling electrodes (either manually or using channel presets), some previously enabled electrodes will be disabled. Additionally, if more than 384 electrodes are manually selected to be enabled, only the last 384 channels will end up being enabled. It is therefore recommended to always double-check that the correct electrodes are enabled.
+
As an example, let us assume that electrodes 0 through 383 are initially enabled (this corresponds to 384 channels). Then, electrodes 384 and 385 are enabled. When these electrodes are enabled, electrodes 0 and 1 will be disabled. In this way, there will always be 384 channels enabled.
+
In addition to the absolute number of channels, there are other restrictions in place regarding which combinations of electrodes can be enabled at any given time. Specifically, in the NeuropixelsV1Electrode there is a Channel property which defines the channel index of an electrode. Across the entire probe, no two electrodes that share the same Channel can be simultaneously enabled.
+
Channel presets take this into account automatically and ensure that the rules are followed. When manually enabling electrodes, the indexing logic is applied in the order that electrodes are selected. If two (or more) electrodes are selected that share a Channel value, the highest indexed electrode is the only one that will be enabled.
+
+
Note
+
Due to these constraints, it is possible that a desired combination of electrodes is not feasible.
+
+
Keeping or discarding configuration settings
+
While the GUI is open, any changes to the configuration settings can be freely modified and will not affect the configuration unless Okay is pressed. This includes all aspects of the configuration, such as which electrodes are enabled, the chosen reference channel, and the probe calibration file.
+
+
Note
+
The hardware is not actually configured until the workflow starts.
+
+
If the window is closed any other way (such as by pressing Cancel, or pressing the X to close the window), then any changes made will not be saved.
+
ProbeInterface
+
The NeuropixelsV1eHeadstage GUI uses ProbeInterface as the format to draw the probes and electrodes visually. For more information on ProbeInterface and the resulting JSON file, check out their format specifications page.
+
When opening the GUI, there is a default probe configuration that is loaded and drawn, which can be saved to a JSON file. Conversely, an existing JSON file can be loaded to update the current channel configuration. If for any reason the default configuration is needed, it can be loaded again at any time.
+
Open Headstage Configuration GUI
+
To open the headstage configuration GUI, double-click the ConfigureNeuropixelsV1eHeadstage operator.
+
+
Once opened, if the calibration files have not been selected the window should look like the image below. To view the probe, follow the steps below to choose calibration files.
+
+
Choosing probe calibration files
+
Upon opening the GUI for the first time, if no probe calibration files were set in the Bonsai editor, the window will be mostly blank. To populate the window with a drawing of the probe, both calibration files must be selected. First, click on the ... button to the right of the empty text box under "ADC Calibration File" (see below). This will open a file dialog, where the ADC calibration file can be searched for and selected. Once the file is selected, press Open or Enter. This will populate the text box with the filepath to the calibration file.
+
+
+
+
This process is then repeated for the gain calibration file; click on the ... button to the right of the empty text box under Gain Calibration File (see below). This will open a file dialog, where the gain calibration file can be searched for and selected.
+
+
+
+
+
Note
+
Files are expected to be named XXXXXXXXXXX_ADCCalibration.csv and XXXXXXXXXXX_gainCalValues.csv, where "XXXXXXXXXXX" is the probe serial number.
+
+
Once both files are selected, this will enable visualization of the electrodes. Below is a view of the configuration GUI that has been opened after both calibration files have been selected.
+
+
Status strip
+
Towards the bottom of the GUI, there is a status strip that reports the serial number found in the selected calibration files. Next to the reported serial numbers is a status symbol indicating if there any potential issues. Below is a list of possible states the status strip will display:
+
+
+
+
Symbol
+
Reason
+
+
+
+
+
+
One or no files are selected
+
+
+
+
One or more files are invalid
+
+
+
+
Different serial numbers reported
+
+
+
+
Files are valid, and serial numbers match
+
+
+
+
View ADC correction values
+
Once a valid ADC calibration file has been selected, the View ADC Correction Values button will be enabled. This button can be pressed to open a new dialog that displays the correction values for all ADCs. Refer to NeuropixelsV1Adc for more details on the specific calibration values.
+
+
Selecting AP gain
+
The gain for the AP-band can be selected from the dropdown menu next to AP Gain. For a list of possible gain values, check out NeuropixelsV1Gain. If a gain calibration file has been selected and is valid, the gain correction that will be applied is displayed in the textbox underneath the dropdown menu and is updated based on the current gain selected.
+
+
+
+
Selecting LFP gain
+
The gain for the LFP-band can be selected from the dropdown menu next to LFP Gain. For a list of possible gain values, check out NeuropixelsV1Gain. If a gain calibration file has been selected and is valid, the gain correction that will be applied is displayed in the textbox underneath the dropdown menu and is updated based on the current gain selected.
+
+
+
+
Enabling spike filter
+
A checkbox allows enabling or disabling of the spike-band filter. If enabled, the spike-band has a 300 Hz high-pass filter which will be activated. If set to false, the high-pass filter will not to be activated.
+
+
+
+
Selecting channel reference
+
Underneath the probe calibration filepath, there is a dropdown menu for choosing the reference for all channels. For possible values and a brief description of what they correspond to, check out the references page.
+
+
+
+
Channel presets
+
To save time, it is possible to select a preset channel combination from the Channel Presets dropdown. These presets are defined to work within the constraints of NeuropixelsV1e channel combinations defined above.
Enables all even electrodes on Bank A, then all odd electrodes on Bank B
+
+
+
Tetrodes
+
+
Enables the first group of four electrodes for every eight electrodes (electrodes 0-3 but not 4-7) in Bank A, then enables the second group of four for every eight electrodes in Bank B (388-391, but not 384-387).
+
+
+
+
If electrodes are manually enabled, the Channel Presets dropdown will change to None, indicating that a channel preset is no longer selected.
+
Maneuvering along the probe
+
Once a GUI has been opened and a probe calibration file has been selected, the main panel on the left will be populated with a NeuropixelsV1e probe. Below are the buttons used to navigate within this panel to view and choose electrodes.
+
+
Mouse Controls
+
+
Mouse wheel zooms in/out towards the cursor
+
Left-click and drag will select electrodes within the drawn rectangle
+
Left-click on an electrode will select that electrode
+
Left-click in empty space will clear the selected electrodes
+
Middle-click and drag will pan the electrodes
+
+
+
Scroll bar
+
+
On the right side of the main panel there is a scroll bar that can be used to move the probe up and down
+
Panning the probe up or down will update the scroll bar once the movement has completed
+
The scroll bar can be moved by:
+
+
Grabbing the marker using the mouse and dragging it up or down
+
Placing the cursor either above or below the marker and clicking
+
Using the mouse wheel to scroll up or down while the cursor is over the scroll bar
+
+
+
+
+
+
Zoom and pan limits
+
When zooming in and out, note that there are limits in both directions. The probe can only be zoomed out to the point that the entire probe is visible within the panel and no more. Similarly, while zooming in the probe will not zoom in past a certain point.
+
In addition to the absolute zoom limits, the panel will automatically shift the probe to ensure it is always in view. This is handled each time the probe is zoomed or panned.
+
To reset the view at any time, click on the Reset Zoom button to fully zoom out the panel.
+
Manually enabling electrodes
+
Electrodes can be selected at any zoom level, but it is often preferable to zoom in to read the electrode indices. Consider maximizing the window to see those numbers more easily.
+
To select, as described above, either click-and-drag the cursor over the desired electrodes, or select individual electrodes by clicking on them one-by-one. Once the electrodes to enable are selected, click on the Enable Selected Electrodes button in the right panel. At this point the selected electrodes should turn blue, indicating that they are now enabled. It is important to note that when electrodes are enabled, a number of previously enabled electrodes will be disabled due to channel constraints. For more information, read the Channel constraints section above.
+
The short video below shows how to select, clear selection, enable selected electrodes, and translate using the scroll bar. Note that once electrodes are manually enabled, the Channel Presets drop-down changes from BankA to None. Then, once the selected electrodes match the preset, it is automatically changed back to BankA.
+
+
+
+
Loading and saving channel configurations
+
When the GUI is first opened and after a probe calibration file has been specified, the default ProbeInterface configuration is loaded and drawn in the main panel. In this case, the default configuration is for a single-shank NeuropixelsV1e probe, with the BankA channel preset selected. To load a new configuration, load the default configuration, or save the current configuration, go to the File drop-down menu (see below) and choose the relevant option.
+
+
+
+
Save ProbeInterface file
+
To save a ProbeInterface JSON file fully describing the probe, including which electrodes are currently enabled, go to the File drop-down menu, and select NeuropixelsV1e → Save Channel Configuration. This will open a file dialog window to save the new JSON file. Choose a folder location and a name for the file, then hit Save. This will export the current channel configuration. This is a useful way to save any manually enabled electrodes as a backup, or to easily switch between different configurations between recordings.
+
Load ProbeInterface file
+
To load a ProbeInterface JSON file, navigate to the File drop-down menu and select NeuropixelsV1e → Load Channel Configuration. This will open a file dialog window; browse to the existing JSON file, select it and press Open to load the channel configuration. The new probe shape will be loaded and drawn, with the enabled electrodes highlighted as usual.
+
+
Note
+
When loading a new configuration, the total number of electrodes must match the existing configuration, and the number of enabled electrodes must match.
+
+
Load default configuration
+
To load the default channel configuration at any time, navigate to the File drop-down menu and choose NeuropixelsV1e → Load Default Channel Configuration. This will load the default configuration, with the BankA channel preset selected.
+
Configure Bno055
+
At the headstage level, there is another device tab listed for a Bno055. From this tab, the device can be enabled or disabled by selecting the appropriate value from the drop-down menu next to Enable. While other properties are displayed here, they have no affect on the underlying device configuration; only changes to the Enable property will be respected.
The NeuropixelsV1eData's DeviceName property is set to "NeuropixelsV1eHeadstage/NeuropixelsV1e". This links the NeuropixelsV1eData operator to the corresponding configuration operator.
+
+
Given the settings above, each frame will contain a [1 x 36 sample] Clock vector, a [384 channel x
+36 sample] SpikeData matrix, and a [384 channel x 3 sample] LfpData matrix. This corresponds to 1.2 ms of data per data frame.
+LfpData has less samples than Clock and SpikeData because LfpData is sampled at a lower rate; AP data is sampled at 30 kHz while LFP data is sampled at 2.5 kHz.
+
The relevant properties are extracted from the NeuropixelsV1DataFrame by right-clicking the NeuropixelsV1eData operator, and choosing the following Output members: Clock, SpikeData, and LfpData. The MatrixWriter operators saves the selected members to files with the following format: np1-clock_<timestamp>.raw, np1-spike_<timestamp>.raw, and np1-lfp_<timestamp>.raw, respectively.
+ The Onix system reports when a headstage port connection enters or leaves an aberrant state. Such aberrant states include loss
+ of communication lock, detection of parity or CRC error, reception of a badly formatted packet, etc.. Knowing the time
+ and type of a communication failure is a good first step to track down its cause. The following excerpt from the
+ NeuropixelsV1e Headstage example
+ workflow demonstrates port status functionality and saves timestamped port status data.
+
+
+
+
+
+
+
+ Headstage port status data is produced in Bonsai by the PortStatus operator which generates a sequence of PortStatusFrames. PortStatus emits a
+ PortStatusFrame whenever PortStatusCode changes value. PortStatus's
+ DeviceName property is set to "NeuropixelsV1eHeadstage/PortController". This links the
+ PortStatus operator to the breakout board's port controller.
+
+
+
+ The TimeStamp operator
+ generates a sequence of UTC timestamped items from its input sequence. The CsvWriter operator writes Timestamp as
+ well as Clock and StatusCode members from PortStatusFrame to a file with the
+ following name format: port-status_<timestamp>.csv.
+
+
+
+
NOTE
+
The PortStatus datastream is always enabled. ConfigureNeuropixelsV1eHeadstage has no
+ Enable property for the PortStatus operator like other Data I/O operators that can be used
+ with the NeuropixelsV1e Headstage.
+ The following excerpt from the NeuropixelsV2e Headstage example workflow demonstrates Bno055 functionality, saves Bno055 data, and commutates the NeuropixelsV2e Headstage if there is a proper commutator connection.
+
+
+
+
+
+
+
+ The PolledBno055Data operator generates a sequence of Bno055DataFrames. The DeviceName property is set to "NeuropixelsV2eHeadstage/PolledBno055Data". This links the PolledBno055Data operator to the corresponding configuration operator.
+
+
+
+ The CsvWriter operator writes the entire Bno055DataFrame to a file with the following format: bno055_<timestamp>.csv. Because CsvWriter is a sink operator, its output sequence is equivalent to its input sequence (i.e., PolledBno055Data's output). This means that the Quaternion property (originally from PolledBno055Data) can be selected from the CsvWriter operator by right-clicking the operator and selecting the proper Output property.
+
+
+
+ Quaternion values are passed to the "AutoCommutator" IncludeWorkflow operator, which will automatically commutate the headstage if there is a proper commutator connected. "AutoCommutator" comes from the OpenEphys.Commutator Bonsai package. Its properties allow you to enable/disable the LED on the commutator using the LedEnable property, set the COM port using the PortName property, and set the orientation of the Bno055 orientation sensor using the headstage RotationAxis property. The RotationAxis is already correctly set for the NeuropixelsV2e Headstage. However, the correct COM port value varies from system to system. You must find and set the correct COM port to which your commutator is connected in your system.
+
+
+
+
NOTE
+
To remove automated commutation, simply delete the last node by selecting it and pressing Delete.
+ To learn more about the top-level configuration motif in every workflow involving
+ ONIX hardware, visit the Configuration Chain
+ Tutorial.
+
+
+
+
Creating an Acquisition Context
+
+
+ The CreateContext operator
+ creates a ContextTask that
+ defines the device driver and index where the hardware exists. The
+ Driver property is set to "riffa", which is the name of the PCIe device used by ONIX.
+ In this case, the Index property is set to 0 because there is only a single ONIX system.
+ If a second system is used on the same computer, a second CreateContext operator
+ would be required in its own configuration chain, with its Index property set to 1.
+
+
+
+
+
Note
+
The NeuropixelsV2eBeta Headstage functions nearly identically to the NeuropixelsV2e Headstage. Simply replace ConfigureNeuropixelsV2eHeadstage with ConfigureNeuropixelsV2eBetaHeadstage.
+
+
Configuring the NeuropixelsV2e headstage
+
The NeuropixelsV2eHeadstage operator is set to configure the NeuropixelsV2e Headstage; this can enable streaming of electrophysiology data from a Neuropixels 2.0 probe and orientation data from a Bno055 IMU. This is accomplished in the NeuropixelsV2e Headstage example workflow by leaving all of the NeuropixelsV2eHeadstage properties set to their default values.
+
Default values for the headstage are:
+
+
Enabling the first 384 electrodes of the first shank for streaming (shank 0, electrodes 0 through 383)
+
+
This is also known as the Shank 0 Bank AChannel Preset
+
+
+
Setting the Reference to External
+
+
+
Important
+
The workflow will not run unless gain correction files are provided. Click the NeuropixelsV2eHeadstage operator, expand NeuropixelsV2e in the property pane, then choose the appropriate files by selecting either GainCalibrationFileA or GainCalibrationFileB and clicking the ... button. If only one probe is plugged in, only one file is required.
+
+
+
Tip
+
For additional details on how to manually configure the headstage, such as enabling specific electrodes for recording, or modify AP / LFP gain, check out the NeuropixelsV2e GUI page.
+
+
When the workflow is started, the current time (based on
+Coordinated Universal Time)
+is saved, along with global hardware parameters governing data acquisition. This is
+accomplished using a TimeStamp operator
+to capture the computer's wall clock time. This
+Timestamp is saved along with ContextTask's properties (e.g.,
+AcquisitionClockHz, BlockReadSize, BlockWriteSize) to a csv
+file (start-time_<timestamp>.csv) when the the workflow is started.
+
+
+
Starting Acquisition
+
+
+ After starting a workflow, the StartAcquisition
+ operator begins data acquisition with the hardware that has been configured. In the NeuropixelsV2e Headstage
+ example workflow, data is collected from the NeuropixelsV2e Headstage only, so the rate of data being
+ produced by the hardware will be ~18.1 MB/s. The StartAcquisition's ReadSize property is set to
+ 4096 bytes, meaning data collection will wait until
+ 4096 bytes of data have been produced by the hardware. At 18.1 MB/s the
+ hardware will produce 4096 bytes every ~220 μs. This is a hard
+ bound on the latency of the system. If lower latencies were required, the hardware would need to
+ produce data more quickly or the ReadSize would need to be reduced.
+
+
+
The StartAcquisition's WriteSize property is set to 2048 bytes. This
+ determines the amount of memory that is preallocated for temporarily holding data before it is
+ sent to hardware. It is less critical to performance unless the rate that data be written to the
+ hardware is comparable to the rate that the hardware produces data, which is not a common scenario.
+
The Neuropixels V2e Beta Headstage GUI functions identically to the Neuropixels V2e Headstage.
+
+
The NeuropixelsV2e headstage has a graphical user interface when the OpenEphys.Onix1.Design package is downloaded. For more information on how to install that library, check out the Installation page.
+
Overview
+
For NeuropixelsV2eHeadstage, the GUI allows for an easy way to change settings and visualize the effect. From the GUI, you can:
There are two ways to access configuration dialogs; 1) at the individual NeuropixelsV2eProbeConfiguration level where either Probe A or Probe B can be modified by itself, and 2) at the headstage level where both probes can be modified, as well as the NeuropixelsV2eBno055 device.
+
Whether the GUI is opened at the probe configuration level, or the headstage level, the usage will be almost identical. There are some additional tabs present at the headstage level, but the Probe A and Probe B tabs will act exactly the same as opening a probe configuration GUI for that specific probe.
+
Channel constraints
+
For NeuropixelsV2e, there will always be 384 channels enabled across the entire probe. Therefore, when enabling electrodes (either manually or using channel presets), some previously enabled electrodes will be disabled. Additionally, if more than 384 electrodes are manually selected to be enabled, only the last 384 channels will end up being enabled. It is therefore recommended to always double-check that the correct electrodes are enabled.
+
As an example, let us assume that electrodes 0 through 383 are initially enabled (this corresponds to 384 channels). Then, electrodes 384 and 385 are enabled. When these electrodes are enabled, electrodes 0 and 1 will be disabled. In this way, there will always be 384 channels enabled.
+
In addition to the absolute number of channels, there are other restrictions in place regarding which combinations of electrodes can be enabled at any given time. Specifically, in the NeuropixelsV2QuadShankElectrode there is a Channel property which defines the channel index of an electrode. Across the entire probe, no two electrodes that share the same Channel can be simultaneously enabled.
+
Channel presets take this into account automatically and ensure that the rules are followed. When manually enabling electrodes, the indexing logic is applied in the order that electrodes are selected. If two (or more) electrodes are selected that share a Channel value, the highest indexed electrode is the only one that will be enabled.
+
+
Note
+
Due to these constraints, it is possible that a desired combination of electrodes is not feasible.
+
+
Keeping or discarding configuration settings
+
While the GUI is open, any changes to the configuration settings can be freely modified and will not affect the configuration unless Okay is pressed. This includes all aspects of the configuration, such as which electrodes are enabled, the chosen reference channel, and the probe calibration file.
+
+
Note
+
The hardware is not actually configured until the workflow starts.
+
+
If the window is closed any other way (such as by pressing Cancel, or pressing the X to close the window), then any changes made will not be saved.
+
ProbeInterface
+
The NeuropixelsV2eHeadstage GUI uses ProbeInterface as the format to draw the probes and electrodes visually. For more information on ProbeInterface and the resulting JSON file, check out their format specifications page.
+
When opening the GUI, there is a default probe configuration that is loaded and drawn, which can be saved to a JSON file. Conversely, an existing JSON file can be loaded to update the current channel configuration. If for any reason the default configuration is needed, it can be loaded again at any time.
+
Open Probe Configuration GUI
+
+
Steps to open the Probe Configuration GUI:
+
+
Select the ConfigureNeuropixelsV2eHeadstage node.
+
Click on the NeuropixelsV2eProbeConfiguration to edit (either ProbeConfigurationA or ProbeConfigurationB).
+
Select the ... button on the right-most part of the property pane (#1 above).
+
+
Once opened, if no probe calibration file has been selected the window should look like the image below. To view the probe, follow the steps below.
+
+
+
Tip
+
The controls shown for this GUI are the same as the ones shown for the NeuropixelsV2e Headstage Configuration below.
+
+
Choosing a probe calibration file
+
Upon opening the GUI for the first time, if no probe calibration file was set in the Bonsai editor, the window will be mostly blank. To populate the window with a drawing of the probe, click on the ellipsis button to the right of the empty text box under "Probe Calibration File:" (see below). This will open a file dialog, where the calibration file can be searched for and selected.
+
+
+
+
+
Note
+
Files are expected to be named XXXXXXXXXXX_gainCalValues.csv, where "XXXXXXXXXXX" is the probe serial number.
+
+
Once the file is selected, press Open or Enter. This will populate the text box with the filepath to the calibration file and enable visualization of the electrodes. Below is a view of the Probe Configuration GUI that has been opened for Probe A with a gain calibration file selected. Note that the Gain Correction textbox and the Gain Calibration SN: status strip are automatically filled in with values found in the calibration file.
+
+
Selecting channel reference
+
+
+
+
Underneath the probe calibration filepath, there is a dropdown menu for choosing the reference for all channels. For possible values and a brief description of what they correspond to, check out the references page.
+
Channel presets
+
To save time, it is possible to select a preset channel combination from the Channel Presets dropdown. These presets are defined to work within the constraints of NeuropixelsV2e channel combinations defined above.
+
+
+
+
Channel presets follow one of these patterns:
+
+
Shank N Bank [A | B | C | D]
+
+
Enables all electrodes in the chosen bank on shank N
Enables all electrodes starting at shank index N up to shank index M across all four shanks
+
+
+
+
If electrodes are manually enabled, the Channel Presets dropdown will change to None, indicating that a channel preset is no longer selected.
+
Maneuvering along the probe
+
Once a GUI has been opened and a probe calibration file has been selected, the main panel on the left will be populated with a NeuropixelsV2e probe. Below are the buttons used to navigate within this panel to view and choose electrodes.
+
+
Mouse Controls
+
+
Mouse wheel zooms in/out towards the cursor
+
Left-click and drag will select electrodes within the drawn rectangle
+
Left-click on an electrode will select that electrode
+
Left-click in empty space will clear the selected electrodes
+
Middle-click and drag will pan the electrodes
+
+
+
Scroll bar
+
+
On the right side of the main panel there is a scroll bar that can be used to move the probe up and down
+
Panning the probe up or down will update the scroll bar once the movement has completed
+
The scroll bar can be moved by:
+
+
Grabbing the marker using the mouse and dragging it up or down
+
Placing the cursor either above or below the marker and clicking
+
Using the mouse wheel to scroll up or down while the cursor is over the scroll bar
+
+
+
+
+
+
Zoom and pan limits
+
When zooming in and out, note that there are limits in both directions. The probe can only be zoomed out to the point that the entire probe is visible within the panel and no more. Similarly, while zooming in the probe will not zoom in past a certain point.
+
In addition to the absolute zoom limits, the panel will automatically shift the probe to ensure it is always in view. This is handled each time the probe is zoomed or panned.
+
To reset the view at any time, click on the Reset Zoom button to fully zoom out the panel.
+
Manually enabling electrodes
+
Electrodes can be selected at any zoom level, but it is often preferable to zoom in to read the electrode indices. Consider maximizing the screen to see those numbers more easily.
+
To select, as described above, either click-and-drag the cursor over the desired electrodes, or select individual electrodes by clicking on them one-by-one. Once the electrodes to enable are selected, click on the Enable Selected Electrodes button in the right panel. At this point the selected electrodes should turn blue, indicating that they are now enabled. It is important to note that when electrodes are enabled, a number of previously enabled electrodes will be disabled due to channel constraints. For more information, read the Channel constraints section above.
+
The short video below shows how to select, clear selection, enable selected electrodes, and translate using the scroll bar. Note that once electrodes are manually enabled, the Channel Presets drop-down changes from Shank0BankA to None. Then, once the selected electrodes match the preset, it is automatically changed back to Shank0BankA.
+
+
+
+
Loading and saving channel configurations
+
When the GUI is first opened and after a probe calibration file has been specified, the default ProbeInterface configuration is loaded and drawn in the main panel. In this case, the default configuration is for a quad-shank NeuropixelsV2e probe, with the Shank0BankA channel preset selected. To load a new configuration, load the default configuration, or save the current configuration, go to the File drop-down menu (see below) and choose the relevant option.
+
+
+
+
Save ProbeInterface file
+
To save a ProbeInterface JSON file fully describing the probe, including which electrodes are currently enabled, go to the File drop-down menu, and select Save Channel Configuration. This will open a file dialog window to save the new JSON file. Choose a folder location and a name for the file, then hit Save. This will export the current channel configuration. This is a useful way to save any manually enabled electrodes as a backup, or to easily switch between different configurations between recordings.
+
Load ProbeInterface file
+
To load a ProbeInterface JSON file, navigate to the File drop-down menu and select Load Channel Configuration. This will open a file dialog window; browse to the existing JSON file, select it and press Open to load the channel configuration. The new probe shape will be loaded and drawn, with the enabled electrodes highlighted as usual.
+
+
Note
+
When loading a new configuration, the total number of electrodes must match the existing configuration, and the number of enabled electrodes must match.
+
+
Load default configuration
+
To load the default channel configuration at any time, navigate to the File drop-down menu and choose Load Default Channel Configuration. This will load the default configuration, with the Shank0BankA channel preset selected.
+
Open Headstage Configuration GUI
+
+
Step to open the headstage configuration GUI
+
+
Double-click the ConfigureNeuropixelsV2eHeadstage node (#2 above)
+
+
Once opened, if no probe calibration is selected for either Probe A or Probe B, then both tabs will only show their controls on the right and no probes (see below).
+
+
Configure Probe A
+
Using the headstage configuration GUI is exactly the same as using the probe configuration GUI. After the GUI has been opened and a probe calibration file has been selected, Probe A will be drawn in the corresponding tab (see below).
+
+
Configure Probe B
+
Using the headstage configuration GUI is exactly the same as using the probe configuration GUI. After the GUI has been opened and a probe calibration file has been selected, Probe B will be drawn in the corresponding tab (see below).
+
+
Configure Bno055
+
At the headstage level, there is another device tab listed for a Bno055. From this tab, the device can be enabled or disabled by selecting the appropriate value from the drop-down menu next to Enable. While the DeviceAddress and DeviceName values are modifiable here, they have no affect on the underlying device configuration; only changes to the Enable property will be respected.
The NeuropixelsV2eBeta Headstage functions nearly identically to the NeuropixelsV2e Headstage. Simply replace NeuropixelsV2eData with NeuropixelsV2eBetaData and set its DeviceName property to "NeuropixelsV2eBetaHeadstage/NeuropixelsV2eBeta".
+
+
The following excerpt from the NeuropixelsV2e Headstage example workflow demonstrates Neuropixels 2.0 probe functionality by streaming data and saves Neuropixels 2.0 probe data. The second chain is disabled by default, assuming that only one probe is connected to the headstage. If two probes are connected, the second NeuropixelsV2eData chain can be enabled to stream data from both probes simultaneously. To enable, select all nodes in the disabled chain and press Ctrl+Shift+D, or click Enable right-clicking the selected nodes.
BufferSize is set to 30. Therefore, each frame will contain a [1 x 30 sample] Clock vector and a [384 channel x
+30 sample] AmplifierData matrix. The Neuropixels 2.0 probe samples at 30 kHz per channel so this
+corresponds to 1 ms of data.
+
DeviceName property is set to "NeuropixelsV2eHeadstage/NeuropixelsV2e". This links the NeuropixelsV2eData operator to the corresponding configuration operator.
+
ProbeIndex property is set to "ProbeA". This links the data generated by this probe to the probe in port A of the headstage.
+
+
The relevant properties are extracted from the NeuropixelsV2eDataFrame by right-clicking the NeuropixelsV2eData operator, and choosing the following Output members: Clock, and AmplifierData. The MatrixWriter operators saves the selected members to files with the following format: np2-a-clock_<timestamp>.raw and np2-a-amp<timestamp>.raw, respectively.
The example workflow below can by copy/pasted into the Bonsai editor using the clipboard icon in the top right. This workflow:
+
+
Captures electrophysiology data from the Neuropixels 2.0 probe(s) and saves it to disk.
+
Captures orientation data from the Bno055 IMU and saves it to disk.
+
Monitors the NeuropixelsV2e Headstage port status
+
Automatically commutates the tether if there is a proper commutator connection.
+
+
+
+
The following pages in the NeuropixelsV2e Headstage Guide provide a breakdown of the above example workflow.
+
+
Note
+
The NeuropixelsV2eBeta Headstage example workflow (download here) is nearly identical to the NeuropixelsV2e Headstage example workflow. Follow the pages in the NeuropixelsV2e Headstage Guide to learn how it works.
+ The Onix system reports when a headstage port connection enters or leaves an aberrant state. Such aberrant states include loss
+ of communication lock, detection of parity or CRC error, reception of a badly formatted packet, etc.. Knowing the time
+ and type of a communication failure is a good first step to track down its cause. The following excerpt from the
+ NeuropixelsV2e Headstage example
+ workflow demonstrates port status functionality and saves timestamped port status data.
+
+
+
+
+
+
+
+ Headstage port status data is produced in Bonsai by the PortStatus operator which generates a sequence of PortStatusFrames. PortStatus emits a
+ PortStatusFrame whenever PortStatusCode changes value. PortStatus's
+ DeviceName property is set to "NeuropixelsV2eHeadstage/PortController". This links the
+ PortStatus operator to the breakout board's port controller.
+
+
+
+ The TimeStamp operator
+ generates a sequence of UTC timestamped items from its input sequence. The CsvWriter operator writes Timestamp as
+ well as Clock and StatusCode members from PortStatusFrame to a file with the
+ following name format: port-status_<timestamp>.csv.
+
+
+
+
NOTE
+
The PortStatus datastream is always enabled. ConfigureNeuropixelsV2eHeadstage has no
+ Enable property for the PortStatus operator like other Data I/O operators that can be used
+ with the NeuropixelsV2e Headstage.
+
+
+
+
+
Note
+
The NeuropixelsV2eBeta Headstage functions nearly identically to the NeuropixelsV2e Headstage in Bonsai. Simply set PortStatus's DeviceName property to "NeuropixelsV2eBetaHeadstage/PortController".
This section will contains tutorials that demonstrate how to make the most of
+the Bonsai library by combining ONIX with third party tools, tuning closed loop
+response times, etc.
ONIX is built on the ONI standard, which is software
+agnostic. Bonsai is the first software target pursued by the Open Ephys team for
+ONIX hardware. There are three major reasons for this:
+
+
Performance. ONIX is a universal interface for neural recording instruments. It can
+capture data produced by neural probes, cameras, high-speed ADCs, etc. In
+general terms, ONIX can capture data from arbitrary mixtures of
+asynchronous1 data sources. Bonsai provides an extremely powerful,
+open-source software platform for elegantly collecting, combining, and
+processing data from essentially any data source regardless of its sample
+rate, sample regularity, packet size, and bandwidth. Bonsai accomplishes this
+task in a fundamental manner: it explicitly models each data source as an
+ordered temporal sequence with a start and end called an
+Observable. This is
+analogous to how, for instance,
+Numpy explicitly models fixed-size
+multi-dimensional arrays as
+ndarrays.
+And, just like Numpy offers an extensive linear algebra toolkit
+to operate on these arrays, Bonsai offers an analogous
+toolkit
+for operating on temporal sequences of data. Because Bonsai was created around this core
+data model and operator library, it makes capturing, processing, and combining data
+sequences from different hardware sources natural in Bonsai, whereas it is
+bug prone and difficult in other software options.
+
+
Code quality. Open Ephys has been developing open source hardware and
+software for the Neuroscience community for over a decade. In terms of code
+quality, Bonsai is excellent. Bonsai uses a modern language and build system,
+has integrated package management, and an extremely clean, featureful, and well
+maintained API. Given that Bonsai's development model perfectly aligns with our
+values, we are very proud to be able to contribute to its growth in the
+Neuroscience community.
+
+
Third party integration. Bonsai provides support for
+hundreds of pieces of open- and closed-source hardware and software that are
+used extensively in neuroscience research. For instance:
By targeting Bonsai, ONIX can be used seamlessly with these third party tools.
+
+
+
+
Note
+
We put a lot of effort into
+making these docs useful for everyone. If you have suggestions for making
+them even better, please contribute by either raising an
+issue or following the links saying
+Edit this page. We welcome all constructive feedback. As always, our goals
+are better performing tools, less redundant development, and more reproducible
+science.
+
In addition to this library, we are currently developing ONIX support for the
+Open Ephys GUI.
+
+
+
+
+
+
Although physical data sources are asynchronous (e.g. a Neuropixels probe
+runs on a distinct clock and produces data at a distinct rate compared to the
+camera sensor on a Miniscope), all data is hardware-timestamped on a common
+clock. No post-hoc data alignment is required.↩