Working to improve the lives of sleep apnea patients and researchers one commit at a time.
Boston, MA
0000-0002-7368-8374
https://github.com/remomueller
Top Topics
Recent Topics
Hi all! A new version of the NSRR gem has been released that now properly handles downloading files and folders with spaces in the path name. You can download v8.0.0 here: https://rubygems.org/gems/nsrr, or update using gem install nsrr. Also note that the NSRR website now puts quotes around paths that include spaces, ex: nsrr download "stages/original/Site Specific PSG Notes and Information/Site PSG Sensor Photos/St Lukes".
gem install nsrr
nsrr download "stages/original/Site Specific PSG Notes and Information/Site PSG Sensor Photos/St Lukes"
The NSRR gem now supports Ruby 3.0.0. To upgrade run: gem install nsrr which should get you v6.0.0 of the gem. Thanks!
Hi sasha74, I talked briefly with some colleagues here, and from my understanding, the BIOSIG extension for EEGLAB supports reading in the GDF format. From there, the program should be able to then write out to the EDF format. I'm sorry I can't provide more details than that, as I haven't done it myself, but hopefully that gives you a starting point. Let us know if this process ends up working for you as it may also help others in the future.
Hi sasha74, did you see Sara's reply to your previous post? HRV analisis from .GDF data
Hi NguyenSon, you can run it from the compiled Windows version following these instructions: https://github.com/nsrr/edf-viewer/wiki/Installing-and-Using-the-NSRR-Cross-Cohort-EDF-Viewer
Our latest update to the NSRR now requires emails to be confirmed. New users will receive a welcome email with a confirmation link, but existing users will need to confirm their email before accessing the site.
You can request a confirmation email here: https://sleepdata.org/confirmation/new
If you have any issues accessing your account, feel free to reach out to us at our support email: support@sleepdata.org.
Thanks!
Dear dong dong, tokens are account-specific and may not be shared with others (as well as data access in general). If your data request has expired, you can start a new request for data access. Also note, that anyone sharing a token would get their data access revoked as it violates the terms of the data use agreement.
Server maintenance for the NSRR is now complete. Thanks!
Hi all, just a quick note that the NSRR will be down throughout the weekend as we update our underlying server architecture. I'll post a new message here again when the server update has completed. Thanks!
I took a look through most of the EDF spec documentation and found the following for duration of a data record:
Q9. Do non-integer sampling frequencies (like 1/30 Hz) cause problems? Not necessarily. Good viewers will count samples and compare these with "number of samples in a datarecord" and in this way count how many datarecords have been passed (and consequently how many "duration's of a datarecord"). Because this is all integer computation, there are no round-off errors. This is why EDF recommends the "duration of a datarecord" to be an integer number of seconds. In the 1/30 Hz example, "duration of a datarecord" and "number of samples in a datarecord" can be 30 and 1, respectively. Or 3600 and 120, respectively. However, if a sampling frequency is 999.98Hz (for instance due to small inaccuracy of the ADC clock), 'integer EDF' would use datarecords of 50000s containing 49999 samples of each signal. Even if only one signal is in the file, there would be more than 61440 bytes in a datarecord. The official specs say that in that case the duration should be a float value less than 1s. This will inevitably cause a small round-off error in the timing. Item 10 of the programming guidelines explains that this error is negligible, even in extreme cases.
Q9. Do non-integer sampling frequencies (like 1/30 Hz) cause problems?
Not necessarily. Good viewers will count samples and compare these with "number of samples in a datarecord" and in this way count how many datarecords have been passed (and consequently how many "duration's of a datarecord"). Because this is all integer computation, there are no round-off errors. This is why EDF recommends the "duration of a datarecord" to be an integer number of seconds. In the 1/30 Hz example, "duration of a datarecord" and "number of samples in a datarecord" can be 30 and 1, respectively. Or 3600 and 120, respectively.
However, if a sampling frequency is 999.98Hz (for instance due to small inaccuracy of the ADC clock), 'integer EDF' would use datarecords of 50000s containing 49999 samples of each signal. Even if only one signal is in the file, there would be more than 61440 bytes in a datarecord. The official specs say that in that case the duration should be a float value less than 1s. This will inevitably cause a small round-off error in the timing. Item 10 of the programming guidelines explains that this error is negligible, even in extreme cases.
I may move your change to the code base if we find an influx in EDFs that do this.
In any case, thanks for all the information, definitely helps out the development of tools!