SleepyHead 0.9.1 Official Beta Release

I got that 0.9.2 windows update online again..
This time I made sure the update can update next time around... which it could last nite too.. I was too doughy to recognize a new update feature was actually working as it was supposed to

To upgrade from 0.9.1, simply click on Help->Check for Updates, and click the "Upgrade Now" button.

Before anyone reminds me.. Remind Me Later button doesn't work yet.. It's probably superfluous anyway.. just click "No Thanks" if you don't want to update yet.. (But I don't recommend doing that with this particular update)

It fixes most bugs reported so far with the beta, and adds a couple of new things.. (namely Zeo CSV importer with basic Sleep Stage line graph, and an option to set whether you prefer Median, Avg, 90/90%, True max or 99%)

This new version also has an option that allows advanced testers to get at future updates earlier.. so they can be tested better before being unleashed on those of you who'd prefer it was a little more stable..

ZEO users may want to hold of till later with that update, as I'm in the middle of making some improvements.. (No reason not to grab it and try)

I just noticed there are several different formats of ZEO csv data, so I need to making a few changes to the importer.

Edit: And these ZEO changes are done already.. I uploaded 0.9.2-1 so anyone with a ZEO who wants to can play with it.

DrPepper00 wrote:
I noticed that SleepyHead Statistics page does not list the pressure settings for my S9. Should it? Is SH supposed to read them from the card? My machine is not scoring my events. Of 9 sessions, it has only shown events on one. I am wondering if the pressure reporting problem is another machine defect. I have a call in to my DME about the lack of events.

Is yours an American machine?

I had to add support for French & German machines... The signal names in the EDF are different.. :-/

My machine was made in Australia, but I am in the US. There is something wrong with the machine. See my post about the 0 event mystery. If it weren't for SH reports, I wouldn't know I wasn't registering any events. Thanks for your work.

jedimark wrote:

peterg wrote:on an older IBM T42 Thinkpad 1.7Ghz with 1Gb RAM I had semi-lockup on the oximeter page 3d cube , I had to turn off animations in the preferences to get a clear Browse for Spor.

is Spor oximeter file browsing only single file? or does it handle a folder selection for that (I havent tried)
would be handy to do multiple (as the processing is now lightning quick)... I'll also look into manually putting the SPor files into the Spleepyhead location.

another round of applause from me for your good works , small donation pending.

You can probably still mass import .spoR data via the main Import used to pull CPAP data.. hunting down Spo2Reviews directory is not pleasant..
I seriously don't recommend this method, as the main purpose of it in SleepyHead to sync with CPAP data.
(In fact this mass import code is technically deprecated, Spo2Review data is basically worthless without a timestamp. )

The best way to get your oximeter data to sync with CPAP in SleepyHead is to start the oximeter recording at the exact moment the cpap machine switches on the first time in the night.. The next day, do a USB import right after importing CPAP data, and SleepyHead will pick the CPAP starting time as the time the oximeter was switched on..

I have not had anyone report if the current oximetry module works with CMS50E/F's yet.. (other than Live view, which is not as accurate as the above mentioned method. (due to both CPAP clock drift, and the difference from the PC's clock))

Edit: I'm glad I added the option to turn the cube off.
Edit Edit: Although I doubt the cube caused it... Sounds like an event queue hang from something breaking in the spo2 importer.. The cube only draws when it's got nothing else to do.

I might have got it busy first, but the issue user wise was that when I clicked on the Import Spo2 button, the file location browser was ghosted/ not clear / crazy . perhaps if the system is busy,, greying out and disabling that button so I dont make it busier still. as I cant recall the exact operations, I'm not much use here for lack of specific details , but it shouldnt happen in any case (in a perfect software world). in the old microsoft world it would be the blue screen of death, so anything is better than that (except the blue screen of death in a world without hard reboots).

DrPepper00 wrote:

DrPepper00 wrote:
I noticed that SleepyHead Statistics page does not list the pressure settings for my S9. Should it? Is SH supposed to read them from the card? My machine is not scoring my events. Of 9 sessions, it has only shown events on one. I am wondering if the pressure reporting problem is another machine defect. I have a call in to my DME about the lack of events.

Is yours an American machine?

