#232 Resmed S9 inconsistant data beyond 1 month

[Eric]

I am looking at the data for October 5th while creating 2 new users and importing a single set of data for each one.
If I load data from the Oct 15 backup of the SD card, I will get an AHI of 7.71
If I load data from the Nov 7 backup of the SD card, I will get an AHI of 2.03
Is this a bug from the S9 machine or in sleepyhead?
I created this from version 9.8 it was the same on 9.6
The user which I started in Mid August and added daily data shows 7.71.
I assume that this means the data displayed prier to July 15 is incorrect.

[Eric]

I borrowed a friends windows machine and installed ResScan.
The Nov 7 backup shows an AHI of 7.7 with ResScan.

It looks like Sleepyhead gives the incorrect data without the detailed files.

[IPS]

Yes, I have this bug too with S9 data using SH 0.9.8-1 on Windows.

[Dan D]

I also find that the calculations in SH are incorrect for days without detailed data for my S9. SH 0.9.8 on Mac 10.10.4

[Mark Watkins]

This is a known issue... It's a lot more complicated than it looks on the surface:

SleepyHead was designed to work with a per-session data model, so it could have the ability to split sessions according to how people actually sleep.. for instance, some people sleep past noon/do shift work/etc.

Summary data on Resmed S9/A10 is stored in the STR.edf record, and is bound by the limitations of the EDF file structure and ResMed's per-day summary indice model. A ResMed day being explicitly fixed 24 hour period between 12 noon and 12 noon. It records a limited number of mask on/off events (10 per day, although it gets messy around splits!), but the AHI indices and other summary data are all combined into an ugly daily lump. To make matters worse, the S9 machine deletes the data making recalculations impossible.

So to make best use of the limited summary data, ResMed users need to match ResMed's day splitting, by adjusting the Combine Session slider all the way to the left (off!) in Preferences match ResMed's model, and leaving the split time default... however it gets even more complicated, because there can be partial detail data stored for a day, which effectively makes impossible to get an accurate count that day without either ignoring the summary or detail data that is present.

When I forced ResMed users to do all of this, they sort of complained en masse because of the inflexibility that happens on normal days with actual detail data (which sadly ends up being only a few, because of ResMed's asinine once a month/7 day detail purge)... so thought some more, and added the "Don't split summary days" option which prevents summary sections being divided into partial chunks according to mask sessions... and so far, that's the best I can come up with.

So in summary: ResMed's choice to store only daily summary information in STR.edf wasn't a very good one, which leaves me between a rock and a hard place. I'm using the best of a whole bunch of bad solutions.

The best advice I can give to workaround, is make sure the SDcard is placed back into the machine after import, and import at least once a month (or better yet, once a week for flow waveform data)

[Dan D]

Thanks for the response, Mark. Thanks also for the Sleepy Head application, which is very useful.

D

[Vincent Bentley]

I have a ResMed S9 and I upload to SleepyHead every Sunday morning. I was using an earlier 32-bit .deb version of SleepyHead and didn't notice any problems.

I Git cloned the latest version for my 64-bit Ubuntu Gnome laptop and noticed that the new colour AHI graphs don't correctly show a rolling month even with a 7-day upload. I have changed my settings as advised here and will compare results over the next three weeks.

I'm not very good with ticked 'Don't do this' options, I always get confused. What should I have for 'Don't split summary days' for an S9? tick on or tick off?

Thanks.

[Mark Watkins]

The recommended setting is to keep Don't Split Summary Days ticked.. otherwise it will screw up when there is summary only data..

I am not particularly pleased with how ResMed stores summary data, it's a nightmare of an issue to work around. :/