NSRR staff
Boston, MA
0000-0002-0506-8368
Top Topics
Recent Topics
Hi -- this question came up before -- https://sleepdata.org/forum/mesa-sleep-position
I'll make a note to add it somewhere in the MESA documentation as well. Thanks for checking out the site!
The technicians worked separately - each sleep recording was staged by a single technician. The group of technicians had routine meetings and quality exercises to ensure consistency over time across scorers.
You can read a bit more about the reliability/quality/consistency procedures used here: https://sleepdata.org/datasets/shhs/pages/07-reliability-shhs2.md
Thanks for being an NSRR user and for asking this question!
I see what you mean - it looks like all the EDFs received from one of the CHAT sites/beds have this quirk. Unfortunately, many PSG manufacturers do not follow the EDF specifications to the letter. Other tools like Polyman and Luna do not seem to have issue opening these files.
Based on my reading of the EDF FAQ Q8 is that you could theoretically put dummy values in the physical min/max (i.e. rewrite this part of the EDF header for affected files) to overcome this issue.
Hi sleepheart,
Thanks for being a user here. Unfortunately we (the NSRR) are only able to offer MESA data that is related to the sleep exam, which was an ancillary study to the main Exam 5. See the note here: https://sleepdata.org/datasets/mesa
MESA Sleep data are made available in collaboration with the MESA Coordinating Center. We have made polysomnography and actigraphy raw data available for download, along with key sets of MESA Sleep covariates. If you wish to access data from other MESA exams, please visit the BioLINCC MESA Collection or contact the MESA Coordinating Center.
Those resources will have their own data request processes.
Hi - thanks. Can you share more about the error? I refreshed the folder on the NSRR system (generates md5 checksums and caches filenames) and now the command appears to work:
There were some recent compatibility issues in the NSRR gem with Ruby 3.0.0 - those got patched in version 6.0.0.
Please give it a try yourself to see if the issue is resolved. Thanks for being an NSRR user and raising this issue.
You can read up on the EDF specification here:
All signal values start from the beginning of the recording, so they are aligned in that regard.
Imagine if a "data record" is 1 second and you have two signals, one that is 1 Hz and the other is 10 Hz. The first value for the first signal will represent the value between the start of the recording and 1 second (1 data record). The first 10 values for the second signal will represent 10 readings between the start of the recording and 1 second (1 data record) (put otherwise, 0-0.1s, 0.1-0.2s, 0.2-0.3s, etc.)
Hey - the viewer is here - https://github.com/nsrr/edf-viewer (other good EDF viewers include EDFbrowser and Polyman)
I will fix the link in the dataset documentation as well. Thanks for checking out the site!
Hey - thanks for checking out the site!
I believe the shhs1_tcvd variable is an indicator variable telling us whether the Tucson field site provided CVD data for a given SHHS subject. In other words, it is not a special type of CVD or cardiovascular factor. Tucson is a city in the state of Arizona. I don't know why there is only an indicator for the Tucson site and not for other sites.
Hey -- I'm glad you have found the site useful.
CFS can be used for commercial purposes.
MESA has restrictions for commercial purposes. Your data request was approved for 'mesa-commercial-use', which only includes subjects who have consented to share their data for commercial purposes.
You should be OK to proceed with your development. Always remember to cite/acknowledge the NSRR datasets as suggested in each dataset's README file. Thanks!
SHHS pages here --
https://www.sleepdata.org/datasets/shhs/pages/10-montage-and-sampling-rate-information-shhs1.md https://www.sleepdata.org/datasets/shhs/pages/11-montage-and-sampling-rate-information-shhs2.md
