Data / Settings on ResMed S9 Escape

While, there are numerous threads about the lack of data stored by the S9 Escape, not just in respect of the data files on the SD card, but also the lack of appropriate hardware inside,, I would still be interested whether anyone can tell me the function of the 12 files in SETTINGS (and how their corresponding .crc files are calculated).

However, my main hope is to extract the daily data from the STR.edf file (presumably - the only file updated on a daily basis, other than MGL.tgt in SETTINGS). I have tried SleepyHead, but it just hangs my Vista system - and I'm just as happy writing something basic myself, if I have the details.

(I've found text in STR.edf, presumably EDF+ entries, for overall info, but not for the daily summaries)

Obviously it would be nice to persuade the Escape to divulge more information, but just getting what it has would be interesting.

Any ideas appreciated.

You need ResScan to gather the data that the Escape gathers which is hours of use only. That's it.
Sleepyhead can't even give you hours of use because it needs the other files that are missing on the Escape because of the way that SleepyHead works. SleepyHead needs those other files to do its calculations...ResScan doesn't.

Thanks - it's helpful to know.

I don't have access to ResScan, so if anyone knows the STR.edf file structure for the daily data (assuming that it is hidden there on the end) I'd be interested to know.

The Escape simply does not gather any data beyond hours of use.
Check your private messages as I sent you some information on ResScan.

But you can't get what the machine doesn't gather.

exbucks wrote:While, there are numerous threads about the lack of data stored by the S9 Escape, not just in respect of the data files on the SD card, but also the lack of appropriate hardware inside,, I would still be interested whether anyone can tell me the function of the 12 files in SETTINGS (and how their corresponding .crc files are calculated).

However, my main hope is to extract the daily data from the STR.edf file (presumably - the only file updated on a daily basis, other than MGL.tgt in SETTINGS). I have tried SleepyHead, but it just hangs my Vista system - and I'm just as happy writing something basic myself, if I have the details.

(I've found text in STR.edf, presumably EDF+ entries, for overall info, but not for the daily summaries)

Obviously it would be nice to persuade the Escape to divulge more information, but just getting what it has would be interesting.

Any ideas appreciated.

Have you tried exchanging the Escape for an Elite or Autoset?

LSAT wrote:Have you tried exchanging the Escape for an Elite or Autoset?

Would love to, but the Escape is our NHS board's standard, and they require their own machine's data for the medical files - swapping would invalidate things.

I could probably hack the SD card with a different machine, but I'm grateful they investigated at all, and I'd have to pay for an enhanced version, so I'll stick with it. After all, it has made a difference to how alert I feel.

exbucks wrote:

LSAT wrote:Have you tried exchanging the Escape for an Elite or Autoset?

Would love to, but the Escape is our NHS board's standard, and they require their own machine's data for the medical files - swapping would invalidate things.

I could probably hack the SD card with a different machine, but I'm grateful they investigated at all, and I'd have to pay for an enhanced version, so I'll stick with it. After all, it has made a difference to how alert I feel.

Have you talked to them about this? Your machine only records time of usage. They can get that from any machine. There is no other data. What use is that to their medical files, other than compliance? They would be using the same software to get the compliance data.

Why not buy a used autoset on your own? Then you will have full data.

exbucks wrote:I would still be interested whether anyone can tell me the function of the 12 files in SETTINGS (and how their corresponding .crc files are calculated).

Can you upload a copy of SETTINGS somewhere so I can look at it? I don't find that folder (that is a folder, right?) in a copy of my S9 Autoset data.

I think it's safe to say no one here knows how the crc files are calculated, except maybe some lurking Resmed people. And if they know they sure a h*** aren't going to tell us. That's part of Resmed's data integrity safeguard scheme. Muck with a file on the SD card in the least little bit and Resscan won't calculate the same crc number the S9 does and Resscan will not read it in.

idamtnboy wrote:

exbucks wrote:I would still be interested whether anyone can tell me the function of the 12 files in SETTINGS (and how their corresponding .crc files are calculated).

Can you upload a copy of SETTINGS somewhere so I can look at it? I don't find that folder (that is a folder, right?) in a copy of my S9 Autoset data.

I think it's safe to say no one here knows how the crc files are calculated, except maybe some lurking Resmed people. And if they know they sure a h*** aren't going to tell us. That's part of Resmed's data integrity safeguard scheme. Muck with a file on the SD card in the least little bit and Resscan won't calculate the same crc number the S9 does and Resscan will not read it in.

ResMed's CRC files (except for identification.crc (and a few others in SETTINGS)) are just a generated 64bit cyclic redundancy check.. not that complicated to figure out the specifics, and ResMed tries very hard to stick to standards. I never bothered with checking them in SleepyHead, because, well, if your getting CRC errors, you've got much bigger problems and are going to know about it.

The act of checking them generates the CRC, so it could easily be written if the file changes were necessary. But I guess the question is, is that really necessary?

The Escape is a brick with a fan, and unfortunately there is nothing really that can be done about that.

Making a simulation of a "bricks" SD card for reporting purposes generated from the data provided by a more advanced machine isn't remotely difficult to achieve programatically. But I definitely do think there are better ways to solve problems like these.

An ethical problem arises by creating such a tool, that with a very simple and minor change, it would easily enable "incompliant" people to change their compliance records at will.. Imagine a sleep deprived but CPAP loathing pilot or truck driver being given the ability to easily hack their SD cards records to make it look like they are correctly treating their sleep disorder.. and then later they fall asleep in the hot seat and cause a terrible "accident"... :-/

jedimark wrote:

idamtnboy wrote:I think it's safe to say no one here knows how the crc files are calculated, except maybe some lurking Resmed people. And if they know they sure a h*** aren't going to tell us. That's part of Resmed's data integrity safeguard scheme. Muck with a file on the SD card in the least little bit and Resscan won't calculate the same crc number the S9 does and Resscan will not read it in.

ResMed's CRC files (except for identification.crc (and a few others in SETTINGS)) are just a generated 64bit cyclic redundancy check.. not that complicated to figure out the specifics, and ResMed tries very hard to stick to standards.

The reason I made the comment is that one time I used a program that supposedly had most all the standard crc calculation routines included, and none of them generated a crc that matched the one the S9 generates.

idamtnboy wrote:

jedimark wrote:

idamtnboy wrote:I think it's safe to say no one here knows how the crc files are calculated, except maybe some lurking Resmed people. And if they know they sure a h*** aren't going to tell us. That's part of Resmed's data integrity safeguard scheme. Muck with a file on the SD card in the least little bit and Resscan won't calculate the same crc number the S9 does and Resscan will not read it in.

ResMed's CRC files (except for identification.crc (and a few others in SETTINGS)) are just a generated 64bit cyclic redundancy check.. not that complicated to figure out the specifics, and ResMed tries very hard to stick to standards.

The reason I made the comment is that one time I used a program that supposedly had most all the standard crc calculation routines included, and none of them generated a crc that matched the one the S9 generates.

They might just be seeding the CRC start value or using a non standard root polynomial.. which doesn't take long to hack out on a modern computer.
It could also be in a different byte order depending on the devices CPU.

Could also be stringing together 2 phases of a CRC32 variant or similar, which is quite possible considering there is both 4 and 8 byte crc's.. (a fairly common practice when firmware space is limited)

But anyway.. if it turns out to be something that's genuinely needed, it something that will be done..

exbucks wrote:how their corresponding .crc files are calculated

was just out of curiosity - I have no interest in creating incorrect data. Quite the opposite - I would like some data, and did wonder at the time whether it was the SETTINGS folder that controlled what data was logged - from further research it seems that the 'brick' is missing some hardware bits so it is totally incapable.

When I'm more used to it, I'll see if I can swap to a privately supplied one.

Meanwhile, for anyone who is interested, I've got an understanding of STR.EDF - which contains solely daily totals for the Escape. The EDF format is an odd mash of ASCII text (Header and Data Value descriptions), followed by 16bit integer values (the actual data in binary).

If anyone is ever interested I can describe it more, or send on the relevant code. The ASCII part is well described at http://www.edfplus.info/specs/edf.html, but it is rather vague on the 16bit integers.

Thanks for all the comments.

exbucks wrote:

exbucks wrote:how their corresponding .crc files are calculated

was just out of curiosity - I have no interest in creating incorrect data. Quite the opposite - I would like some data, and did wonder at the time whether it was the SETTINGS folder that controlled what data was logged - from further research it seems that the 'brick' is missing some hardware bits so it is totally incapable.

When I'm more used to it, I'll see if I can swap to a privately supplied one.

Meanwhile, for anyone who is interested, I've got an understanding of STR.EDF - which contains solely daily totals for the Escape. The EDF format is an odd mash of ASCII text (Header and Data Value descriptions), followed by 16bit integer values (the actual data in binary).

If anyone is ever interested I can describe it more, or send on the relevant code. The ASCII part is well described at http://www.edfplus.info/specs/edf.html, but it is rather vague on the 16bit integers.

Thanks for all the comments.

The firmware on the Escape models are stripped of all the capabilities to do this. It genuinely is a brick at it's core unfortunately

The settings are pretty much just a log of what the machines internal state is set to. Worth exploring, but you won't find much useful data there.

The EDF+ data format is very well documented, it's all at the site you have have mentioned, including on dealing with the integers. It's spread out though several different pages though.

There are several open-source parsers for EDF+ out there, including the one I wrote for SleepyHead's S9 importer.

exbucks wrote:Meanwhile, for anyone who is interested, I've got an understanding of STR.EDF - which contains solely daily totals for the Escape. The EDF format is an odd mash of ASCII text (Header and Data Value descriptions), followed by 16bit integer values (the actual data in binary).

As you have probably figured out there are four sections to an EDF file, header, signals, data, and annotations. I believe the data is base 10, not binary, but then maybe the extraction program I use converts it. It's been three years since I dug into the edf files so I've forgotten a lot of what I learned back then! If it helps any here is a listing of the signals and units for the str.edf file for the S9 Autoset. I used a program EDF2ASCII.exe to convert the edf files. The output are the four straight files I mentioned which I massaged with a spreadsheet.

https://dl.dropboxusercontent.com/u/178 ... LS%202.pdf

I don't know specifically what the log and tgt files are other than they are probably regular type logging files and the others are target files. Oh, I just remembered something. On the Autoset if the machine settings have been placed on the SD card from Resscan I think there is a SETTINGS folder. Those settings are read by the S9 and the machine settings are then adjusted to coincide. However, with the Autoset anyway, the settings folder is then deleted and the card is formatted for operational data by the S9. Maybe the Escape doesn't delete that folder like the Autoset does. Have you changed any settings and then seen them go back to the previous settings? I'm not familiar with the Escape so that's why I ask.

Does anyone know for sure if the Escape reads the settings on the SD card every time it starts and adjusts to them? Or does it only reread them if there has been a power loss to the Escape?

I appreciate your summary of the fields. It seems likely that ResMed will have settled on these permanently, though the EDF format is very flexible.

I now see that an EDF viewer would do just fine - the STR.EDF is just a standard EDF file for the daily totals. I was confused that anyone would design a format with a mix and ASCII text (and numbers) and binary data (it is 16bit binary, though any program worth it's salt with display it base 10).

As to the SETTINGS folder, it seems a bit of a mystery, so far.