SleepyHead Qt v0.8 alpha

tetragon wrote:What was the build environment for the 0.8.7 OS X build? I haven't had a compile succeed since fcbb57ae84ec387a950977ba72b763ca0d7c5936. I'm running on an older 10.6, with an older Xcode, and Qt 4.7.4.

That one's definitely a Jimbo question, although I'm not sure if he still has a non Lion machine. :-/

I know the area of the code that's likely playing up. I'll have a look over it again..

It will be the evil code to detect the "first day of the week" to display on the calendar from the system locale.. Qt 4.8 has a magical function that just works.. The 4.7.x compatibility code hasn't been properly tested yet.. If I can't make this work, I'll drop the mac specific detection code and make it use a default week starting day on Mac with 4.7.x, and it should get things compiling again.

Alternatively, you could use the QtSDK SDKMaintainer tool to install the 4.8 RC. It runs a little faster and fixes some other Qt related bugs..

Not an easy task writing system specific code for a platform I don't have access to.

Edit: I just dropped that dodgo code, you may want to try a fresh git pull and see if it works..

jedimark wrote:I know the area of the code that's likely playing up. I'll have a look over it again..

It will be the evil code to detect the "first day of the week" to display on the calendar from the system locale.. Qt 4.8 has a magical function that just works.. The 4.7.x compatibility code hasn't been properly tested yet.. If I can't make this work, I'll drop the mac specific detection code and make it use a default week starting day on Mac with 4.7.x, and it should get things compiling again.

A quick run of git bisect suggests that the particular spew (a mere 9980) of Mac-specific errors I'm getting was introduced with 3ffbc14138e578acf6f11eb55b09c94d5b14f39c, either that or the failure was introduced earlier but couldn't be reached.

jedimark wrote:Alternatively, you could use the QtSDK SDKMaintainer tool to install the 4.8 RC. It runs a little faster and fixes some other Qt related bugs..

And is that install as stupidly massive and slow as the 4.7 SDK?

tetragon wrote:

jedimark wrote:I know the area of the code that's likely playing up. I'll have a look over it again..

It will be the evil code to detect the "first day of the week" to display on the calendar from the system locale.. Qt 4.8 has a magical function that just works.. The 4.7.x compatibility code hasn't been properly tested yet.. If I can't make this work, I'll drop the mac specific detection code and make it use a default week starting day on Mac with 4.7.x, and it should get things compiling again.

A quick run of git bisect suggests that the particular spew (a mere 9980) of Mac-specific errors I'm getting was introduced with 3ffbc14138e578acf6f11eb55b09c94d5b14f39c, either that or the failure was introduced earlier but couldn't be reached.

jedimark wrote:Alternatively, you could use the QtSDK SDKMaintainer tool to install the 4.8 RC. It runs a little faster and fixes some other Qt related bugs..

And is that install as stupidly massive and slow as the 4.7 SDK?

The latest push I just made should have fixed it..

Updating with the SDK tool is still relatively big, but not as big as the initial setup.
Half the problem is it wants to pull all the symbian garbage by default. Much better with this crud removed.. :-/

jedimark wrote: The latest push I just made should have fixed it..

89b6d09678709cf2128868ce06a3fd5aaa262345 works for me.

The latest Mac DMG on sourceforge is 89b6d09678709cf2128868ce06a3fd5aaa262345.

I've have been making a few nice improvements to SleepyHead, and I just wanted to share a progress report..

Today I completely rewrote the Oximetry tab and made work a lot better. It's no longer tied to the Contec CMS50, so later it can be expanded to support other brands.

