SleepyHead Qt v0.8 alpha

On one Windows 7 installation with the new .dlls SleepyHead stopped running.

I had to change the Compatability Mode to "Windows xP (Service Pack3)" by right-clicking on SleepyHeadQT.exe, and choosing Properties. In the Properties dialogue, select the Compatibility tab and tick the "Run this program in compatibility mode for:" box

After that all worked well.

On another Win7 machine SleepyHead ran perfectly straight away.

I have been able to successfully build SleepyHead on Mac OSX Lion using Qt 4.8 beta. Things seem to run OK, loading and displaying daily and summary data looks OK. This however seems to be true for only the first run after building, or after deleting the SleepApp data folder. On subsequent runs of the application it usually tells me that software changes have been made and data will have to be re-imported, this although no changes to software were made between runs. If I allow it to reload the data I get nothing unless I load the data manually. A few times it seems to hang on subsequent restarts although I have not been able to reproduce this consistently enough to see what's going on.

There are some lingering ResMed data issues where it looks like perhaps the raw values from the EDF file are used and not the correctly scaled real values. I see this for sure on pressure and respiratory rate so I suspect others as well but have not checked everything. Along with the tile for each channel or parameter it would be nice to see the units displayed (ie. L/min, cmH2O, etc.) this may help if units differ from what the user is expecting them to be.

I also see screen artifacts then scrolling in the daily view. If I scroll up or down quickly I actually see parts of the welcome screen painted in the background. I have not done much with Qt 4.8 beta yet so this may be the problem but I wanted to highlight it anyhow.

tschultz wrote:I have been able to successfully build SleepyHead on Mac OSX Lion using Qt 4.8 beta. Things seem to run OK, loading and displaying daily and summary data looks OK. This however seems to be true for only the first run after building, or after deleting the SleepApp data folder. On subsequent runs of the application it usually tells me that software changes have been made and data will have to be re-imported, this although no changes to software were made between runs. If I allow it to reload the data I get nothing unless I load the data manually. A few times it seems to hang on subsequent restarts although I have not been able to reproduce this consistently enough to see what's going on.

There are some lingering ResMed data issues where it looks like perhaps the raw values from the EDF file are used and not the correctly scaled real values. I see this for sure on pressure and respiratory rate so I suspect others as well but have not checked everything. Along with the tile for each channel or parameter it would be nice to see the units displayed (ie. L/min, cmH2O, etc.) this may help if units differ from what the user is expecting them to be.

I also see screen artifacts then scrolling in the daily view. If I scroll up or down quickly I actually see parts of the welcome screen painted in the background. I have not done much with Qt 4.8 beta yet so this may be the problem but I wanted to highlight it anyhow.

Thanks Troy.. Good to know there's hope for Lion..

I think I know what's wrong with the loader issues.. In the profile.xml file, the class variable was being corrupted.. I can't remember if I pushed this change yet.. (I was using Latin strings instead of ascii with TinyXML... I may drop TinyXML for QtXML) I know I have used this in other places, so I've got to clean up.. There's a few other bits I need to Qt-ize for simplicities sake.

I've been focusing a lot on PRS1 waveform sync & ASV support, and haven't touched the ResMed code for a while.. It needs more attention.

ResMed's EDF doesn't appear to use the standard EDF logarithmic scaling.. From what I have observed it uses simple multiplier (divide by 50.0). The waveform data itself doesn't really need to convert, it's more the Y axis scale that needs adjustment..

There is definitely a bug in the Mac version of Qt with QSplitter's.. Jimbo's shown me that one with a screen capture. Perhaps override the thumb scroll event and issuing redraws may work around this..

Qt SDK works well on windows.. GIT doesn't unfortunately.. If anyone comes across a decent GIT client for windows, I want to know about it..

Mark, I got SleepyHead (on windows xp sp3) to find my oximetry data. It looks good. Thanks! I'd like a small additional feature (please put this on the list):

I'd like to be able to specify a different time zone for a particular date (or dates). For example in May I spent 5 days in England and then 8 days in California, and then another 8 days in California in June. My home time zone is Eastern Time. This would allow the data displays to be calibrated to local time.


Victor

PS. I still haven't tried to get SH to run on my macbook. When I do, which files to I need to transfer from my PC to my mac?

victormiller wrote:Mark, I got SleepyHead (on windows xp sp3) to find my oximetry data. It looks good. Thanks! I'd like a small additional feature (please put this on the list):

I'd like to be able to specify a different time zone for a particular date (or dates). For example in May I spent 5 days in England and then 8 days in California, and then another 8 days in California in June. My home time zone is Eastern Time. This would allow the data displays to be calibrated to local time.


Victor

PS. I still haven't tried to get SH to run on my macbook. When I do, which files to I need to transfer from my PC to my mac?

