Should "time correction" be optional (for those who have set a "time offset" in SleepHQ)? #19
Replies: 8 comments 7 replies
|
Question to people using the "time offset" feature on SleepHQ web site. Or is this something you set "for today" and it stays there for all days (global)? I did some research/trial, but I find their implementation extremely confusing. |
|
I went ahead and changed it a few times for a few days, and found that it "sticks" to a single noon-day only. |
|
I enabled the ability to upload to SleepHQ and did a quick session with it. I did not make a change to the existing offset of -3619 at the device level in SleepHQ. The session that showed up was exactly 1 hour and 19 seconds behind. So I went in and changed the device offset and set it to 0. It did not change the offset of previous sessions/days. I then changed the offset of today to 0 and the session looks accurate. I'll now try to enable the ring at the exact same time as starting a session and confirm that they line up. Thank you! |
|
Turns out there is another interface for Machine setting (with the time offset applied globally to the machine). |
|
So far it kind of seems like the following is true:
In summary, that would mean that users will simply need to update the Machine Settings and from there on the time-corrected EDFs from SomnoTrace will be perfectly synced (without any issues affecting the previously recorded data). |
|
It’s about my bedtime, so I will do a full test tonight with both the ring and the automatic upload. I suspect it will work just fine, thank you. It’ll certainly be great when we have the ring connected as well. |
|
This has proven to be very important to understand the correction mechanism that SleepHQ uses. |


Uh oh!
There was an error while loading. Please reload this page.
It has come to my knowledge that some people are using the "time offset" configuration in SleepHQ (to align their EDF data to pulse oximeter readings).
I'm wondering if what's going to happen once people start using SomnoTrace, which has perfect NTP-based timestamps?
Because they would need to set the "time offset" to zero (0). And that might make SleepHQ display their historical data (imported before using perfectly-timed SomnoTrace) with the drifted timestamps from the AS-generated EDF files.....
All reactions