Apnea Board Forum - CPAP | Sleep Apnea
Sleepyhead / CMS50F 8-day data offset problem - Printable Version

+- Apnea Board Forum - CPAP | Sleep Apnea (https://www.apneaboard.com/forums)
+-- Forum: Public Area (https://www.apneaboard.com/forums/Forum-Public-Area)
+--- Forum: Software Support Forum (https://www.apneaboard.com/forums/Forum-Software-Support-Forum)
+--- Thread: Sleepyhead / CMS50F 8-day data offset problem (/Thread-Sleepyhead-CMS50F-8-day-data-offset-problem)



Sleepyhead / CMS50F 8-day data offset problem - JimInPT - 09-15-2018

I'm having a problem with Sleepyhead offsetting my Contec's PulseOx data on the Overview display by 8 days - see attached screenshot, at the bottom.  Last night's data (Sept 14th) is shown on Sept 6th; I highlighted the bar's data to illustrate this.

I got my Contec monitor 8 days after starting APAP on July 23rd, and as you can see Sleepyhead is treating the first PulseOx data as aligned with July 23rd, not the 31st when I actually started using the Contec.

Does anybody know if I can adjust this to offset the PulseOx data and bring it in line?  I still have all the Contec's data files archived so I can reload them if necessary.

Thanks!


RE: Sleephead / CMS50F 8-day data offset problem - JimInPT - 09-25-2018

Just thought I'd add an addendum question - has anybody else noticed this problem or seen a mention of it in discussion threads for the new beta version now in development?  

Everything aligns just fine in the Daily view; the problem is only in the Overview tab. I find it hard to believe I'm the only one who's had this data-offset problem.


RE: Sleephead / CMS50F 8-day data offset problem - Clayto - 09-29-2018

Dear JimInPT:
I too had this issue but it can go away -- if you consistently upload your oximeter data. I had date shifts if I picked date range that started before I began uploading oximeter data. So, if you only have 3 weeks worth of oximeter recordings uploaded, you should not use a date range in the summary view that is longer than 3 weeks, or you will see the days shift left.

I have used the oximeter for 3 months now, and so that is the longest range I can view without date shifts.


RE: Sleepyhead / CMS50F 8-day data offset problem - JimInPT - 09-30-2018

(09-29-2018, 06:23 PM)Clayto Wrote: Dear JimInPT:
I too had this issue but it can go away -- if you consistently upload your oximeter data. I had date shifts if I picked date range that started before I began uploading oximeter data. So, if you only have 3 weeks worth of oximeter recordings uploaded, you should not use a date range in the summary view that is longer than 3 weeks, or you will see the days shift left.

I have used the oximeter for 3 months now, and so that is the longest range I can view without date shifts.

Wow, genius!  VERY impressive for a first post - you nailed it.  I'd never thought to use a different timeframe for viewing and you're absolutely right.

I got my APAP setup on July 23rd and the Contac oximeter July 31st and have uploaded data for both devices every single day since - if I set the start date to July 31st or later, everything looks fine.  I hope this is addressed in the new build of SleepyHead now in beta; there doesn't seem to be a direct bug-reporting link on the SH webpage.

Thank you very much - problem solved!


RE: Sleephead / CMS50F 8-day data offset problem - JimInPT - 11-05-2018

A new offset problem appeared the last two nights after Daylight Savings Time shift in the USA.  

When imported into SleepyHead, my SpO2 data starts one hour ahead of my APAP machine's data - I adjusted the time on my Contec device Sunday morning AFTER importing data from the Sat/Sun overnight DST shift and it's been left that way - both days since the shift, however, show the same 1-hour offset.

The start times for the APAP data are correct; it's the Contec data that's being moved an hour early, as if SleepyHead isn't correctly reading the times recorded for each data point even after I adjusted the Contec's clock.

Any ideas?  Thanks!


RE: Sleephead / CMS50F 8-day data offset problem - Crimson Nape - 11-05-2018

On the 'F' model, a data point's time will be based on the unit's time setting when it was recorded. You might try choosing to use the CPAP's time when importing. . . if I'm understanding you correctly.


RE: Sleephead / CMS50F 8-day data offset problem - JimInPT - 11-05-2018

(11-05-2018, 11:35 AM)Crimson Nape Wrote: On the 'F' model, a data point's time will be based on the unit's time setting when it was recorded.  You might try choosing to use the CPAP's time when importing.  .  . if I'm understanding you correctly.

IIRC, that's done by leaving unchecked the "Set Device Time/Date" option?  That's my usual setting, unchecked.  Thanks for the assist. 

I'll check data tomorrow to see if the offset persists, but since I have two days after DST change, I suspect it will.


RE: Sleephead / CMS50F 8-day data offset problem - Crimson Nape - 11-05-2018

I always had problems if I checked any of those check boxes in the download screen. They were a good idea but didn't work as planned, at least for me. To set the CMS-50's time, I had to either manually input it on the device or use SpO2 Assistant to update it. SleepyHead never worked.

It's been awhile since I've used my CMS-50 but I remember that when I imported its data, I would be given the option to use the CMS-50's time or use my CPAP's starting time. Due to clock drift between the two, I always opted to use the CPAP time.


RE: Sleepyhead / CMS50F 8-day data offset problem - JimInPT - 11-06-2018

FIXED, I think.  I'll know for sure after tonight's sleep data is gathered, after 3 days of being offset by an hour.

It was pretty dead-simple - I had to set the APAP machine's time-of-day back one hour to compensate for Daylight Savings Time change, using the Clinical Menu.  It had also slowed by about 2 minutes since I got it in late July, assuming it was set accurately by the DME.

I'm surprised the Resmed 10 doesn't keep accurate time via the cellular network, like all other cellular devices, when it's available.  Seems like an obvious firmware improvement that should be added.  Or, at least display the machine's current time on the screen, so that at a glance we could tell it's wrong.