SleepyHead Qt v0.8 alpha

Well, it looks like I'll be the first reporting success with the new version.

Downloaded and installed on my Eee PC netbook with no problems. I didn't remove or move the SleepApp folder. The program more or less gracefully stepped me through the process of getting stuff loaded. I did have to reimport the data, which is a pretty trivial thing to do. I was pleased to see that my (noncritical) journal entries were still there after redown loading the data from my back up copies (for the old machine) and the SD card (for the current one).

The touchy video card in my Eee PC continues to cause a problem with the graphs when the computer goes to sleep---but simply toggling between "full screen" and "not full screen" brings the graphs back. So this is no longer a problem.

Tried to "print" a report to a file and everything hung. I had to quit SleepyHead to get out of the situation. Couldn't test whether I could print to a printer because we don't have a working printer at home.

And the Usage graph on the Overview graphs has a couple of flaws: First the x-axis scale does not correspond to the dates of the bars as shown by moving the mouse across them. In other words, the bar over Aug. 30 on the time scale shows up as Aug 30 according to what pops up when the mouse is moved over that bar. Second, there are a number of (recent) days where Usage in the Overview graph is incorrectly listed as 1 hour, but Usage in the Daily Data for the day shows up correctly (and is much larger than 1 hour). Some, but not all, of those days a nights with large gaps in the run time due to overnight drives and the gaps correspond to when I was driving (without the hose on my nose obviously). And a comment: It's hard to get a good idea on the accuracy of the res of the usage times in that overview graph because the usage on the Daily Data is in hours:minutes format and the usage on the Usage graph is simply in hours---i.e. 6:58 gets recorded as 6.97. Also it's not clear (at all) if the Overview data labeled as Aug 30 actually corresponds to the Daily Data labeled for Aug 30 (night of 8/30 - 8/31) or the data labeled Aug 31 (night of 8/31 -8/30). In my quick scanning, it appears that the bar for Aug 30 really corresponds to the night of 8/31 - 8/30 since the usage for both 8/29 - 8/30 AND 8/30 - 8/31 are nowhere close to the time listed in the bar labeled 8/30. But the usage data for 8/31 - 9/1 is right on the button.

Mark, Keep up the good work! I did a git pull last night and built SH 0.8.5 on my macbook. I reimported all of my old data from the PRS1 data card and all the spor files for the cms50e. There still is the bug that the times given in the oximetry data ignores the start time on oximeter, but instead uses the time of importation for starting the time. But this morning, I imported by oximetry data and got a really weird result:



By contrast, here's the Oximetry report for the same data from SPO2 Review on Windows:



If you send me a private message I can send you the spor file in question.

Victor

robysue wrote:Well, it looks like I'll be the first reporting success with the new version.

Downloaded and installed on my Eee PC netbook with no problems. I didn't remove or move the SleepApp folder. The program more or less gracefully stepped me through the process of getting stuff loaded. I did have to reimport the data, which is a pretty trivial thing to do. I was pleased to see that my (noncritical) journal entries were still there after redown loading the data from my back up copies (for the old machine) and the SD card (for the current one).

The touchy video card in my Eee PC continues to cause a problem with the graphs when the computer goes to sleep---but simply toggling between "full screen" and "not full screen" brings the graphs back. So this is no longer a problem.

Tried to "print" a report to a file and everything hung. I had to quit SleepyHead to get out of the situation. Couldn't test whether I could print to a printer because we don't have a working printer at home.

And the Usage graph on the Overview graphs has a couple of flaws: First the x-axis scale does not correspond to the dates of the bars as shown by moving the mouse across them. In other words, the bar over Aug. 30 on the time scale shows up as Aug 30 according to what pops up when the mouse is moved over that bar. Second, there are a number of (recent) days where Usage in the Overview graph is incorrectly listed as 1 hour, but Usage in the Daily Data for the day shows up correctly (and is much larger than 1 hour). Some, but not all, of those days a nights with large gaps in the run time due to overnight drives and the gaps correspond to when I was driving (without the hose on my nose obviously). And a comment: It's hard to get a good idea on the accuracy of the res of the usage times in that overview graph because the usage on the Daily Data is in hours:minutes format and the usage on the Usage graph is simply in hours---i.e. 6:58 gets recorded as 6.97. Also it's not clear (at all) if the Overview data labeled as Aug 30 actually corresponds to the Daily Data labeled for Aug 30 (night of 8/30 - 8/31) or the data labeled Aug 31 (night of 8/31 -8/30). In my quick scanning, it appears that the bar for Aug 30 really corresponds to the night of 8/31 - 8/30 since the usage for both 8/29 - 8/30 AND 8/30 - 8/31 are nowhere close to the time listed in the bar labeled 8/30. But the usage data for 8/31 - 9/1 is right on the button.

Good observations there

XTickers are complicated, in that they have no knowledge of what's actually drawn in the other layer.. Very very hard to get this neat without the xtickers know everything the barchart knows.. It requires a fair bit of hacking to get right..

