Trouble Syncing Oximetry in SleepyHead

[windbag]

OK, tried the copy with file extension changed to .spo2 but just got the
"No Oximetry module could parse the given file" warning plus the full data path with no apparent action (as no Oximetry data is displayed in the daily tabs graphs).
I also noted that two full CPAP days were missing, despite data being in the log area.
So I did a Data/Rebuild CPAP data; was concerned about the backups warning, but went ahead & it said it proceeded OK.
Not sure it has, as one day is still missing.
Have tried copying the .spo2 file so that the total path length is shorter, but that gave the same result.
Problem is that the Oximetry data that was being shown yesterday (90 mins out of sync) is no longer coming up for the one day it had data.  

How can I tell if Sleepyhead thinks there is any Ox data been input OK?

[windbag]

I have some extra info.
Failing to import from file, I went back to the other way;
"Import Directly From A Recording On A Device"
Trouble is, yesterday's data has been overwritten, so I can't get the info back in this way.
For today's data I get the "Oximeter name is different" warning (don't understand) but it does import data.
The first way, using the log file times, the start time is correct (I deliberately started just before midnight to avoid the day problem) but the end is wrong - this time by 3 hours!
If I import the other way (sync start times), before it imports it shows a session almost EXACTLY half the actual session time.
So my guess is that the log is only half the length it expects, and/or the log interval is not what it thinks.
I THINK the actual interval is 1 data point per second; when I checked out that the new CMS50F/SpO2 Assistant software was working OK, I made a test file and tried a .csv export.
When opened in Excel, it gave the first few rows of data as:
DATE          TIME   SPO2 PULSE
01/11/2017 19:48:25 97 71
01/11/2017 19:48:26 97 71
01/11/2017 19:48:27 97 71
01/11/2017 19:48:28 97 71

Could the CMS50F version 3.7 loader module be getting either the file header wrong or assuming an incorrect log interval?
That would be consistent with both methods starting at the correct time, but the end time being wrong by an amount dependant on the total log time.

The problem with not being able to read from the .spo2 file (whatever case) is still serious, though, as data could potentially be unusable every night without it.

[pholynyk]

It looks like the way the code is written only one "." is allowed in the filename. If you used a "." in your (user.name), it would use everything after that as the extension (I think - need to add some debug code). This is a stretch, but it's all I can see so far.

I will add the "." check to my bug list. Unfortunately, I have no way to create new Windows versions for testing.

[windbag]

It looks like the way the code is written only one "." is allowed in the filename. If you used a "." in your (user.name), it would use everything after that as the extension (I think - need to add some debug code). This is a stretch, but it's all I can see so far.

I will add the "." check to my bug list. Unfortunately, I have no way to create new Windows versions for testing.

Will try renaming a file to have no "." in the middle and see if that gets around it.
In the meantime I have more info...

[windbag]

There is something very odd about the default data area for the SpO2 Assistant program.
On my laptop, the path is:
C:\Program Files\SpO2 Assistant V3.0.3\Data
It is like no other area I have come across.
In Win7 explorer (set to show hidden files), I can see 2 SpO2 files plus one demo.
When I open the same area using the Sleepyhead
"Import from a datafile... like SpO2 Review" module
I get the Sleepyhead "Select a valid oximetry data file" browser, in which
I can see *9* otherwise invisible SpO2 file entries with expected sizes that have a padlock symbol on them.
What?
Right-clicking to look at their properties, they are not hidden and are not read-only; in fact the two with no padlock show as being padlocked in the properties icon.
Weird.
I cannot copy the padlocked ones - if I try I get :
"Item Not Found - Could not find this item
This is no longer located in C:\Program Files\SpO2 Assistant V3.0.3\Data
Verify the item's location and try again.

Is this area somehow locked up by SpO2Assistant and not being "shared" ?

Whatever, it still doesn't import into Sleepyhead, just get the "No Oximetry module.."

two other points of info/query:
My CMS 50F firmware version is 3.9

What is SpO2Review? My software is SpO2Assistant

[windbag]

I took your suggestion; Import (partial) success.  
I removed all the dots and spaces in the .SpO2 filenames and lo, it imported!

The duration is still strangely wrong;
It may be relevant that the red-box import bar is 151mm (on my screen) vs the wider black box of 209mm, but says the duration (of the CPAP?) is 6h:42m.  In fact, both data sets should be this long.

At the import stage it says the correct (CPAP?) duration, but on the plots the Oximetry is 1h:51m short over a 6h:43m run (both to nearest minute).
So it is 101 mins short over a 703 min total run.

The result is the same whether I opt to use the Oxi internal clock time or sync it to start with the CPAP data.

At least the data goes in via the saved files, which shows promise.  If the duration can be fixed by either getting the log interval correct or downloading missing parts of the file, then it should be there.

If it helps, I could send you my overnight .SpO2 file, it is only about 45kB

[Sheepish]

Have you tried running the file through SPO2DateChanger?

[windbag]

Have you tried running the file through SPO2DateChanger?

I have tried briefly yesterday, but realised you needed to know the actual time it started, which I didn't at that moment. The facility would be more useful if it defaulted to starting with the the original date and time rather than the current time; it would then be trivial to change the date, which I'd guess would be the most common use.
More findings on the next post...

[windbag]

Myself and partner worked away at getting Oximeter data in. We managed to save two files with no dots or spaces that Sleepyhead said it was reading. One file did load correctly, but we don't know how we did it. When we did the same for the second, it was wrong, bearing no relation to the trace that the SpO2 software showed.
We tried purging the Oximeter data for the TWO days that had false data in, but the process also lost days of CPAP data from the overview, despite the data showing in the Daily graphs. Even after a restore it was still showing missing days, and we were getting tired, so we gave up for the evening.
It plainly CAN load data from the file, but we could not identify a reliable route to do so.

[Sheepish]

Agreed it's a huge pain the next morning  to get oximetry data to sync in SleepyHead, and it's a lot of trial and error, but you can eventually get it to work. Here's what it looks like (bottom graph in this screenshot):



A couple of random tips that may help (or may make no difference):

• In the SpO2 Assistant, under Options, choose User Information and at least give your data file a name, etc. For some reason, only after that was I then able to...
  
• Under File, choose Export (the file to a new location on another drive), rather than trying to copy the file with Windows from its (stupid) default save location.
  
• Run the file through SPO2DateChanger, referenced above. Give it the exact time you started your CPAP session you've just imported into SleepyHead, but you may need to give it a date one day after the displayed date in SleepyHead, e.g., SleepyHead's date is Fri., Nov. 3, but set the SpO2 file to Sat., Nov. 4 if you went to bed after midnight.
  
• Muck around experimenting with SleepyHead's Oximetry Import Wizard, trying different options until you get it right, and if you mess up and it doesn't sync, before you try again, you need to choose Data / Advanced / Purge Oximetry Data / Current Day ... BUT it will purge your current day's CPAP session as well, so you'll need to import that again from your SD card with File / Import Data
  

So yup, a huge pain, so I won't be wasting time doing that every day. Too bad such a cool function isn't more user friendly and bug-free. Still, kudos to the developers of all the software involved for at least making it (for free) in the first place.