Thanks for the offer, DreamDiver! I don't think it's advantageous to spend more time on that.DreamDiver wrote:I could probably take the time to sit down and measure, but I think others may have already done that. I'm still putting some distance between me and the problem.-SWS wrote:DD, can you find any correlation between your machine's data skew and number of mask-fit sessions?
Sorry to hear about your frustrating experience with sleep studies.
And thanks for this explanation as well:
I'll continue keeping an eye on mine to see how the skew progresses with firmware version SX474-0602.DreamDiver wrote:There are four main files types in question: *BRP.edf, *PLD.edf, *EVE.edf, and *SAD.edf. The .crc files are 'sanity' check files, as far as I can tell, to make sure the numbers have not been tampered with upon uploading to ResScan.
*BRP.edf includes two very high resolution measurements at 25 Hz: Flow and Mask Pressure. This data is linear. These two measurements are either combined using an algorithm to produce what we see in ResScan, or one of them is simply dropped. I suspsect the former.
*PLD.edf includes eleven less-high resolution (1 Hz) data, which are linear. These include another different Mask Pressure measurement, Therapy pressure, Exp Pressure, Leak, RR, Vt, MV, Snore Index, FFL Index and two unlabeled indices or lines that seem to have something to do with lining up the *EVE.edf data (the next one.)
*EVE.edf includes all event data (point or 'marker' data on a timeline), including central, obstructive and unknown apneas and hypopneas. The shorter this file, the better we supposedly sleep.
*SAD.edf is for high-resolution oxygen and pulse data. ResMed suggests the data being measured is 1Hz data, even though the sensor they use is capable of 25(27?)Hz collection, including plethysmography, so I don't know what to believe on that one because I haven't seen any oximetry data in a *SAD.edf file yet.
Some of the data being measured is either not stored or not displayed by ResScan, even though the S9 measures it. Some of the data shown by ResScan graphs is created during the upload process, such as the AHI graph.
The three most important files for this are the *BRP.edf, *PLD.edf and *EVE.edf files. They have to be written to one at a time because the S9 has only one processor and can handle only one task at a time. Similarly, the data cannot be all read at identically the same time, but rather, darned close. It looks to me like the flow data takes precedence, since it writes most often. The 1Hz linear data is written next. The event (point data) data writes independently of either flow or linear data, only when events are noted by the software in the S9. Regardless of when the data is written, at least one variable is being held as a sort of changing global variable from mask-session to mask-session that affects the skew of the next data session. The currently writing session seems to either grab some variables from the their analogous files from the last mask session, or from a variable storage file that is used to alter the original write time of the current session. However it happens, those variables change from session to session, independently for each file type when they should be identical. Session begin-time ends up being different for each file in a mask session, with that difference in time growing in an asymptotic curve. The outcome is ever-increasing skew.
Data seen in the EDF browser are usually identical to what is seen in the data on ResScan, down to the second, so an independent audit of the data proves that ResScan is not introducing the problem. It already exists in the data as written by the S9 before it gets to ResScan. The SD cards provided by ResMed are their approved cards, so they cannot be the problem. Hence, the data skew must be either firmware- or hardware-based.
