DME actively discourages use of software?!

[Pugsy]

And another OSA patient has been coaxed over to the dark side...taking control, being knowledgeable and proactive!

Yep, another convert.

I knew that an IT person wouldn't be able to stand not knowing about the data.

[Uncle_Bob]

I was, in no uncertain terms, very strongly discouraged from attempting to read the data on my CPAP's SD card, even though I knew the EncoreViewer software was available. They stated that it was "too easy" to nuke the compliance data and/or change the settings; that if I downloaded the data from the card before they did, they wouldn't be able to download it on a followup visit.

Thanks!

Let them know that when its not in your CPAP you will turn on the SD cards write protect switch so it will be impossible for anything to get altered on the card.

End of conversation.

[comstosf]

I'll go one better than the read-only switch: I have a Linux netbook with a built-in SD card reader, so when it comes time to read the data, in addition to using the read-only switch I'll disable automount on the card reader, manually mount the card in read-only mode, and copy the data to my file server. From what I've read, it's no different than copying pictures off my camera's SD card.

Will EncoreViewer support reading the data from somewhere other than an SD card, like a network file share?

[Lizistired]

Good question. ResScan won't.

[BernieRay]

ResScan also can't be fooled with a virtual drive substitution, either, so I'm certain that it is looking for a physical device to be present. EncoreViewer likely does the same.

Regardless, I would not give the DME's un-founded fears the time it would take to go to such extremes. The simple fact is, if our software usage caused problems, there would be a lot of threads about it here.

From one developer to another - get the Pro version and see for yourself what it does.

[idamtnboy]

The problem is that the S9 detects if the files in the root directory of the card have been moved in regards to their physical location(s) on the card. Without using specialized copy software, files will almost certainly be written to different physical parts of the card. If that happens with the S9, it won't accept the card and will most likely prompt to format it.

Your comment piqued my curiosity so I did some checking. Using a Hex Editor to look at a couple of cards. Here's what I find. The order of the file names in the root directory is Journal.dat, Identification.tgt, Identification.crc, DATALOG, STR.edf, and STR.crc, but the order of the files, according to starting sector, is DATALOG, Identification.crc, Identification.tgt, STR.crc, and STR.edf, and Journal.dat. Journal.dat file is all the way at the end of the card in unpartionable space. There is no ready way whatever I know of to write the files and the directory to the card in this order. Simply copying files from the PC hard drive back to the SD card writes them in altogether different locations.

Fortunately, Resscan does not care about the order of the files on the SD card. All it cares about is a valid CRC file. If you lose all the patient data it can be recreated by copying the backup files to an SD card and downloading them into Resscan.

There is no doubt in my mind this special card writing scheme is utilized to minimize the possibility of fake data being created. Reminds me of the early days of Lotus 1-2-3 when 5 1/2" key floppy disks were used to foil copying procedures. One track of the floppy was divided into something like 7 sectors while all the rest of the disk was divided into 8 sectors. Installing the s/w wrote, or removed, some key data in that secret track. Uninstalling reversed the process. If you had a hard drive crash after installing you were screwed. You could not reuse the floppy to reinstall the s/w.

Luckily, those root directory files (Identification.crc, Identification.tgt, Journal.dat, STR.crc, and STR.edf) can be re-created by the S9 in their entirety providing that the S9 has not been reset. Anytime that I need to copy data back onto the card (such as my weekly reset to avoid data skewing), I delete everything from the card, insert it into the S9 and power up. Once the machine is ready to go, having written the root directory files back as part of it's power up sequence when it finds a blank card, I then power the S9 down, take the card to my computer, and then copy only the files in the DATALOG folder back to the card.

So far I have had no problem with removing and reinserting the card without turning the S9 off. Do you know if it's possible to rewrite the summary data back into the S9 if the internal memory has been erased? The one time I tried it the first thing the S9 did was erase the card so both machine and card started fresh with no data.

[BernieRay]

Interesting discovery!

As far as I know, the S9 memory can only be written to by the S9 itself. It's conceivable that the data port might offer a way, but if it can, I think we'd have better luck in finding needles in haystacks. I guess a sequence of button presses would also be possible, but with so few buttons, it would probably be too easy for someone to stumble across it. Besides, if the data is already on the card, putting it back on the machine doesn't accomplish much.

Hmm...when you did your attempt, did you set up the card in ResScan as if you were downloading a new setting? I doubt that would work, but if there's an easy but hidden way to do it, that would be it.

