-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add hs64 stimulation pages and data loading script
- Conform hardware guides to a standard and fix data loading scripts - Bno055 CsvWriter should be consistent - memory monitor template + pages for np1 & np2 - Change timestamp to filecount for file suffixes - Change Load Data titles
- Loading branch information
Showing
57 changed files
with
620 additions
and
276 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,30 +1,8 @@ | ||
| --- | ||
| uid: breakout_memory-monitor | ||
| title: Breakout Board Memory Monitor | ||
| device: memory monitor | ||
| title: Memory Monitor | ||
| memoryMonitor: true | ||
| hardware: Breakout Board | ||
| hardwareOperator: BreakoutBoard | ||
| workflowDirectory: breakout/workflow | ||
| --- | ||
|
|
||
| The following excerpt from the Breakout Board [example workflow](xref:breakout_workflow) demonstrates memory monitor functionality and saves memory monitor data. | ||
|
|
||
| ::: workflow | ||
|  | ||
| ::: | ||
|
|
||
| The <xref:OpenEphys.Onix1.MemoryMonitorData> operator generates a sequence of <xref:OpenEphys.Onix1.MemoryMonitorDataFrame>s. `MemoryMonitorData` emits `MemoryMonitorDataFrame`s at a regular interval defined during <xref:breakout_configuration> using the <xref:OpenEphys.Onix1.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](https://bonsai-rx.org/docs/api/Bonsai.IO.CsvWriter.html) 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](https://bonsai-rx.org/docs/api/Bonsai.Expressions.MemberSelectorBuilder.html) 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](xref:breakout_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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,8 +1,9 @@ | ||
| --- | ||
| uid: hs64_bno055 | ||
| title: Headstage 64 Bno055 | ||
| hardware: Headstage 64 | ||
| bno055: true | ||
| hardware: Headstage 64 | ||
| bnoOperator: Bno055Data | ||
| hardwareOperator: Headstage 64 | ||
| hardwareOperator: Headstage64 | ||
| workflowDirectory: hs64/workflow | ||
| --- |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| --- | ||
| uid: hs64_load-data | ||
| title: Load Data | ||
| --- | ||
|
|
||
| The following python script can be used to load and plot the data produced by the Headstage64 [example workflow](xref:hs64_workflow). | ||
|
|
||
| [!code-python[](../../../workflows/hardware/hs64/load-hs64.py)] | ||
|
|
||
| > [!NOTE] | ||
| > This script will attempt to load entire files into arrays. For long recordings, data will need to | ||
| > be split into more manageable chunks by: | ||
| > - Modifying this script to partially load files | ||
| > - Modifying the workflow to cyclically create new files after a certain duration |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,29 +1,8 @@ | ||
| --- | ||
| uid: hs64_memory-monitor | ||
| title: Headstage64 Memory Monitor | ||
| title: Memory Monitor | ||
| memoryMonitor: true | ||
| hardware: Headstage 64 | ||
| hardwareOperator: Headstage64 | ||
| workflowDirectory: hs64/workflow | ||
| --- | ||
|
|
||
| The following excerpt from the Breakout Board [example workflow](xref:breakout_workflow) demonstrates memory monitor functionality and saves memory monitor data. | ||
|
|
||
| ::: workflow | ||
|  | ||
| ::: | ||
|
|
||
| The <xref:OpenEphys.Onix1.MemoryMonitorData> operator generates a sequence of <xref:OpenEphys.Onix1.MemoryMonitorDataFrame>s. `MemoryMonitorData` emits `MemoryMonitorDataFrame`s at a regular interval defined during <xref:breakout_configuration> using the <xref:OpenEphys.Onix1.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](https://bonsai-rx.org/docs/api/Bonsai.IO.CsvWriter.html) 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](https://bonsai-rx.org/docs/api/Bonsai.Expressions.MemberSelectorBuilder.html) 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](xref:breakout_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. |
Oops, something went wrong.