diff --git a/articles/hardware/rhs2116/configuration.md b/articles/hardware/rhs2116/configuration.md index e2e52cd..81bd51f 100644 --- a/articles/hardware/rhs2116/configuration.md +++ b/articles/hardware/rhs2116/configuration.md @@ -12,16 +12,17 @@ workflowLocation: overview ## Configuring the Breakout Board and Headstage Rhs2116 -The `ConfigureBreakoutBoard` operator configures the Onix Breakout Board. In the Headstage Rhs2116 example tutorial, it is -configured to enable digital inputs to serve as a trigger for the Headstage Rhs2116'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 Monitor` `Enable` property is set to -`True`. +The `ConfigureBreakoutBoard` operator configures the Onix Breakout Board. In the Headstage Rhs2116 +example tutorial, it is configured to enable digital inputs to serve as a trigger for the Headstage +Rhs2116'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 Monitor Enable property is set to "True". -The `ConfigureHeadstageRhs2116` operator is used to configure the Headstage Rhs2116. In the Headstage Rhs2116 example -tutorial, it is configured to enable streaming of electrophysiology data from a Rhs2116 amplifier, orientation data from -the on-board Bno055 IMU, and position data from the Ts4231. This is accomplished in the Headstage Rhs2116 example -workflow by leaving all of the `ConfigureHeadstageRhs2116` properties set to their default values. +The `ConfigureHeadstageRhs2116` operator is used to configure the Headstage Rhs2116. In the +Headstage Rhs2116 example tutorial, it is configured to enable streaming of electrophysiology data +from a Rhs2116 amplifier, orientation data from the on-board Bno055 IMU, and position data from the +Ts4231. This is accomplished in the Headstage Rhs2116 example workflow by leaving all of the +`ConfigureHeadstageRhs2116` properties set to their default values. [!INCLUDE [timestamp-info](../../../includes/configuration-timestamp.md)] diff --git a/articles/hardware/rhs2116/gui.md b/articles/hardware/rhs2116/gui.md index f523599..2fa361b 100644 --- a/articles/hardware/rhs2116/gui.md +++ b/articles/hardware/rhs2116/gui.md @@ -12,16 +12,18 @@ downloaded. For more information on how to install that library, check out the The GUI for `Rhs2116Headstage` allows for an easy way to change settings, as well as the ability to set waveform parameters and visualize the effect. From the GUI, you can: -- Modify stimulus parameters for all 32 channels simultaneously - - Visualize waveforms across all channels - - Select specific channels using a ProbeInterface representation of the hardware - - Remove or add stimulus waveform parameters to one or more channels at a time +- Modify stimulus parameters for all 32 channels + - Visualize waveforms across all channels + - Select specific channels using a ProbeInterface representation of the hardware + - Remove or add stimulus waveform parameters to one or more channels at a time + - Save and load channel configuration - Change filter settings for recording data - - See the page for more information on filter settings + - See or the + [Rhs2116 datasheet](https://intantech.com/files/Intan_RHS2116_datasheet.pdf) for more + information on filter settings This configuration GUI can be accessed by double-clicking on the `ConfigureHeadstageRhs2116` -operator. The remainder of this page will describe the functionality of the window that opens, -allowing for easy configuring of the hardware. +operator.