Victor, that time-zone thing your talking about isn't easy to implement.. Effectively, each session would need to store it's own time-zone value.. which in itself is not difficult. The tricky part is how to present the ability to change time-zone per day/session to the user, without confusing people who don't have need of this feature. On top of this, the algorithm that sorts sessions into days would need to be very time-zone aware, also not easy.

For instance, a menu option could open a dialog to convert a days sessions to a different time-zone. However, the sessions for out of zone days will sort incorrectly.. Leaving potential muck-ups on either end of the Trip.

This is a very good and useful idea, but it's not really something I can prioritize at the moment.. ie, it may have to be a version 2.0 feature.
I will put some more thought into this again later, when my brain is functioning better before pushing it back there though..

Mac stuff I know not much about.. you need to compile it at the moment, which requires Apples' XCode software, and (nokia's) Qt SDK.

I got some strange looking graphs last night. Apparently, SH decided my PRS1 Auto was a bilevel or ventilator of some sort. It showed Mask pressure, minute ventilation, and a pressure graph with pressures up to 40. I'm currently using a fixed pressure

I saved the SleepApp folder, then removed it and started SH again. I had to go through a few crashes until it finally ran OK, but now it shows me the correct graphs.

If I put the "bad" SleepApp folder back, I see the "ventilator" graph again.

I'm pretty sure the SleepApp folder was erased after I downloaded the current version, so I don't think I have any hangover from previous version databases.

Sometimes I feel like a poster boy for sleep deprivation. I just spent some time chasing my own tail from a stupid mistake.

I was loading last night's data into SH, but it simply wouldn't show me last night. Or even the day before.

I looked at the raw data on the SD card, and it was there.

I had changed from manual to auto CPAP. Maybe SH couldn't handle the transition. No, that isn't when the data stopped, I don't think.

I tried loading the data into Encore and the missing data was there.

OK, let's try removing the SleepApp directory and start again from scratch. Oh, wait. Let's really look at what I'm doing.

Turns out I was loading the data from the P Series directory I had saved to my hard drive a few days earlier, not from the SD card. i.e SH wasn't showing me the data because it wasn't there.

"Hi! My name is Archangle and I'm an apneac."

jedimark wrote:...
ResMed's EDF doesn't appear to use the standard EDF logarithmic scaling.. From what I have observed it uses simple multiplier (divide by 50.0). The waveform data itself doesn't really need to convert, it's more the Y axis scale that needs adjustment..
...

There is no need for logarithmic scaling, the physical values simply scale based on the gain and offset calculated from the difference of the physical and digital values;
Gain = (Physical Max - Physical Min) / (Digital Max - Digital Min)
Offsets are handled in a similar manner.

Each channel provides all the necessary details for digital to physical scaling in the header information.

tschultz wrote:

jedimark wrote:...
ResMed's EDF doesn't appear to use the standard EDF logarithmic scaling.. From what I have observed it uses simple multiplier (divide by 50.0). The waveform data itself doesn't really need to convert, it's more the Y axis scale that needs adjustment..
...

There is no need for logarithmic scaling, the physical values simply scale based on the gain and offset calculated from the difference of the physical and digital values;
Gain = (Physical Max - Physical Min) / (Digital Max - Digital Min)
Offsets are handled in a similar manner.

Each channel provides all the necessary details for digital to physical scaling in the header information.

!!?? That would make a lot of sense.. I didn't think these fields aren't all filled in?? or does the resulting 0 gain mean leave it alone?
EDIT: All Physical Max & Min values are 0.. ResMed are naughty
EDIT EDIT: No they are not.. I checked in a hexeditor.. toLong doesn't like floats.. :}


