OSCAR Data Help Needed

Thank you, OSCAR team, for doing what you guys do and for making the lives of us CPAP users so much easier. OSCAR is an invaluable tool that many of us use to be involved in our therapy and tweak settings. All the hard work is greatly appreciated.

A few days ago, I had an issue whereby Oscar wasn't reading data from my Resmed SD card because my Airsense10 Autoset somehow seemed to have corrupted the data.

When I read off my SD card (stock manufacturer card of 4GB) I was only able to read summary data for the previous night. I was also getting a prompt that the Datalog folder on the SD card that stores the data was corrupt and needs to be fixed using chkdsk (at least I believe that was from OSCAR? The prompt was in the tray).

I repaired the card using Windows, following which it is no longer was holding much detailed data except from the last 3 days-everything else since I started using the machine at end of December 2019, was just summary data.

Anyway, long story short I scanned the SD card with Windows without doing a back-up and now it only has 3 detailed sessions on it as opposed to almost 10 months’ worth.

Also as a result of trying to fix this, I reinstalled OSCAR, creating a new profile and also destroyed my profile without making a back-up, since I was juggling multiple things at the same time on my laptop (which is extremely dumb of me!).

I was able to recover the files from the SD card that I lost using file recovery software. However, it put the data in directories, and they are not in the Resmed folder/file structure that exist in the DATALOG folder.

I tried creating a few folders following the Resmed folder/naming structure adding the recovered data to them in the DATALOG folder on the SD card and OSCAR imported the sessions. However, when I view those particular dates in OSCAR, the result is really weird. It's showing bizarre graphs and also added Oximetry and pulse data which is all over the place. I do not have any Oximetry device attached to the Airsense10 and this only show up for the days that I manually created the folders and copied the data on to the SD card.

Any assistance or guidance on how I can get the data that I recovered integrated into OSCAR would be appreciated. I know it may not be possible to integrate it into the new 16GB SD Card that I am now using with the Airsense10 but as long as I can import and view it in OSCAR, that's sufficient.

Attaching a url to a couple of images.

Thank you in advance.

https://1drv.ms/u/s!AjHAB0kvkgwFgQBLf0M ... D?e=0r4C8I

Mchezaji wrote: ↑

Thu Oct 01, 2020 8:55 pm

I was able to recover the files from the SD card that I lost using file recovery software. However, it put the data in directories, and they are not in the Resmed folder/file structure that exist in the DATALOG folder.

I tried creating a few folders following the Resmed folder/naming structure adding the recovered data to them in the DATALOG folder on the SD card and OSCAR imported the sessions. However, when I view those particular dates in OSCAR, the result is really weird. It's showing bizarre graphs and also added Oximetry and pulse data which is all over the place. I do not have any Oximetry device attached to the Airsense10 and this only show up for the days that I manually created the folders and copied the data on to the SD card.

Did your file recovery software recover the file names? That can be a sticking point with recovery software. Incorrect file names could result in OSCAR misreading input as oximetry, among other errors. Without accurate file names, it would be impossible to recover. Getting all the files in the correct folders will be laborious too. At least you can cut the work in half by ignoring the .crc files -- OSCAR does not depend on them.

I suggest you just move forward with the data you have and not try to recover the old data.

And I hope you make good backups in the future. Backups are the safety net for this kind of problem.

Yes, it recovered all the file names and extensions correctly. I compared them to what's in the DATALOG folders-however it put the files in directories and not in folders following the naming convention used by Resmed.

I agree, I was very irresponsible with my data and need to be better at creating backups and reading before execute actions with software.

Including screenshots of the contents of some directories, that were recovered.

Thanks for the feedback.

BlueDragon wrote: ↑

Mon Oct 12, 2020 10:18 am

Mchezaji wrote: ↑

Thu Oct 01, 2020 8:55 pm

I was able to recover the files from the SD card that I lost using file recovery software. However, it put the data in directories, and they are not in the Resmed folder/file structure that exist in the DATALOG folder.

I tried creating a few folders following the Resmed folder/naming structure adding the recovered data to them in the DATALOG folder on the SD card and OSCAR imported the sessions. However, when I view those particular dates in OSCAR, the result is really weird. It's showing bizarre graphs and also added Oximetry and pulse data which is all over the place. I do not have any Oximetry device attached to the Airsense10 and this only show up for the days that I manually created the folders and copied the data on to the SD card.

