reading NDF files in python

[Kevan Hashemi]

Dear Raphael,

Returning to this behavior:

> Once the conversion to EDF is complete:
> “M1702291203.ndf” has been converted to “E1702291203.edf”
> “M1702294804.ndf” has been converted to “E1702294795.edf”

I am able to reproduce this behavior easily. I am recording 60-s files with synchronization at the start of each new file. I am exporting 60-s files, starting with the first file. I see the following conversions:

M1721250458.ndf -> M1721250458.edf
M1721250519.ndf -> E1721250516.edf
M1721250580.ndf -> E1721250575.edf
M1721250641.ndf -> E1721250634.edf

The problem arises when the file and the export length are the same. There is a logical error in my code for this particular situation. I believe the correct behavior should be:

M1721250458.ndf -> M1721250458.edf
M1721250519.ndf -> M1721250519.edf
M1721250580.ndf -> M1721250580.edf
M1721250641.ndf -> M1721250641.edf

Here we are missing 1-s intervals as the Neurorecorder synchronizes with the computer, but the file names are the same and all the files are the same length. Do you agree that this is the correct behavior?

Best Wishes, Kevan

[Kevan Hashemi]

Dear Raphael,

Thank you for your patience. We just released LWDAQ 10.6.11 with Neuroplayer 171 and Neurorecorder 168. You can pull from our Git repository:

https://github.com/OSI-INC/LWDAQ

Or download and unzip our new archive:

http://www.bndhep.net/Software/Download/LWDAQ_10.6.11.zip

The default behavior of the Neurorecorder is now "free-running" rather than "re-synchronizing". The Synchronization box will be un-checked. We discuss the two synchronization strategies here:

https://www.opensourceinstruments.com/Electronics/A3018/Neurorecorder.html#Synchronization

Please try the Exporter in the Neuroplayer 171 and let me know if it eliminates overlap and assigns the correct names to the export files.

Best Wishes, Kevan

[Raphaël Nunes]

Dear Kevan,

Thank you again for your help.

We have installed the latest version of LWDAQ (10.6.10) on our new recording machine. After using this new machine to record and export the signals, here are some observations:

1) Although the Neuroplayer no longer crashes, it now creates two files when exporting: one containing the full 3600 seconds and another with only the last 8 seconds.

2) The 8-second overlap still exists when exporting files with an 8-second processing interval.

3) When exporting in EDF format with the latest version of Neuroplayer, the exported files use "cnt" as units instead of mVs (millivolts). This is problematic for us because we built our processing scripts based on the previously used mVs units. Additionally, we are not familiar with the "cnt" unit and cannot convert it to mVs. Is there a way to modify the export unit in version 10.6.10 of Neuroplayer? This would be very useful to us.

Best wishes,
Raphaël

[Kevan Hashemi]

Dear Raphael,

I am sorry to hear that you are still having problems with the exporter.

> We have installed the latest version of LWDAQ (10.6.10) on our new recording machine.

The latest version is LWDAQ 10.6.11. Do you really mean 10.6.10? You can download 10.6.11 from here:

http://www.bndhep.net/Software/Download/LWDAQ_10.6.11.zip

or here:

https://github.com/OSI-INC/LWDAQ

> 2) The 8-second overlap still exists when exporting files with an 8-second processing interval.

I tested 10.6.11 with hour-long archives and 8-second intervals. For me it did not produce these extra files. If you are using 10.6.11 and you still see this error, then I will test again. I may need some more samples of your hour-long files. Does this problem occur with every archive, or only with some archives?

> 3) When exporting in EDF format with the latest version of Neuroplayer, the exported files use "cnt" as units instead of mVs (millivolts).

That's because you lost your Exporter settings when you updated your LWDAQ. You need to set up the conversion between "cnt" (sixteen-bit analog to digital converter counts) to mVs using the EDF setup button. See the EDF section here:

https://www.opensourceinstruments.com/Electronics/A3018/Neuroplayer.html#Exporting%20Data

You can read the EDF header from one of your older files with the Read button in the EDF Setup Panel.

> Additionally, we are not familiar with the "cnt" unit and cannot convert it to mVs.

The A3047A1B transmitters you are using have three voltage inputs with dynamic range 60 mV, 120 mV and 120 mV. This range is asymmetric about zero volts. For 60-mV, the input range is -36 mV to +24 mV. For the 120 mV, it is -72 mV to +48 mV. In the EDF setup, you set the units to "mV" and you set "min" and "max" to the two range limits. The temperature sensor entry allows you to convert the digitized temperature sensor output into centigrade, like this:

https://www.opensourceinstruments.com/Electronics/A3047/M3047.html#Thermometer

Best Wishes, Kevan

[Raphaël Nunes]

Dear Kevan,

I apologize for missing some of your previous posts; I hadn't realized there was a second page for the discussion... It turns out most of my questions had already been answered!

1) We are missing 1-second intervals as the Neurorecorder synchronizes with the computer, but the file names and lengths are consistent. Do you agree that this is the correct behavior?
I do agree that this is the correct behavior.

2) Please try the Exporter in Neuroplayer 171 and let me know if it eliminates overlap and correctly names the export files.
Thank you for addressing the issue we discussed in this update. I will provide feedback as soon as I have tested this new version.

3) Do you really mean 10.6.10?
I hadn’t seen the post mentioning version LWDAQ 10.6.11, so we installed the previous version. We will migrate to the new version as soon as possible.

4) I tested 10.6.11 with hour-long archives and 8-second intervals. It did not produce extra files for me. If you are using 10.6.11 and still see this error, please let me know. I may need more samples of your hour-long files. Does this problem occur with every archive, or only some?
I will test version 10.6.11 and check if the error persists.

Thank you very much for your help. We are grateful.

Best wishes,
Raphaël