I had to add support for French & German machines... The signal names in the EDF are different.. :-/

My machine was made in Australia, but I am in the US. There is something wrong with the machine. See my post about the 0 event mystery. If it weren't for SH reports, I wouldn't know I wasn't registering any events. Thanks for your work.

An easy clue to prove it's not recording properly is all your xxxxxxx_EVE.edf files in your DATALOG folder will be of the same size.. empty ones are around 548 bytes in size (-ish, it may depending on machine.)

If there are bigger ones, find the biggest xxxxxxxxx_EVE.edf file , it might give some clues.. (either look with a hex/file editor, or PM me for my email and I'll have a look for you)

Am I missing something? Is there a way to get the oximetry graphs on the daily tab? Or will O2 and the Zeo always be on separate tabs?

Pugsy wrote:

cpaptex wrote:What is the Vibratory Snore #2 all about?

Apparently the machines score 2 different types of snores but only one type causes any response in an APAP machine (it will try to fix them with more pressure). I assume that it is because the sound may be associated with a small reduction in flow and the machine associates it with an event precursor.

Just what the #1 snore does or is...we don't really know. Robysue has a detailed explanation somewhere that goes into more detail but in the end we don't have a perfect explanation as to the differences and why they are reported as such. It is never explained in any of the Encore software literature.
All we know is that it is there.

BTW...my machine will flag these even when it isn't me.. It catches my little Pug dog's snores when he sleeps with his chin on my shoulder up by my head. So the machine is super sensitive to sounds.

Since snore number # 2 seems to trigger the APAP machines trying to fix things and number #1 it doesn't do anything (so we assume not so important) #2 snores are reported in SH software.

You have it backwards, pugsy.

SleepyHead's VS's are the ones that the Autos respond to by raising pressure. VS #2's are recorded regardless of whether the machine is in auto mode or fixed pressure mode. In Auto mode, the machine does not seem to respond to VS #2s.

The known differences between a VS and a VS #2 are what we can determine from the SH reports. They include these facts:

• only the Autos record VS's; both Autos and fixed pressure machines record VS #2's
• the Autos record VS's only when running in auto mode
• the Autos increase pressure when the machine detects even a single VS, but pressure is not raised when the machine detects VS #2's
• in Encore Pro, the VS's show up as tick marks on the wave form data, but the VS #2's do not show as tick marks on the wave form data; the VS #2's do show up in the Encore Events table in both Encore Viewer and Encore Pro.

But as to what actually distinguishes a VS from a VS #2 and why the Autos don't respond to the VS #2's is anybody's guess. I haven't been able to find out any information from perusing the PR web pages or by googling information about the PR Auto algorithm. Maybe it's the noise level? Maybe it's got something to do with the frequency of the vibrations?? Who knows?

I certainly haven't been able to figure out what characteristics of your basic snore cause it to get flagged as a VS instead of a VS #2. But I don't think its just the noise level because I can make my BiPAP Auto increase that EPAP almost at will while I'm awake making "purring" noises that are similar to my night time snoring. These purring noises are not loud by any means, but I can "feel" them in my throat in a peculiar way. (Oddly enough, conscious relaxation in yoga classes triggers these "purr-snores" even when I know I'm awake; that's how I'm beginning to sort out what they feel like inside my throat.)

Edit.. maybe we could get Robysue to add her Snore explanation to the SH tutorial under construction thread...then I would have it handy and we can add it to the final tutorial. She explains it in much better detail than I do.[/quote]I'll get around to doing it this weekend.

Jedimark,

My oh my, but you've been the busy beaver lately. Things are looking really good in 0.9-beta. I just did an update to the 0.9.2 test version since I like to play with things AND because you wrote:

jedimark wrote: It fixes most bugs reported so far with the beta, and adds a couple of new things.. (namely Zeo CSV importer with basic Sleep Stage line graph, and an option to set whether you prefer Median, Avg, 90/90%, True max or 99%)

I noticed that in the preferences you now allow the user to choose from Median, Weighted Average, and Normal Average for the Middle calculations. Seems like the earlier versions of SH were using Weighted Average for the middle calculations. Is that correct?

