remomueller

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.

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!

Hi Sarah,

I'll reach out to the team that released the code so they can take a look at it. The original BlockEDFLoad was created by Dennis Dean, one of our former members, and the code is available here: https://github.com/DennisDean/BlockEdfLoad/blob/master/blockEdfLoad.m

It looks like this version is slightly newer: v0.1.22 vs v0.1.0