You may need to play with the session merge values in Preferences.. SleepyHead now defaults to the boring Encore/Resmed way.. However, I need to make it rebuild some cache values when the sliders are adjusted.. (which is being worked on, it _should_ kinda work until then.)
EDIT: I don't need to rebuild those cache values, they are tied to individual sessions rather than days.. Yay.. less work for me

Decimal hours do indeed suck.. I only just noticed I forgot to convert them :-}

Each bar (or empty space) represents one physical day according to the Daily screens calendar.. The xtickers are currently positioned on the left side of the bar, and the minor ticks currently have no meaning.. The dates represent the physical 24 hour boundaries, and not the actual data's starting date (which may span differently). The popup should match the value on the left side of the bar.. (If it is not, there is a UTC related timezone error) The plan is I will offset the bar width by half a bar, and it will line up correctly.

victormiller wrote:Mark, Keep up the good work! I did a git pull last night and built SH 0.8.5 on my macbook. I reimported all of my old data from the PRS1 data card and all the spor files for the cms50e. There still is the bug that the times given in the oximetry data ignores the start time on oximeter, but instead uses the time of importation for starting the time. But this morning, I imported by oximetry data and got a really weird result:



By contrast, here's the Oximetry report for the same data from SPO2 Review on Windows:



If you send me a private message I can send you the spor file in question.

Victor

Hmmm.. Recently some changes were made for Qt 4.6 compatability.. Perhaps they broke the UTC code.. I need to look over it again..

Oximetry is getting a bit neglected while I work on finishing Daily & Overview off, along with the new print code.. :-/

victormiller wrote:Mark, Keep up the good work! I did a git pull last night and built SH 0.8.5 on my macbook. I reimported all of my old data from the PRS1 data card and all the spor files for the cms50e. There still is the bug that the times given in the oximetry data ignores the start time on oximeter, but instead uses the time of importation for starting the time. But this morning, I imported by oximetry data and got a really weird result:



By contrast, here's the Oximetry report for the same data from SPO2 Review on Windows:



If you send me a private message I can send you the spor file in question.

Victor

I think you have more than one sp02 file in your data folder; or you imported two files on the same day? The importer is attempting to bring all of the data files it can find but assigning each to the import time; you can see the second section of import in SH is the same data essentially as in the SpO2 Review, only compressed. The importer needs to be rewritten or cleaned up so each imported data file gets assigned to the proper start time. I'm not sure in the graphing section of SH, how it decides what time range of oximetry data to display.

milw wrote: I think you have more than one sp02 file in your data folder; or you imported two files on the same day? The importer is attempting to bring all of the data files it can find but assigning each to the import time; you can see the second section of import in SH is the same data essentially as in the SpO2 Review, only compressed. The importer needs to be rewritten or cleaned up so each imported data file gets assigned to the proper start time. I'm not sure in the graphing section of SH, how it decides what time range of oximetry data to display.

The algorithm that decides what day a session belongs to is being fed misinformation here.. Unfortunately .spoR files don't always contain a valid timestamp (CMS50D+ for instance), and all the importer has to go on is the filenames date component - and this time is set as the time of import by Spo2Review.. which is not particularly helpful.

As for structure, each individual imported file is kept in it's own session record. Sessions are grouped during each time SleepyHead starts into day records, depending on the split parameters in preferences (default is 12 noon split)

The graphing system is supplied the day record each time a new calender record is selected.. it it works directly off the session lists.. (rather than double handling, it actually works much faster this way)

.spoR importing kinda got a bit neglected when the serial module came about.. Which also needs a rewrite to support multiple brands of serial oximeters (including the SPO5000)

CMS50 serial importing is currently being help up by a length code that still needs deciphering for longer sessions. The devices themselves don't appear to supply a timestamp to Spo2Review (I've seen the serial transfer logs for CMS50D+ & 50E models, the traffic looks the same apart from packet size) I'm not sure where SPO2Review even gets it's timestamps from, unless it's packed somehow into that crazy length field.
As for length field, I can keep reading until it's done, and get the data that way, but it's nice to give a progress bar.

victormiller wrote:I did a git pull last night and built SH 0.8.5 on my macbook.

You might want to git pull again. Mark may have pushed a lot since "last night," depending on your TZ.

archangle wrote:Printing doesn't work for me.

No printers are shown in the print dialog other than "add a printer", which gives the message "Windows can't open "add printer" The local print spooler service is not running. Please restart the spooler or restart the machine."

Going into the Find Printer dialog only shows "networked" printers, and all mine are USB connected.

I'll tinker with my machine and print spooler setting later when I can reboot.

Mea culpa. It was Comodo sandboxing the application. SH worked fine in the sandbox until printing was added.

After I told Comodo to not sandbox SH, the printing menu comes up as expected.

archangle wrote:

archangle wrote:Printing doesn't work for me.

No printers are shown in the print dialog other than "add a printer", which gives the message "Windows can't open "add printer" The local print spooler service is not running. Please restart the spooler or restart the machine."

Going into the Find Printer dialog only shows "networked" printers, and all mine are USB connected.