@@ -29,16 +31,17 @@ allowing for easy configuring of the hardware. ### Stimulus parameters -All of the parameters are applied in real-world units that the user will be familiar with (i.e., -milliseconds and microamps). On the backend, the GUI will take these units and convert them into raw -samples which is how they will be written to the hardware. Since the conversion between real units -and samples is not always exact, there might be some discrepancies between the value that the user -initially inputs and the value that is automatically updated. Values will be automatically updated -whenever the focus moves away from the current text box (i.e., the user presses Tab or -clicks somewhere outside of the text box). +The GUI accepts values for stimulation waveform parameters in metric units (e.g., milliseconds and +microamps). In the backend, the GUI converts metric units into units that can be written to the +hardware. Because the conversion between metric values and converted values is not always exact, the +GUI might automatically update the metric value initially input by the user to a metric value that +more accurately represents the converted value that will be written to hardware. This update is +visually displayed in the same text box where the user initially input their values and happens when +the focus moves away from the active text box (e.g., the user presses Tab or clicks +somewhere outside of the text box). -Below is a table listing the various parameters that can be applied to each channel, as well as the -resolution and any other relevant limits for each parameter. +Below is a table describing the various stimulus parameters that can be applied to each channel +including the resolution and limits for each parameter. | Parameter Name | Minimum Value | Maximum Value | Resolution | Remarks | | ----- | ---- | ---- | ---- | ---- | @@ -46,25 +49,23 @@ resolution and any other relevant limits for each parameter. | `Anodic First` | Unchecked | Checked | n/a | If checked, the anodic (positive) segment will be delivered first for every pulse | | `Delay` | 0 ms | n/a | 0.03312 ms | Time between a trigger being received and the first pulse is delivered | | `Inter-Pulse` | 0 ms | n/a | 0.03312 ms | Time between positive-to-negative (or negative-to-positive) stimulation for a single pulse | -| `Amplitude` | 0 µA | 2550 µA | Dependent on the step size | Type in the requested amplitude, and underneath is the actual value that will be applied on hardware based on the current step size | -| `Step Size` | 0.01 µA | 25 µA | [Step Size](xref:OpenEphys.Onix1.Rhs2116StepSize) | Automatically calculated to optimize difference between requested and actual amplitude | -| `Pulse Width` | 0.03312 ms | n/a | 0.03312 ms | Width of each positive or negative portion of the stimulus | +| `Amplitude` | 0 µA | 2550 µA | Dependent on the step size | Enter the requested amplitude, and the actual value that will be applied on hardware based on the current step size is displayed underneath in the `Step Size` text box | +| `Step Size` | 0.01 µA | 25 µA | [Step Size](xref:OpenEphys.Onix1.Rhs2116StepSize) | Automatically calculated to optimize difference between requested and actually possible amplitude | +| `Pulse Width` | 0.03312 ms | n/a | 0.03312 ms | Time between each pulse's rising edge and falling edge (or vice-versa) | | `Inter-Stimulus` | 0.03312 ms | n/a | 0.03312 ms | Time between successive pulses. Can be 0 if there is only one pulse | | `Number of Pulses` | 1 | n/a | 1 | Number of pulses that are sent per trigger received | ### ProbeInterface -The `Rhs2116Headstage` GUI uses -[ProbeInterface](https://probeinterface.readthedocs.io/en/main/index.html) 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](https://probeinterface.readthedocs.io/en/main/format_spec.html) page. +The `Rhs2116Headstage` GUI uses the +[ProbeInterface](https://probeinterface.readthedocs.io/en/main/index.html) format to draw the probes +and electrodes visually. For more information on the ProbeInterface JSON format, check out their +[format specifications](https://probeinterface.readthedocs.io/en/main/format_spec.html) page. -When opening the GUI, there is a default probe configuration that is loaded and drawn, which can be -saved to a [JSON file](#save-probeinterface-file). Conversely, an existing JSON file can be -[loaded](#load-probeinterface-file) to update the current channel configuration. If for any reason -the default configuration is needed, it can be [loaded again](#load-default-configuration) at any -time. +When opening the GUI, there is a default probe configuration that is loaded and drawn which can be +saved to a [JSON file](#save-probeinterface-file). Conversely, an existing ProbeInterface JSON file +can be [loaded](#load-probeinterface-file) to update the current channel configuration. If the +default configuration is needed, it can be [loaded again](#load-default-configuration) at any time. ## Using the Channel Selection Window @@ -86,11 +87,11 @@ are the controls used to navigate within this panel to view and choose electrode - 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 toggle selection for that electrode - - Left-click in empty space will clear the selected electrodes + - Left-click on empty space will clear the electrode selection - Middle-click and drag will pan the electrodes When channels are selected, they will be highlighted by a green circle around the contact number, -and the appropriate waveform will continue to be plotted in the main window; any channels that are +and the corresponding waveforms will be plotted in the main window; any channels that are not selected will not be plotted. ### Zoom and pan limits @@ -104,10 +105,9 @@ is always in view. This is handled each time the probe is zoomed or panned. ## Define Stimuli -The following sections will define how to apply parameters, read existing parameters, and clear -parameters from channels. A description of what the parameters refer to will be given, as well as -tables to define some of the error codes that can appear in the status strip to better troubleshoot -issues. +The following sections define how to apply parameters, read existing parameters, and clear parameters from channels. +They also provide example stimulus parameters and descriptions of error codes that can appear in the status strip to +facilitate troubleshooting. ### Applying parameters @@ -121,13 +121,12 @@ are selected.