The mathematician in me wants to know: How are you calculating the "Normal Average" and the "Weighted Average" when a user chooses one of these options? If you can give me the nice technical details, I'll be able to translate this in to language that a non-math type user can understand when they are trying to make a decision about which "Middle Calculation" to use.

Also--curiosity makes me ask: How are you computing the median (50%), and the 90% and 95% figures?

I've got one bug to report: SH 0.9.1 and SH 0.9.2 both have a handful of days where each and every event got listed twice in the Events tab and hence the AHI computation is double what it should be. But SH 0.8.* showed these days correctly. Sometime over the weekend I'll try to file a proper bug report over at sourceforge.

A final observation: In SH 0.8.* the average, 90%, and max AHI/hour statistics were listed in the left sidebar along with all the other statistics. That row is missing in SH 0.9. Is that a conscious decision on your part or just an omission?

Lizistired wrote:Am I missing something? Is there a way to get the oximetry graphs on the daily tab? Or will O2 and the Zeo always be on separate tabs?

You click the save button, and it saves the data to a session record.

But first, how are you getting the data.. Direct USB import? USB live view? or loading via the open .spoR button?

If your doing a Direct USB import, and you have already imported your CPAP data for the day, and you started the oximeter recording and CPAP machine at the same time, you can just click save.. You will have perfect sync without having to get your hands dirty.

Recording via Live view should work too, however it does not take CPAP clock drift into account.. You may need to adjust the time a few minutes either way to counter for this. (You can open oximetry sessions again and alter the time, by clicking on the session ID in details tab in daily view, editing, and then resaving)

If your loading a .spoR, you might have to adjust the session time manually (there is not an optimal way of dealing with this yet)

Bulk importing is not supported anymore, as the idea of SleepyHead's oximetry support is to get the data to sync up, and spo2Review does not give real time-sync information (so a bulk import would just screw up)

Just remember you will always have a better chance of sync if you start the CPAP machine and oximetry device recording at the same time..

robysue wrote:Jedimark,
My oh my, but you've been the busy beaver lately. Things are looking really good in 0.9-beta. I just did an update to the 0.9.2 test version since I like to play with things AND because you wrote:

jedimark wrote: It fixes most bugs reported so far with the beta, and adds a couple of new things.. (namely Zeo CSV importer with basic Sleep Stage line graph, and an option to set whether you prefer Median, Avg, 90/90%, True max or 99%)

I noticed that in the preferences you now allow the user to choose from Median, Weighted Average, and Normal Average for the Middle calculations. Seems like the earlier versions of SH were using Weighted Average for the middle calculations. Is that correct?

Yes..

The mathematician in me wants to know: How are you calculating the "Normal Average" and the "Weighted Average" when a user chooses one of these options? If you can give me the nice technical details, I'll be able to translate this in to language that a non-math type user can understand when they are trying to make a decision about which "Middle Calculation" to use.

For normal average just just means the sums divides by the count of samples or events.. rather boring.

Weighted Average just uses the summed times between events, or the sample rate*count for linear waveforms as weight to the average..

Also--curiosity makes me ask: How are you computing the median (50%), and the 90% and 95% figures?

All percentile figures in sleepyhead are calculated by a single function (technically two, one for day records, and one for date ranges, same algorithm though)

It first combines the counts for each different value for the signal (I call them channels) for all sessions that have been sorted to that day.
A weighted percentile is then calculated using this count data. (which is effectively a standard percentile, as the weights are simple counts)

Poorly described here
http://en.wikipedia.org/wiki/Percentile ... percentile

The count values are cached during import and stored in the session summary files to make these calculations faster (which is part of the reason initial import is rather slow.)

There is an important catch here for ResMed users.. On days where no event or graph data exists, these cached counts are manipulated so the percentile algorithm can calculate the only percentile data available in the STR.edf summary file, which only stores Median, 95% and 99.5% (and incorrectly calls it max.) If you try pulling a different one in these cases, it will not be accurate.. Not an optimal solution, but I don't see any other way.. That's why I recommend ResMed users stick to Median, 95% and 99% instead of true max.. (the alternative is losing this data source for missing days)

I've got one bug to report: SH 0.9.1 and SH 0.9.2 both have a handful of days where each and every event got listed twice in the Events tab and hence the AHI computation is double what it should be. But SH 0.8.* showed these days correctly. Sometime over the weekend I'll try to file a proper bug report over at sourceforge.