Funny you should mention L123. Because it used 123.COM to handle the decryption of the real 123.EXE into memory, it was possible to bypass the key floppy by running 123.COM through debug up until just after the 123.EXE was decrypted into memory but prior to the command to run it, then writing the decrypted 123.EXE back to the disk. Once that was done, the install could be backed up. An un-install would then reset the floppy's install counter back to zero, effectively putting it back to new condition. Then, the backup could be restored. At that point, the disk was un-altered and a decrypted 123.exe could be run.

What I do wish that I could figure out is a way to patch the STR files to regain one day's worth of lost detail data from about a month ago. Something happened while the S9 was writing to the STR.EDF file. The DATALOG EDF detail files all exist and look fine in EDFBrowser, but ResScan will only load the summary data. My guess is that a reference of some type in STR.EDF to the detail files was buggered up but the rest of the data is fine. I could probably fix STR.EDF with some effort (if that is where the problem is), but without knowing their CRC algorithm, it would be wasted effort. I can't shake the thought that they use a standard CRC calculation then hash the result, but I just don't have the drive to attempt to reverse engineer it. $10 says it's something obscure yet simple.

I do find it curious that Resmed went to the trouble to enforce the root directory logic then have ResScan ignore it. Not that I'm complaining mind you...

[chunkyfrog]

I suppose this makes it 'impossible' to hack the compliance numbers.
Who would be up to that challenge?
It's only a matter of time. . .
Which decade's wunderkind; coming of age, decides to redirect his (or her) rage.

[idamtnboy]

Hmm...when you did your attempt, did you set up the card in ResScan as if you were downloading a new setting? I doubt that would work, but if there's an easy but hidden way to do it, that would be it.

Funny you should mention L123. Because it used 123.COM to handle the decryption of the real 123.EXE into memory, it was possible to bypass the key floppy by running 123.COM through debug up until just after the 123.EXE was decrypted into memory but prior to the command to run it, then writing the decrypted 123.EXE back to the disk. Once that was done, the install could be backed up. An un-install would then reset the floppy's install counter back to zero, effectively putting it back to new condition. Then, the backup could be restored. At that point, the disk was un-altered and a decrypted 123.exe could be run.

What I do wish that I could figure out is a way to patch the STR files to regain one day's worth of lost detail data from about a month ago. Something happened while the S9 was writing to the STR.EDF file. The DATALOG EDF detail files all exist and look fine in EDFBrowser, but ResScan will only load the summary data. My guess is that a reference of some type in STR.EDF to the detail files was buggered up but the rest of the data is fine. I could probably fix STR.EDF with some effort (if that is where the problem is), but without knowing their CRC algorithm, it would be wasted effort. I can't shake the thought that they use a standard CRC calculation then hash the result, but I just don't have the drive to attempt to reverse engineer it. $10 says it's something obscure yet simple.

I do find it curious that Resmed went to the trouble to enforce the root directory logic then have ResScan ignore it. Not that I'm complaining mind you...

I erased the machine memory in a desperate attempt to correct the date foul up I caused when I tried to reset the clock to standard time last November. I tried doing it between 12 and 1 am. Wrong time to try. I've since figured out how to do it properly. I'll post instructions just before we change to DST. I thought the summary data would be restored into the S9 from the card. Wrong!

Back when I was using L123 on floppies, I didn't have the foggiest idea about debugging. PCs were very young and I was new to PCs and learning from DOS manuals and Peter Norton's (remember him?) books and programs. Back in the days when Bill Gates, when upgrading DOS, reportedly said, "DOS ain't done till Lotus won't run!" Those were fun, and frustrating, days. Now it's mostly just boring and frustrating.

STR.edf file has no reference to the detail or hi-res files in it. Make sure you've got the option to read all data from the card checked in the download options of Resscan. Is the missing day of data not showing up in the summary data, or is it just the detail and hi-res that's missing?

Big difference between the S9 and Resscan - the OS. The S9 probably is running an embedded version of Linux, or something like that, and since it's a single purpose machine they have no restrictions on what they can and can't write to the card. Resscan, of course, is running under Windows, which controls the media I/O operations. It would be somewhat of a hassle to bypass the Windows controls and read/write the card structure directly, and not worth the trouble since there would be nothing really to be gained by doing so. From a practical standpoint the current approach probably prevents 999,999 out a million chances that someone would try to create phony data. That last 1 in a million culprit ain't worth going to the trouble to stop.