-Next, type in / check the [stimulus parameters](#stimulus-parameters) that are to be -applied to the currently selected channel(s). The section above will give some insight into what -each parameter is controlling, as well as the possible resolutions and maximum/minimum values that -can be applied. Note that each time the cursor leaves a text box it will automatically update the -values inside the text box to reflect the actual value that will be written, based on the -resolutions listed above. In the example below, we can see that the table listed below as well shows -the typed values compared to the actual values list. +Enter the [stimulus parameters](#stimulus-parameters) that you want to apply to the currently +selected channel(s). Note that the value initially input by the user might update when the focus +moves away from the current text box (e.g., the user presses Tab or clicks somewhere +outside of the text box) to reflect the actual value that will be written based on the resolutions +listed above. In the example below, we can see that the table listed below as well shows the typed +values compared to the actual values list. | Parameter | Requested Value | Listed Value | | --- | --- | --- | @@ -178,8 +177,8 @@ parameter fields will be populated with zeroes as shown in the image below:

-Any channel that has been configured can also be selected before pressing Read to pull -out the current parameters. For example, if one of the channels that was configured in the [Applying +Now select a channel that has been configured and press Read to read that channel's +current parameters. For example, if one of the channels that was configured in the [Applying parameters](#applying-parameters) section above is selected, the image below shows the result of the operation: @@ -239,8 +238,8 @@ configuration, such as filter settings and all stimulus waveform parameters. > [!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. If the current settings are considered +If the window is closed any other way (such as by pressing `Cancel` or pressing the X to +close the window), any changes made *will not* be saved. If the current settings are considered invalid (see [the table above](#reasons-for-invalid-sequence-status) for specific reasons why some settings are invalid), they also *will not* be saved even if Ok is pressed. A message box will pop up warning that the settings will not be saved, giving the opportunity to continue editing diff --git a/articles/hardware/rhs2116/rhs2116-record.md b/articles/hardware/rhs2116/rhs2116-record.md index 645f73c..bb33be1 100644 --- a/articles/hardware/rhs2116/rhs2116-record.md +++ b/articles/hardware/rhs2116/rhs2116-record.md @@ -3,26 +3,26 @@ uid: rhs2116_record title: Rhs2116 Recording --- -The following excerpt from the HeadstageRhs2116 [example workflow](xref:rhs2116) demonstrates the Rhs2116 -recording functionality by streaming and saving data from the Rhs2116 device. +The following excerpt from the HeadstageRhs2116 [example workflow](xref:rhs2116) demonstrates the +Rhs2116 recording functionality by streaming and saving data from the Rhs2116 device. ::: workflow ![/workflows/hardware/rhs2116/rhs2116-record.bonsai workflow](../../../workflows/hardware/rhs2116/rhs2116-record.bonsai) ::: -The operator generates a sequence of s using -the following settings: -- `BufferSize` is set to 30. Each `Rhs2116DataFrame` will contain a [1 x 30 sample] `Clock` vector, a [32 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. -- `DeviceName` is set to "HeadstageRhs2116/Rhs2116". This links the `Rhs2116Data` - operator to the corresponding configuration operator. +The operator generates a sequence of +s using the following settings: +- The BufferSize property is set to 30. Each `Rhs2116DataFrame` will contain a [1 x 30 sample] Clock + vector, a [32 channel x 30 sample] AmplifierData matrix, and a [32 channel x 30 sample] DcData + matrix. This corresponds to 1 ms of data per data frame. +- The DeviceName property is set to "HeadstageRhs2116/Rhs2116". This links `Rhs2116Data` to the + Rhs2116s on the Headstage Rhs2116. -The relevant properties are extracted from the `Rhs2116DataFrame` by right-clicking the `Rhs2116Data` operator, and -choosing the following Output members: `Clock`, `AmplifierData`, and `DcData`. The - operators saves the selected members to -files with the following format: `rhs2116pair-clock_.raw`, `rhs2116pair-dc_.raw`, and -`rhs2116pair-ac_.raw`, respectively. +The relevant properties are extracted from the `Rhs2116DataFrame` by right-clicking the +`Rhs2116Data` operator, and choosing the following Output members: Clock, AmplifierData, and DcData. +The s save the selected members to files with the following +formats: `rhs2116pair-clock_.raw`, `rhs2116pair-ac_.raw`, and +`rhs2116pair-dc_.raw`, respectively. > [!TIP] > For more details about configuring the Rhs2116 and its data, read the diff --git a/articles/hardware/rhs2116/rhs2116-stimulate.md b/articles/hardware/rhs2116/rhs2116-stimulate.md index 0b046cb..2cc846e 100644 --- a/articles/hardware/rhs2116/rhs2116-stimulate.md +++ b/articles/hardware/rhs2116/rhs2116-stimulate.md @@ -10,22 +10,26 @@ stimulation functionality by streaming and saving data from the Rhs2116 device. ![/workflows/hardware/rhs2116/rhs2116-stimulate.bonsai workflow](../../../workflows/hardware/rhs2116/rhs2116-stimulate.bonsai) ::: -The operator generates a sequence of s. -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). 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 operator generates a sequence of +s. 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). In the Breakout Board example workflow, the `DigitalInput`'s DeviceName property is +set to "BreakoutBoard/DigitalInput". This links the `DigitalInput` operator to the Breakout Board's +digital inputs. - is selected from the `DigitalInputDataFrame`. It is an enumerator with values -that correspond to bit positions of the breakout board's digital port. `Buttons` connects to `Condition` which is -inspectable with the F12 hotkey. `Condition` contains a `HasFlags` operator. Because `HasFlags`'s `Value` is -set to "Triangle", its output is "True" when the selected `BreakoutButtonState` bit field contains the "Triangle" flag. -Therefore, the conditional statement evaluates as true whenever the "Triangle" button is pressed in which case the -upstream `BreakoutButtonState` element emitted by `Condition` to `Double`, which emits a value of type -to anytime it receives an item in its upstream sequence. + is selected from the `DigitalInputDataFrame`. It is an +enumerator with values that correspond to bit positions of the breakout board's digital port. +`Buttons` connects to `Condition` which is inspectable with the F12 hotkey. `Condition` +contains a `HasFlags` operator. Because `HasFlags`'s Value property is set to "Triangle", it outputs +"True" when the △ button is pressed. `Condition` passes `BreakoutButtonState` to `Double` +when the its internal conditional statement is evaluated is true. `Double` emits a value of type + to anytime it receives an item in +its upstream sequence. -When `Rhs2116StimulusTrigger` receives a double from the upstream sequence, a stimulus waveform is triggered. The -waveform can be modified by `Rhs2116StimulusTrigger`'s properties. +When `Rhs2116StimulusTrigger` receives a double from the upstream sequence, a stimulus waveform is +triggered. Its DeviceName property is set to "HeadstageRhs2116/StimulusTrigger" to link this +operator to the Rhs2116s on the Headstage Rhs2116. [Open the Headstage RHS2116 +GUI](xref:rhs2116_gui) to edit the stimulus waveform. > [!TIP] > For more details about configuring the Rhs2116 and its stimulation capabilities, read the diff --git a/includes/configuration-timestamp.md b/includes/configuration-timestamp.md index 2e012ba..af4423e 100644 --- a/includes/configuration-timestamp.md +++ b/includes/configuration-timestamp.md @@ -1,8 +1,6 @@ When the workflow is started, the current time (based on -[Coordinated Universal Time](https://en.wikipedia.org/wiki/Coordinated_Universal_Time)) -is saved, along with global hardware parameters governing data acquisition. This is -accomplished using a [TimeStamp](https://bonsai-rx.org/docs/api/Bonsai.Reactive.Timestamp.html) 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_.csv`) when the the workflow is started. \ No newline at end of file +[Coordinated Universal Time](https://en.wikipedia.org/wiki/Coordinated_Universal_Time)) is saved, along with global +hardware parameters governing data acquisition. This is accomplished using a +[TimeStamp](https://bonsai-rx.org/docs/api/Bonsai.Reactive.Timestamp.html) operator to capture the computer's wall clock +time. The timestamp is saved along with `ContextTask`'s properties (e.g. AcquisitionClockHz, BlockReadSize, +BlockWriteSize) to a csv file (`start-time_.csv`) when the workflow is started. \ No newline at end of file diff --git a/template/partials/hardware/bno055.tmpl.partial b/template/partials/hardware/bno055.tmpl.partial index 11579ff..989ba89 100644 --- a/template/partials/hardware/bno055.tmpl.partial +++ b/template/partials/hardware/bno055.tmpl.partial @@ -1,5 +1,8 @@

- The following excerpt from the {{{hardware}}} example workflow demonstrates Bno055 functionality, saves Bno055 data, and commutates the {{{hardware}}} if there is a proper commutator connection. + The following excerpt from the {{{hardware}}} example + workflow visualizes Bno055 data, saves Bno055 data, and commutates the {{{hardware}}} if there + is a proper commutator connection.

@@ -7,18 +10,41 @@

- The {{{bnoOperator}}} operator generates a sequence of Bno055DataFrames. The DeviceName property is set to "{{{hardwareOperator}}}/{{{bnoOperator}}}". This links the {{{bnoOperator}}} operator to the corresponding configuration operator. + The {{{bnoOperator}}} + operator generates a sequence of Bno055DataFrames. Its DeviceName property is + set to "{{{hardwareOperator}}}/{{{bnoOperator}}}" which links {{{bnoOperator}}} to + the Bno055 on the {{{hardware}}}.

- The CsvWriter operator writes the entire Bno055DataFrame to a file with the following format: bno055_<filecount>.csv. Because CsvWriter is a sink operator, its output sequence is equivalent to its input sequence (i.e., {{{bnoOperator}}}'s output). This means that the Quaternion property (originally from {{{bnoOperator}}}) can be selected from the CsvWriter operator by right-clicking the operator and selecting the proper Output property. + The CsvWriter + operator writes the entire Bno055DataFrame to a file with the following format: + bno055_<filecount>.csv. Because CsvWriter is a sink + operator, its output sequence is equivalent to its input sequence. This means that the Quaternion + member from Bno055DataFrame can be selected downstream of CsvWriter. + This is most easily performed by right-clicking the operator, hovering over "Output", and clicking + the corresponding member.

- 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 {{{hardware}}}. 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. + Quaternion values are passed to AutoCommutator which automatically commutates the + headstage's tether if there is a proper commutator connection. This operator comes from the + OpenEphys.Commutator Bonsai package. Make sure it's installed and updated. You can + enable/disable the commutator using the Enable property, enable/disable the LED on the commutator + using the LedEnable property, and set the COM port using the PortName property. 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
-

The AutoCommutator operator is included in the workflow by default because it is so commonly used with {{{hardware}}}. However, it is disabled for people without a commutator to be able to run the workflow. To enable it, select the node and press Ctrl + Shift + D or select "Enable" in the context menu that appears after right-clicking the node.

+

+ AutoCommutator is included in the workflow because a commutator is often combined + with the {{{hardware}}} and the Breakout Board for freely-moving experiments. However, it is + disabled by default so that users without a commutator can run the workflow without additional + steps. To enable it, click on the node and press Ctrl + Shift + D or right-click the + node and click "Enable". +

\ No newline at end of file diff --git a/template/partials/hardware/configuration.tmpl.partial b/template/partials/hardware/configuration.tmpl.partial index ee90acb..b110345 100644 --- a/template/partials/hardware/configuration.tmpl.partial +++ b/template/partials/hardware/configuration.tmpl.partial @@ -1,11 +1,25 @@

The following excerpt from the {{{hardware}}} - example workflow demonstrates how to create an ONIX acquisition context using CreateContext, configures a {{{hardware}}} - using {{{operator}}}, and - then starts acquisition using StartAcquisition. + example workflow demonstrates how to configure your {{{hardware}}} and Breakout Board + in Bonsai. This process comprises of the following steps: +

+

@@ -15,8 +29,8 @@
NOTE

- To learn more about the top-level configuration motif in every workflow involving - ONIX hardware, visit the Configuration Chain Tutorial.

@@ -25,13 +39,13 @@

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. + 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.

{{{conceptual}}} @@ -39,28 +53,31 @@

Starting Acquisition

- After starting a workflow, the StartAcquisition + After starting a workflow, the StartAcquisition operator begins data acquisition with the hardware that has been configured. In the {{{hardware}}} example workflow, data is collected from the {{{hardware}}} only, so the rate of data being - produced by the hardware will be ~{{{dataRate}}} MB/s. The StartAcquisition's ReadSize property is set to - {{{blockReadSize}}} bytes, meaning data collection will wait until - {{{blockReadSize}}} bytes of data have been produced by the hardware. At {{{dataRate}}} MB/s the - hardware will produce {{{blockReadSize}}} bytes every ~{{{timeUntilFullBuffer}}}. 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. + produced by the hardware will be ~{{{dataRate}}} MB/s. The ReadSize property is set to + {{{blockReadSize}}} bytes, meaning data collection will wait until {{{blockReadSize}}} bytes of + data have been produced by the hardware. At {{{dataRate}}} MB/s the hardware will produce + {{{blockReadSize}}} bytes every ~{{{timeUntilFullBuffer}}}. 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 property value 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 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.

NOTE
-

For an overview of the devices on the {{{hardware}}} that can be configured through the {{{operator}}} operator, visit - the {{{hardware}}} - Overview.

+

+ For an overview of the devices on the {{{hardware}}} that can be configured through the {{{operator}}} operator, visit + the {{{hardware}}} Overview. +

diff --git a/template/partials/hardware/memoryMonitor.tmpl.partial b/template/partials/hardware/memoryMonitor.tmpl.partial index 566fe9e..dd4d96e 100644 --- a/template/partials/hardware/memoryMonitor.tmpl.partial +++ b/template/partials/hardware/memoryMonitor.tmpl.partial @@ -1,6 +1,7 @@

- The following excerpt from the Breakout Board example workflow demonstrates - memory monitor functionality. + The following excerpt from the Breakout Board example + workflow demonstrates memory monitor functionality.

@@ -8,41 +9,43 @@

- 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 - MemberSelector operator selects the PercentUsed member from the - MemoryMonitorDataFrame so the user can visualize PercentUsed data from the - MemoryMonitorDataFrame. + MemoryMonitorData + emits a MemoryMonitorDataFrame at a + regular interval set by Breakout Board Configuration + using the ConfigureBreakoutBoard's + 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 Breakout Board's memory monitor. + MemberSelector selects the PercentUsed member from + MemoryMonitorDataFrame so the user can visualize the percentage of the breakout + board's memory that is occupied.

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%. + MemoryMonitorData 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, + StartAcquisition's BlockReadSize property 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. + If the hardware FIFO's PercentUsed is non-zero for long time periods, or is + increasing, the value of StartAcquisition's BlockReadSize property is too small + (see the breakout board configuration). A small + BlockReadSize means 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.

\ No newline at end of file diff --git a/template/partials/hardware/portStatus.tmpl.partial b/template/partials/hardware/portStatus.tmpl.partial index b09a2df..3bdc059 100644 --- a/template/partials/hardware/portStatus.tmpl.partial +++ b/template/partials/hardware/portStatus.tmpl.partial @@ -1,9 +1,12 @@

- 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 - {{{hardware}}} example - workflow demonstrates port status functionality and saves timestamped port status data. + The Onix system reports when a headstage/miniscope 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 an aberrant state can + help track down its cause. The following excerpt from the {{{hardware}}} + example + workflow + demonstrates port status functionality and saves timestamped port status data.

@@ -11,26 +14,28 @@

- 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 "{{{hardwareOperator}}}/PortController". This links the - PortStatus operator to the breakout board's port controller. + PortStatus emits a PortStatusFrame when + PortStatusCode changes value + i.e. when the {{{hardware}}} port connection enters or leaves an aberrant state. Its DeviceName + property is set to "{{{hardwareOperator}}}/PortController" which links the operator to the port + controller where the {{{hardware}}} is connected.

- The TimeStamp operator + 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. + href="https://bonsai-rx.org/docs/api/Bonsai.IO.CsvWriter.html">CsvWriter operator writes + Timestamp as well as Clock and StatusCode members from PortStatusFrame to a file with + the following name format: port-status_<filecount>.csv.

NOTE
-

The PortStatus datastream is always enabled. {{{configureHardwareOperator}}} has no - Enable property for the PortStatus operator like other Data I/O operators that can be used - with the {{{hardware}}}.

+

+ The PortStatus datastream is always enabled. + {{{configureHardwareOperator}}} does not have an Enable property for + streaming port status data. +

\ No newline at end of file