Damn, someone else is experiencing this too.. That one I consider hyper-critical. I badly need to replicate this

A final observation: In SH 0.8.* the average, 90%, and max AHI/hour statistics were listed in the left sidebar along with all the other statistics. That row is missing in SH 0.9. Is that a conscious decision on your part or just an omission?

Someone suggested it was confusing for new users.. :-/
I kinda liked it because it indicated the severity of clusters.. (Which I get a lot of)
I think I'll add an option to add it back..

I hope the above calc stuff made sense.. I'm foggin out..

robysue wrote:I've got one bug to report: SH 0.9.1 and SH 0.9.2 both have a handful of days where each and every event got listed twice in the Events tab

That may be a residual problem left over from the transition from 0.9.0 to 0.9.1. I experienced the same thing until I deleted my SleepyHeadData folder and subsequently used 0.9.1 to create a fresh profile and reimport all my data from my backup (NOT from the SH backup!). Something to do with the original compression scheme leaving duplicate .edf and .edf.gz files, for which the only solution was to wipe out all data and rebuild from scratch with 0.9.1 or 0.9.2. (Mea culpa; I jumped the gun with a premature release - dirty minds! - of 0.9.0.) It would be useful to know whether using 0.9.2 to delete the SleepyHeadData folder, create a fresh profile, and reimport data from a non-SH backup solves the duplicates problem for you. If so, then the bug has already been fixed but the problem appears to persist because the bug left you with messed-up data. If not, then your duplicates problem is not the same one that I had. The best way to determine whether it is the same problem is to test whether the solution that worked for me - i.e. delete the SleepyHead folder, create a fresh profile, and reimport data from a non-SH backup - works for you.

robysue wrote:I've got one bug to report: SH 0.9.1 and SH 0.9.2 both have a handful of days where each and every event got listed twice in the Events tab and hence the AHI computation is double what it should be. But SH 0.8.* showed these days correctly. Sometime over the weekend I'll try to file a proper bug report over at sourceforge.

Silly question: If you create a test profile and import again, do the same days show the duplicates?

Also, are you importing your older machines.. Could these screw-ups be near crossover points?

If not I really wouldn't mind seeing if I can replicate it.. (I think I still have some of your data in my test stash already, but it's fairly old..)

I think I forgot to add to the feature list of 0.9.2... Delete profiles now works from the login screen.. Great for trashing temporary test profiles, but use with caution..

Breathe Jimbo wrote:

robysue wrote:I've got one bug to report: SH 0.9.1 and SH 0.9.2 both have a handful of days where each and every event got listed twice in the Events tab

That may be a residual problem left over from the transition from 0.9.0 to 0.9.1. I experienced the same thing until I deleted my SleepyHeadData folder and subsequently used 0.9.1 to create a fresh profile and reimport all my data from my backup (NOT from the SH backup!). Something to do with the original compression scheme leaving duplicate .edf and .edf.gz files, for which the only solution was to wipe out all data and rebuild from scratch with 0.9.1 or 0.9.2. (Mea culpa; I jumped the gun with a premature release - dirty minds! - of 0.9.0.) It would be useful to know whether using 0.9.2 to delete the SleepyHeadData folder, create a fresh profile, and reimport data from a non-SH backup solves the duplicates problem for you. If so, then the bug has already been fixed but the problem appears to persist because the bug left you with messed-up data. If not, then your duplicates problem is not the same one that I had. The best way to determine whether it is the same problem is to test whether the solution that worked for me - i.e. delete the SleepyHead folder, create a fresh profile, and reimport data from a non-SH backup - works for you.

^^^ This.. I forgot all about this.
EDIT: That whole mess was from the backup folder compression stuff.. For a while it was creating a backup file without looking if an uncompressed version was already there.. and vice versa with compression switched off.

jedimark wrote:I forgot all about this.

We won't hold it against the sleep-deprived.

I have a question about updating from 0.9.1 to 0.9.2. I get a "failed" message and a note that "something went wrong with upzipping" and to manually install the update. How exactly do you manually install the update?
Thanks very much.
Haztek