I'll tinker with my machine and print spooler setting later when I can reboot.

Mea culpa. It was Comodo sandboxing the application. SH worked fine in the sandbox until printing was added.

After I told Comodo to not sandbox SH, the printing menu comes up as expected.

Ah ok.. I take it Comodo is some kind of security software? I'm a little out of the loop lately.

jedimark wrote:Ah ok.. I take it Comodo is some kind of security software? I'm a little out of the loop lately.

Yes, Comodo is pretty good free security software. A little more configurable than some of the other programs. Perhaps a little less newbie friendly than some programs, more configurable for us professional paranoids.

comodo.com.

It has multiple components, firewall, antivirus, "defense plus", and "sandbox."

The later two limit the programs from doing certain interprocess things, modifying system files, etc.

I've got the security set pretty tight, and frequently have to tweak things to allow programs to run.

Note: I do NOT think SleepyHead is doing anything "wrong." It's just that I have Comodo set to lock things down pretty tightly. Lots of legitimate programs won't run in Comodo's sandbox.

(Background, I'm a computer geek by nature and profession, so tell me what info you need and where it needs to go and I can get it, I just don't know what you need )

So I installed the latest SH on Wednesday to get data for my (then) machine, and it worked marvelously (Your services to the world are appreciated, seriously, this software is awesome!)

So marvelously, in fact, that it gave me enough information to get a new machine (after a mild argument...).

So, I now have a ResMed S9 VPAP™ Auto BiLevel Machine, with new mask and etc. And after a lovely night's sleep (seriously, the thing rocks, and rocks serious awesome...I can't recommend it highly enough) I went to download my newly acquired data to see if the numbers matched up with my perception.

Unfortunately, SH keeps crashing trying to read the card. It looks like it recognized that it was a ResMed card, it created the machine correctly (or so said the message), but in the middle of the download, it crashed out with an error that basically said that the program asked to close in a weird way (I'm not home, I can get the exact error message this evening US East Coast time).

Windows 7, up to date in terms of patches, decently powerful PC, SD reader built in, the card itself is readable by the machine with no issue, I can browse it to my heart's content. Nothing terribly fancy in terms of software loaded onto it or anything.

It's quite possible the machine is too new so SH isn't there yet, that's cool if that's the case, what can I do to help with that?

UNsure if this will be helpful or not, however...

I managed to get SH to work for my machine, but I had to delete (well, move, actually) the data file that had been created in my users directory with the old machine. Once I got there, we were golden.

Don't know what's up with that, but I'm working again!

AlanMacNeill wrote:(Background, I'm a computer geek by nature and profession, so tell me what info you need and where it needs to go and I can get it, I just don't know what you need )

So I installed the latest SH on Wednesday to get data for my (then) machine, and it worked marvelously (Your services to the world are appreciated, seriously, this software is awesome!)

So marvelously, in fact, that it gave me enough information to get a new machine (after a mild argument...).

So, I now have a ResMed S9 VPAP™ Auto BiLevel Machine, with new mask and etc. And after a lovely night's sleep (seriously, the thing rocks, and rocks serious awesome...I can't recommend it highly enough) I went to download my newly acquired data to see if the numbers matched up with my perception.

Unfortunately, SH keeps crashing trying to read the card. It looks like it recognized that it was a ResMed card, it created the machine correctly (or so said the message), but in the middle of the download, it crashed out with an error that basically said that the program asked to close in a weird way (I'm not home, I can get the exact error message this evening US East Coast time).

Windows 7, up to date in terms of patches, decently powerful PC, SD reader built in, the card itself is readable by the machine with no issue, I can browse it to my heart's content. Nothing terribly fancy in terms of software loaded onto it or anything.

It's quite possible the machine is too new so SH isn't there yet, that's cool if that's the case, what can I do to help with that?

Hmm.. Very likely the case.. You can drag the debug window at the bottom all the way up before importing, and sometimes catch a glimpse of where it's messing up..

If it's happening once import is complete, it could be a video driver issue from vertical fonts again (I thought that issue was resolved, but check for an graphics driver update if this is the case?)

If it's happening during import, it will be something strange happening with an unknown code.. The EDF parser is generic, so it will just be in the bit of ResMed code that maps them to sleepyhead data channels.

I'll PM you my email if you have any debug logs, example data, etc, that may help resolve this..

AlanMacNeill wrote:UNsure if this will be helpful or not, however...

I managed to get SH to work for my machine, but I had to delete (well, move, actually) the data file that had been created in my users directory with the old machine. Once I got there, we were golden.

Don't know what's up with that, but I'm working again!

Old data in SleepApp folder is a pain..

Because this is still alpha, the format still is being tweaked. If it was beta I would be taking a bit better care to make sure updates don't mess up, but I really need the freedom at this stage to do this, or I wouldn't get much done at all.

I'm currently working on some data definition code/schema stuff to help with this in future.

The good news is I feel the first beta is getting close

Can you define what you mean by "close"? A couple of weeks? A couple of months? Not that I will hold you to whatever you say!!!