Offsets? Are you sure about that one? I thought my overlay markers where lining up already.. (Aren't they? :/ ) Or do you mean something else?

Normally they are supposed to fill one of the text fields explaining the scaling algorithm as per EDF specs..

Thanks Troy!

The _BRP files, which contain the high resolution data have the following channel information;

**** SIGNAL PARAMS ****
label: Flow
samples in file: 354000
samples in datarecord: 1500
physical maximum: 3
physical minimum: -2
digital maximum: 1500
digital minimum: -1000
physical dimension: lps
prefilter:
transducer:
samplefrequency: 25 40mS

**** SIGNAL PARAMS ****
label: Mask Pres
samples in file: 354000
samples in datarecord: 1500
physical maximum: 40
physical minimum: 0
digital maximum: 2000
digital minimum: 0
physical dimension: cmH2O
prefilter:
transducer:
samplefrequency: 25 40mS

As you can see from the Flow channel, there is both a gain and offset needed to provide the proper physical values. Many channels will have an offset of 0, but some do not.

I had sent you a spreadsheet back around Easter that had the details on each file, and each channel/param in each file. If you need some information to help fill in the blanks you can email me and I'll help where I can.

I don't see any channel showing a gain of 0 so I'm not sure if there may still be a possible problem with the field mappings. I have not dug into your code base to see what you did but don't expect the problem to be very big.

-Troy

tschultz wrote:As you can see from the Flow channel, there is both a gain and offset needed to provide the proper physical values. Many channels will have an offset of 0, but some do not.

I had sent you a spreadsheet back around Easter that had the details on each file, and each channel/param in each file. If you need some information to help fill in the blanks you can email me and I'll help where I can.

I don't see any channel showing a gain of 0 so I'm not sure if there may still be a possible problem with the field mappings. I have not dug into your code base to see what you did but don't expect the problem to be very big.
-Troy

It definitely helped reading floats as floats instead of ints.. I had a faulty conversion in my code that was always returning zero.

Thanks heaps for that.. Things are making a lot more sense now.

tschultz wrote:I have been able to successfully build SleepyHead on Mac OSX Lion using Qt 4.8 beta. Things seem to run OK, loading and displaying daily and summary data looks OK. This however seems to be true for only the first run after building, or after deleting the SleepApp data folder. On subsequent runs of the application it usually tells me that software changes have been made and data will have to be re-imported, this although no changes to software were made between runs. If I allow it to reload the data I get nothing unless I load the data manually. A few times it seems to hang on subsequent restarts although I have not been able to reproduce this consistently enough to see what's going on.

There are some lingering ResMed data issues where it looks like perhaps the raw values from the EDF file are used and not the correctly scaled real values. I see this for sure on pressure and respiratory rate so I suspect others as well but have not checked everything. Along with the tile for each channel or parameter it would be nice to see the units displayed (ie. L/min, cmH2O, etc.) this may help if units differ from what the user is expecting them to be.

I also see screen artifacts then scrolling in the daily view. If I scroll up or down quickly I actually see parts of the welcome screen painted in the background. I have not done much with Qt 4.8 beta yet so this may be the problem but I wanted to highlight it anyhow.

What did you do to get it to build? I downloaded and installed the latest version of QtSDK and of Xcode after downloading and installing Lion. After running qmake, when I typed make I got a bunch of warning messages saying that QtSDK doesn't support this version of Mac OS X

Despite the warnings about this version of OS X (Lion) not being supported, I ran SleepyHeadQT.app anyway. So far it appears to be running ok. Mark, you might be interested in some of the warnings coming out on the debug panel:

When I loaded my CMS50 data I got the following

Importing "/Volumes/Iomega HDD/Oximetry/SpO2"
Create CMS50 Machine Record
Create Machine: 469cb53
Warning: Error in Session->StoreSummary: Can't pack variant type "float"

WIth a ton of repeats of the last line. The graphs look ok though.

When I start SleepyHeadQT I get the following messages:

SleepyHead" "v0.8.1" built with Qt 4.7.3 on Jul 26 2011 09:23:49
Loading "/Users/victorsmiller/Documents/SleepApp/Profiles/victorsmiller/01aecd38"
Warning: vertarray bounds exceeded in gYAxis for "Respiratory Rate" graph MinY = 1.75561e+194 MaxY = 7.5203e+252 min_ytick= 100
Warning: vertarray bounds exceeded in gYAxis for "Respiratory Rate" graph MinY = 1.75561e+194 MaxY = 7.5203e+252 min_ytick= 100

I'm currently rebuilding the entire core Event system.. Has been on my todo list for a while, and I finally got a clear enough head to take it on. It basically involves ripping out SleepyHeads guts and replacing them.

I have merged Event & Waveform types into a new EventList container, events are stored in a list like waveforms, instead of a separate object for every single apnea/hypopnea/etc..

I also killed the need for a separate graphData object (which was the major cause of current crashes).. Now graphs talk directly to the new Event subsystem.. Changing between days doesn't have to copy data (apart from loading from disk into memory)

This is a lot of boring work (affecting pretty much every single component), but it frees up a lot of memory, speeds up switching between days, and most importantly will simplify the code, hopefully knocking the buggy crap dead in it's tracks.

Visually things won't change much..

It may take a few days to finish.. I'll keep you posted.

I ran 0.8.1 on Windows XP Pro x64 tonight, mostly because I needed to check my leak line and I thought it would be less of a PITA than my other options. I was right. No major problems so far. Is MaskPres displayed in tenths of an inch of water, or is that one of the scale issues you mentioned early in the thread? I haven't noticed any speed issues yet. It used 122mb of ram displaying one nights data. Windows gave it 328mb of VM. I know it's just an alpha, but I'm really psyched about how it's coming along.

Regutting the thing sounds painful, but if you've figured out a better way, you're right to bite the bullet and change it now. That will probably save you a lot of hair in the long run. May your head stay clear and the bugs be few.