Request for Resmed SD Card feature

Having spent 40+ years of my life developing software, I'm very glad to see a software engineer here soliciting ideas for CPAP software, to make the software more useful to the end user. I think that it would be an excellent idea to have ResMed (and other mfgr's) monitoring this forum to read about the most common problems that people have with their machines that can easily be remedied by ResMed, et. al. to make all of our lives easier (including ResMed's support organization *smile*, less need for support saves you guys money and saves us pain).

I heartily agree with the most common idea, which is to just let the detailed data sit on the card as long as possible, since most cards are a lot bigger than 1GB. these days. In fact, you'd have to really look to find a 1GB. SD card now, and they only get bigger. It is painful to have to download data once a week or lose the detailed data, especially if one is on vacation, or sick, or whatever. When I go on vacation, I'm much more likely to take my tablet than my laptop, in which case I can't download SD cards at all.

Of course, an even better solution would be to have the CPAP machine have either built-in wireless or even just wired ethernet capability, so the download would be much easier and less error-prone. You could encrypt the data (or use a VPN-type connection) if you're worried about the security of medical data. You would also need to keep the SD card for a "hard-copy" fallback in case of problems with the network solution, or the user's choice to use an SD card instead of networking. And on and on, but that's most likely the next generation of CPAP.

Anyways, I'm happy to see you here reading *smile*.

I only wish this was 6 months further down the track, as I have only been using my S9 for 2 months and it is early days in coming to terms with it all. However I will second the previous suggestion from idamtnboy "Also consider modifying the data scheme, particularly for the SAD file, so that external data from an oximeter can be merged into the data files." It would be really great to be able to compare oximetry readings downloaded from other oximeters (apart from the Nonin - which I understand is the only one that's compatible with the S9) against the Rescan data and graphs.
We are able to select the type of mask when setting the S9, but there doesn't seem to be a transfer of this info when downloading the SD card. I am using, or rather should say I am trialling, various masks, and I often wish the statistics page would record which type of mask was used on a particular night to be able see how it coincides with leakage AHI etc. Maybe it is there but I can't find it.
Thanks for looking for feedback from us owner/users

The idea is not to be able to store other data on the card. The idea is to have the software NOT go crazy when it finds a file it doesn't recognize on the card.

It's also been suggested that there is something nonstandard about the filesystem used by the S9 card. i.e. not a standard FAT32 filesystem. If another device writes to the card with standard FAT32 protocol, the S9 can't read it any more because it uses a non-standard directory table or one of the other fiddly bits about the way you store data in a FAT32 filesystem.

As for figuring how much space is left on the card, that shouldn't be a problem. Free space is something almost any operating system has to figure out anyway. Roughly speaking, you just count the free clusters in the FAT. You have to handle the FAT in order to be able to write to the card at all.

There are also some limits created by the use of a FAT32 filesystem. The choice of cluster size means each file uses up a minimum number of bytes on the disk, no matter how small the file is. The S9 records something like 8 different files each time you turn it on and off. Each of these consumes 4 to 16K of disk space because of the cluster size in a FAT32 filesystem, so you get an artificial limit that way to the number of files on the card.

sol wrote:how do you get rid of this message on the S9 Elite other than return machine to provider "error setting reset to default settings contact service provider"

Put the card in your PC. Read the data with Encore if you're using that. If you're using SleepyHead, save a copy of the whole card for later use. Then format the SD card. Expect to lose all data previously stored on it. The S9 itself should remember the compliance data.

RogerSC wrote:Of course, an even better solution would be to have the CPAP machine have either built-in wireless or even just wired ethernet capability, so the download would be much easier and less error-prone.

How about using a wireless SD card?

viewtopic.php?f=1&t=86656

RMD_software wrote:Hi all,

I am a software engineer working at Resmed. Seeing as I am working on SD Card area of the software. Does anyone have any SD Card related feature requests for the next generation of Resmed product?

Top request: Publish the data format and content
Second request: Support wireless SD cards (you may already, I don't know) ... mostly this means:

• Accept the name of the card
• Accept the pre-existing content
• Leave the card powered (could be an option!)

From one software engineer to another, great to see your interest!

I have never had the "invalid card" problem come up. I was just wondering what was going on because others come here and ask.
Nearly a year on the S9 and I don't write protect my card when I download data.
Windows 7...maybe just dumb luck. I was wondering if Windows was sneaking some sort of change in the SD card that the machine didn't like...seemed only logical explanation.
Short on time, maybe more later.

The thing I'd most like is to be able to use the SD card to update the firmware so that we can take advantage of your improvements as well as bug fixes and other new features without having to send the machine back to ResMed. I believe the current policy is to not allow field upgrades, and that leaves most of us using buggy firmware.

A robust warning if we try to operate the machine with the card out would be very welcome. Maybe flash the screen for minute or so. Currently, the machine only warns us when it reboots, and most people don't reboot every night. I wouldn't go as far as to disallow therapy, as there might not be an SD card available. But if the user has forgotten to put the card back in, he may be too sleepy to notice a subtle message. It needs to be OBVIOUS.

If it's within your power, please cache as much data as possible on the machine. It's just common sense to preserve data if you can. Keep however much will fit without causing a problem.

Absolutely allow the card to fill up with data. Erasing data after one week is just silly. If it's too much for DMEs databases, then let them choose how much to import. I'd prefer that the machine start warning two or three months out that the card is getting full and then start overwriting the oldest files as needed.

Allow other files on the card, not because that's where we hide our porn, but because if some pointless file gets written to the card, it can simply be ignored. There shouldn't be much of this on the card, hence it's probably best to preserve these files once the card is full. At some time in the future, there may be a legitimate reason for other files, and it's probably best to let whatever writes those files manage them.

Please publish the details of the data formats. The main reason this is needed is that they are funkier than they need to be. For instance, for apnea, the duration of the event is logged, but for hypopnea, only the duration after ten seconds is logged. I'm told there is even more weirdness in the summary files. Perhaps it's too late to easily correct these things, but it would be very helpful to third-party developers if you would publish the details. Please at least send them to JediMark, who has developed an open source, user-oriented data viewer that many of us like very much. If you have trouble selling this, you might point out that users like Mark's application, SleepyHead, so much that which machines it supports, and how well it can support them, is a serious consideration when it's time to buy a new machine. Yes, users who are that involved in their therapy are a minority, but we'll live longer and hence buy more equipment.

Is there a good reason for Journal.dat, and does it really need to be in the last sectors? The peculiarities of this file/location make it difficult for users to reconstruct the card from backups if something goes south. If it really needs to be that way, perhaps you could provide a program to rebuild the data structure on a new card.

I'd also like to see the "skew" bug fixed. This causes the events to be offset from the data they're supposed to flag. It usually starts to show up after about two weeks or so. Rebooting daily helps a lot with this and other data recording bugs, but many users also reformat their cards every two weeks to help keep the bug out of their data. This may not be your area, but it definitely affects what you're doing. What's an annoyance at two weeks could become a major problem after two years. This bug has been discussed at length. Here are a few threads.
viewtopic.php?f=1&t=50578
viewtopic.php?f=1&t=51328
viewtopic.php?f=1&t=53095
viewtopic.php?f=1&t=57582
viewtopic.php?f=1&t=57224
viewtopic.php?f=1&t=62899

I don't have a problem with the CRC files, but their presence is a great argument for Archangle's suggestion to use something other than FAT32. If this would cause difficulties, though, the capacity of the cards can compensate for some inefficiency in the file system.

Is there anything you can do about how poorly the S9 keeps time? In order to sync my CPAP data with the data from my Zeo alarmclock/EEG or any oximeter except the overpriced one that is supported by the S9, I have reset my machine's time often. I suspect this is more of a hardware problem, but it's ridiculous that a cheap digital watch will keep time better than an expensive medical device. If there is anything you can do to compensate, it would be very appreciated.

I am very glad to see someone from ResMed here asking what we need. I am especially glad that it's someone who can directly implement some of our suggestions. Thank you! The industry needs more of this.

Strange. Shouldn't the OP be asking the DMEs and not the patients. We dont have the software for the SD cards only the DMEs have such power.

khauser wrote:Top request: Publish the data format and content

The files are standard format EDF. As I understand it that is a standard open source data structure for medical files used in Europe mostly. I've used a couple of free programs to navigate the files without using Resscan, EDFtoText and EDFviewer. Both will transform the EDF data into text files you can import into spreadsheets. But be aware, when you import the BRP file into a spreadsheet you can end up with 10+ sheets of 64,000 rows each! 25 times/second x 60 seconds/min x 60 min/hr x 7 hours = 630,000, which is a lot of numbers to crunch in a spreadsheet!! And that's for only one night!

Uncle_Bob wrote:Strange. Shouldn't the OP be asking the DMEs and not the patients. We dont have the software for the SD cards only the DMEs have such power.

Love your signature.

idamtnboy wrote:

khauser wrote:Top request: Publish the data format and content

The files are standard format EDF. As I understand it that is a standard open source data structure for medical files used in Europe mostly. I've used a couple of free programs to navigate the files without using Resscan, EDFtoText and EDFviewer.

Yes, it's EDF, but some information about what the numbers mean would be helpful.

See this thread, it has my suggestions (brand new user) followed by others ideas as well as why they don't like mine.

viewtopic.php?f=1&t=86879&p=792167#p792167

The SD card capacity is growing every year with costs staying the same or going down. There is not a reason to revamp the S9 (and future) schema to have it take a look at the card capacity and auto adjust the number of days the high def data will be kept on the card. An 8 gig card will allow X days and a 16 will double and a 32 will double again. IOW, enhance the machine software to look at the card capacity and auto adjust the high def number of days.

Another, but a bit 'out there' machine enhancement would be to have a second card slot or USB port to allow a choice of a data mirror, or data overflow or even mp3 music files that could be ported to a new ear plug output. It would be pretty cool to have a earplug output and a hose designed to contain the wiring that interface with a mask and the mask strapping has the wiring embedded and the earplugs would come out of the strapping to fit into the ears. No wire tangling and going to sleep with a favorite playlist would be great.

Otter wrote:Yes, it's EDF, but some information about what the numbers mean would be helpful.

If you use the EDFtoText program it outputs four files, annotations, data, header, and signals. Going from memory since I haven't looked at the extracted files for a year or more, the annotations are text info, the data is just that, the actual data, the header is the meta info about the data such as start time, and the signals list what each data column is. What I did was put the signal file into the s/s and rotated it, then copied it to the top of the worksheet of the data file. I can send you some examples if you can't get it all deciphered yourself. All the info you need to format the various files in a s/s is available in the four extracted files. It just takes some time studying them to figure it all out. I'd have to look at my s/s to remember exactly what the unit of the time stamp increment is, like in the brp file, but I think it's 1/100 of a second.

The Resmed clinicians manual describes what the various data items represent. What isn't described there you can figure out by looking at the signals file.

I guess I pretty much figured it all out just by studying the data, but then I suppose I may find doing such things easier to do than other folks do.

If you can't get it figured out I can put together some stuff to help explain it.