Live View clock sync is now accurate, so if you record with USB connection, you can get sync with CPAP data.. (provided your CPAP machines clock hasn't drifted too far)

If you still can't stand the idea of sleeping with the USB cable attached, you will be able to gain a reasonable sync if you start the oximeter record mode, and turn on the cpap machine at exactly the same time. When you do a serial import in SleepyHead, it now imports the oximetery data from the time the previous days first CPAP session started.

CMS50E oximeters with a clock may or may not provide time information accurate to 1 minute with the new importer. Mine (50D+) doesn't have a clock to test it.

The Intellipap loader is coming along nicely.. I've still got a few problems with the AHI calculations, and there is still a few minor files to parse, and some missing details.. The good news is it works well enough for anyone who wants to take it for an early spin.

The Intellipap having no flow rate waveform still bums me out.. Hopefully the serial/firmware cable can be used to gain access to it? (I know it can be accessed somehow by this port, it's in the clinical manual) I'm not sure how easy it would be to sync this to the other data..

The only major component left to tackle in sleepyhead is the print/graph layout system. The rest is only smaller/easier stuff and bug fixes...
Then an actual beta. (Yay!)

/Mark

Alas, the "improvements" yew speak of are a bust. 0.8.8 Program crashes on import.

I really do like the yew been doing, though. I couldn't write this software if I tried!

ThomasMcKean wrote:Alas, the "improvements" yew speak of are a bust. 0.8.8 Program crashes on import.

I really do like the yew been doing, though. I couldn't write this software if I tried!

Is the GIT version or the one I just uploaded? :-/

EDIT: In either case, You probably need to start with a fresh SleepApp (ie, trash the old one),
the database format had to change slightly..

jedimark wrote:

ThomasMcKean wrote:Alas, the "improvements" yew speak of are a bust. 0.8.8 Program crashes on import.

I really do like the yew been doing, though. I couldn't write this software if I tried!

Is the GIT version or the one I just uploaded? :-/

EDIT: In either case, You probably need to start with a fresh SleepApp (ie, trash the old one),
the database format had to change slightly..

It offered to purge but I will try doing it manually...

...Nope. Still crashes.

K to make sure it wasn't on my end I tried importing the backup data as well and the same thing happened. Something about runtime termination. Happens when import reaches 98 or 99 percent.

Mark,
Your SleepyHead (SH) program is certainly welcomed competition to ResScan. Thanks for all your efforts. One big reason why I have now stopped using ResScan, is because I highly value the addition of oxygen saturation and pulse analysis within the same program.

My ResMed S9 data imports to SH v8.8-4 work great.

I have Contec’s CMS50EW oximeter and their Assistant program which uses *.SpO2 data files. Both the oximeter and the Assistant program work fine. I use Windows 7 Ultimate.

My problem is that I am unsuccessful with inputting the CMS50 oximetry data into SH.
I attempted to input my oximeter data in 2 different ways:
1. Import directly from the oximeter
2. Opening and selecting a spo or to spoR file. I changed the Assistant data file suffix from spo2 to do this)
In both cases, I first loaded the SD card data and then attempted to load the oximeter data

Do I have a file format problem?

Jimxx1 wrote:Mark,
Your SleepyHead (SH) program is certainly welcomed competition to ResScan. Thanks for all your efforts. One big reason why I have now stopped using ResScan, is because I highly value the addition of oxygen saturation and pulse analysis within the same program.

My ResMed S9 data imports to SH v8.8-4 work great.

I have Contec’s CMS50EW oximeter and their Assistant program which uses *.SpO2 data files. Both the oximeter and the Assistant program work fine. I use Windows 7 Ultimate.

My problem is that I am unsuccessful with inputting the CMS50 oximetry data into SH.
I attempted to input my oximeter data in 2 different ways:
1. Import directly from the oximeter
2. Opening and selecting a spo or to spoR file. I changed the Assistant data file suffix from spo2 to do this)
In both cases, I first loaded the SD card data and then attempted to load the oximeter data

Do I have a file format problem?

I've made a few bug fixes to the oximetry module over the last couple of days for the CMS50E's, to fix the import problems with this model.. The 50E has a different import process to my CMS50D+, which is purely software controlled. Next build (coming soon) will include these fixes.

Not sure what format your dealing with, but renaming files won't make it work.. Could you perhaps email me a copy of one so I can investigate?

Hi,
I too cannot import my CMS50FW (as far as I can tell, this is the "wireless" version of the CMS - if wrong, anyone, please advise!). I cannot find a way to import this .spo2 oxymetry data into SH. SH important my Resmed data very well - seamlesssly in the true sense of the word. Now if I can just get the oximetry data in there, I would be tickled pink.

If I could get the bluetooth functionality of the CMS 50FW to work, I'd be even more happy, but this appears to be impossible.

-Gasp

Gasping you'd get better responses if you started a new thread with your question. This is an old thread.

Hello..

I don't know how I missed all of this work.

Can I get a link to your latest ASV version for Windows 7 64 bit??

If a copy of my SD Card from my ASV machine would be any help I can ZIP it and send a copy to you.

Sorry about my complaining...

Rich