[idamtnboy]

I suppose this makes it 'impossible' to hack the compliance numbers.
Who would be up to that challenge?
It's only a matter of time. . .
Which decade's wunderkind; coming of age, decides to redirect his (or her) rage.

'Impossible', no. Impractical, yes. Once someone cracks the code for generating the CRC numbers all bets are off. Once that happens a truly resourceful person could generate all the data needed to show compliance, put it on a card, and give it to the DME. But why would someone want to do that, especially if they had to pay someone else to do it for them? This is one activity that I don't see where there would be any monetary reward for a 'criminal' act. Now, doing it for the sheer sake of the thrill of cracking a code, yeah, maybe someone will do it for that reason.

[BernieRay]

The entry in the STR.EDF for that day was hosed (as were the numbers on the S9). The summary data for the problem day is an exact duplicate of the previous day and there are no details or hirez in spite of 4 good EDF files and correct D/L settings. Even if STR.EDF doesn't have a reference, it being hosed for that day effectively stops ResScan from reading the DATALOG files for that day. Which stinks, since the summary could be re-built from the DATALOG EDFs if there was a way to do it. Actually, the root problem was that the data inside of the S9 for that day was hosed. I let the S9 rebuild the card, and it still wouldn't work. A few days later, my doc questioned the flow rate on my report, so, between the 2 problems, the DME swapped out machines. As the saying goes, t's good and gone now without a way to do a manual data patch.

BTW - I agree with you about the state of things today vs 20-25 years ago. The fun started leaving when WFW311 was replaced. Gates invents the registry, effectively opening a software version of Pandora's box. Efficient, tight code has turned into buggy bloatware. Oh well....at least I still have an IBM PS2/80 with IBM-DOS on it that I can fire up from time to time.

[idamtnboy]

Oh well....at least I still have an IBM PS2/80 with IBM-DOS on it that I can fire up from time to time.

Ever run OS/2? 10 times better than Win was, and still would be if the M$ jaugernaut hadn't been able to strangle it to death. Some missteps by IBM didn't help, either.

[imtired]

I suppose this makes it 'impossible' to hack the compliance numbers.
Who would be up to that challenge?
It's only a matter of time. . .
Which decade's wunderkind; coming of age, decides to redirect his (or her) rage.

'Impossible', no. Impractical, yes. Once someone cracks the code for generating the CRC numbers all bets are off. Once that happens a truly resourceful person could generate all the data needed to show compliance, put it on a card, and give it to the DME. But why would someone want to do that, especially if they had to pay someone else to do it for them? This is one activity that I don't see where there would be any monetary reward for a 'criminal' act. Now, doing it for the sheer sake of the thrill of cracking a code, yeah, maybe someone will do it for that reason.

There are many reasons someone would pay for false data. Think of someone who is in an accident and will be found at fault for untreated osa. Compliance data showing that you didnt fall asleep might be worth the money for some people

[BernieRay]

Ever run OS/2? 10 times better than Win was, and still would be if the M$ jaugernaut hadn't been able to strangle it to death. Some missteps by IBM didn't help, either.

I used OS/2 briefly, around 91 or so. Just long enough to see the possibilities.

There are many reasons someone would pay for false data. Think of someone who is in an accident and will be found at fault for untreated osa. Compliance data showing that you didnt fall asleep might be worth the money for some people

Even if I figured the algorithm out, I'd keep it to myself. Doing it to enable missing data is one thing. Falsifying data is unethical and, if used in court, illegal. So those folks don't count.

Besides, it would only be useful to me as a curiousity - that missing day a month ago has no bearing on my treatment now.

[idamtnboy]

Even if STR.EDF doesn't have a reference, it being hosed for that day effectively stops ResScan from reading the DATALOG files for that day. Which stinks, since the summary could be re-built from the DATALOG EDFs if there was a way to do it. Actually, the root problem was that the data inside of the S9 for that day was hosed.

Was it you, or someone else, who posted a hack for the devicescan2.exe file that would bypass the CRC check for loading data into Resscan? This would allow you to repair the STR.edf file for your own use, but wouldn't for the summary file you submit for compliance. You could reconstruct the summary data for the one day, but it would be a royal pain. You'd have to use a spreadsheet to calculate median, max, and 95% numbers for flow, pressure, etc.

Like you said later, at this point in time there's no particular value in doing it. Kind of like when I worked for Uncle Sam. I found out there really are times, "If you ignore a problem long enough, it goes away!"