Thank you very much for your precious help.
We have carefully analyzed your suggestions and there are a few elements that we would like to clarify with you.
1) “If I were you, I would export as you are recording, so the export file is always ready to use.”
We were not aware that it was possible to export data in EDF format while recording. After checking the documentation, we found this could be very helpful for us. However, when we export data with Neuroplayer on the machine used for recording data with Neurorecorder, we often experience crashes during the export process.
The only reason we can think of that could cause these crashes is the limited computational capacity of the computer used to record the signals. Indeed CPU usage is at 97-100% when recording and exporting at the same time. Therefore, we aim to transfer the acquisition to a more powerful computer to record and export the signals simultaneously. Is there a specific internal extension card (or another specific component) we have to add to the new machine we are assembling?
2) “How big is the overlap? How long are your individual NDF files? Do you have the Synchronize button checked in Neuroplayer when you record? How long is the overlap? Is it seconds, minutes, or tens of minutes?”
Let me better explain our overlap problem with an example.
Imagine we want to export the successive NDF files “M1702291203.ndf” and “M1702294804.ndf” to EDF format and we have chosen a processing interval of 8 seconds in the Neuroplayer menu.
Each of these two files corresponds to a one-hour recording, which is well reflected by the Unix-Time index difference in the file names: 1702294804 - 1702294804 = 3601 seconds.
Once the conversion to EDF is complete:
- “M1702291203.ndf” has been converted to “E1702291203.edf”
- “M1702294804.ndf” has been converted to “E1702294795.edf”
Thus, the Unix-Time index difference in the EDF file names is no longer 3601 seconds but 1702294795 - 1702291203 = 3592 seconds. This results in an overlap of 3600 - 3592 = 8 seconds between the two recordings, with both EDF files having a duration of 3600 seconds.
Similarly, if we choose a processing interval of 2 seconds:
- “M1702291203.ndf” is converted to “E1702291203.edf”
- “M1702294804.ndf” is converted to “E1702294801.edf”
We therefore have an overlap of 3600 - (1702294801 - 1702291203) = 3600 - 3598 = 2 seconds. Thus, the overlap matches the duration of the processing interval.
Likewise, if we launch the successive export of “M1702291203.ndf”, “M1702294804.ndf”, and “M1702298405.ndf” with an 8-second processing interval:
- “M1702291203.ndf” is converted to “E1702291203.edf” (1)
- “M1702294804.ndf” is converted to “E1702294795.edf” (2)
- “M1702298405.ndf” is converted to “E1702298389.edf” (3)
Thus, we observe:
- A temporal shift of 8 seconds between “M1702294804.ndf” and “E1702294801.edf” (2)
- A temporal shift of 16 seconds between “M1702298405.ndf” and “E1702298389.edf” (3)
We can then hypothesize that: temporal shift = number of files * processing interval duration.
However, if we launch the export (still with an 8-second processing interval) of two batches of files separately, for instance:
- First of “M1702291203.ndf” and “M1702294804.ndf”
- And then of “M1702298405.ndf” and “M1702302006.ndf”
Then,
- “M1702291203.ndf” is converted to “E1702291203.edf” (1)
- “M1702294804.ndf” is converted to “E1702294795.edf” (2)
- “M1702298405.ndf” is converted to “E1702298405.edf” (3)
- “M1702302006.ndf” is converted to “E1702301998.edf” (4)
Thus, we observe:
- No temporal shift for the first exported files (1) and (3)
- An 8 seconds shift for the second exported files (2) and (4)
This is problematic for us because, if a crash occurs during an export, we have to reindex all the remaining files to be exported before starting their export.
Therefore, could you please let us know if this is normal and, if so, if it is possible to avoid this overlap?
Regarding the Synchronize button, we do check it when we record our data with Neurorecorder.
Best wishes,
RaphaëlStatistics: Posted by Raphaël Nunes — Mon Jul 15, 2024 11:44 am
]]>