Did your file recovery software recover the file names? That can be a sticking point with recovery software. Incorrect file names could result in OSCAR misreading input as oximetry, among other errors. Without accurate file names, it would be impossible to recover. Getting all the files in the correct folders will be laborious too. At least you can cut the work in half by ignoring the .crc files -- OSCAR does not depend on them.

I suggest you just move forward with the data you have and not try to recover the old data.

And I hope you make good backups in the future. Backups are the safety net for this kind of problem.

That data looks like it might be ok--file names and sizes look reasonable. If the first set of data were on the SD card in a folder named DATALOG\20200114, that might work. You could copy your str.edf file from the newer SD card as the str.edf file is a cumulative record. You do need the Identification.tgt file. Might as well copy the SETTINGS folder, although it may not be necessary.

What I suggest doing is just putting one DATALOG\yyyymmdd directory on your SD card and try importing that. Don't try to do all of it at once. If that works, add a bunch more directories until you find one that breaks OSCAR. Then back off and don't try to import that day.

Thanks for the insight.
Tried it and it worked-as in Oscar imported the 3 sessions for 01142020.
However, when I go and view the data in OSCAR for 01/14/20-it's the same bizarre looking stuff that I saw before.

BlueDragon wrote: ↑

Mon Oct 12, 2020 11:52 am

That data looks like it might be ok--file names and sizes look reasonable. If the first set of data were on the SD card in a folder named DATALOG\20200114, that might work. You could copy your str.edf file from the newer SD card as the str.edf file is a cumulative record. You do need the Identification.tgt file. Might as well copy the SETTINGS folder, although it may not be necessary.

What I suggest doing is just putting one DATALOG\yyyymmdd directory on your SD card and try importing that. Don't try to do all of it at once. If that works, add a bunch more directories until you find one that breaks OSCAR. Then back off and don't try to import that day.

Well, there's something odd going on; I'm not sure what. I need to do some investigation why the CPAP machine even creates the ...SAD.EDF files, which are the ones that hold oximetry data, if there is no oximetry data.

Try importing a different DATALOG day, without 1/14/2020. Do you get the same results? (You should make each test import into a new profile to minimize interaction and confusion.)

UPDATE: My conclusion is that your data has been scrambled. Perhaps even the wrong file names assigned in some cases. For example, oximetry data is held in the ...SAD.EDF files. Without having oximetry equipment, all of the values reported should be -1, meaning "ignore me -- there's no data here for this time." OSCAR then ignores the non-existent data. But your graphs show oximetry data and other data with crazy values. This suggests the possibility of file names connected to wrong data. The times on the graph don't even match to the data files as I would expect.

Do you have a way to view files in hex? If so, view the ...SAD.EDF files in the day and look at offset 0x100. For a "real" SAD file, you should see text Pulse.1s, SpO2.1s, and Crc16. What do you see?

Thanks BlueDragon. You are absolutely correct, the data is scrambled indeed. Offset 0x100 is fine but from then on there is a lot of junk scrambled data in the file.

I will try and run another recovery attempt and see if I get files with intact data. I appreciate the feedback!

BlueDragon wrote: ↑

Mon Oct 12, 2020 3:49 pm

Well, there's something odd going on; I'm not sure what. I need to do some investigation why the CPAP machine even creates the ...SAD.EDF files, which are the ones that hold oximetry data, if there is no oximetry data.

Try importing a different DATALOG day, without 1/14/2020. Do you get the same results? (You should make each test import into a new profile to minimize interaction and confusion.)

UPDATE: My conclusion is that your data has been scrambled. Perhaps even the wrong file names assigned in some cases. For example, oximetry data is held in the ...SAD.EDF files. Without having oximetry equipment, all of the values reported should be -1, meaning "ignore me -- there's no data here for this time." OSCAR then ignores the non-existent data. But your graphs show oximetry data and other data with crazy values. This suggests the possibility of file names connected to wrong data. The times on the graph don't even match to the data files as I would expect.

Do you have a way to view files in hex? If so, view the ...SAD.EDF files in the day and look at offset 0x100. For a "real" SAD file, you should see text Pulse.1s, SpO2.1s, and Crc16. What do you see?

The header is in ASCII but the data is binary, so the rest of the file will look messy. But what you are showing me is not typical for a SAD file, so the binary portion of the file does appear scrambled.