CPAPtalk.com

Examining my first night's data on the SD card, the high-res data takes up just over 2,000 KB on the SD card and was collected over approximately 6 hours. If my math is correct that implies an average data write speed of approximately 0.1 KB/s (2,000 / (6 x 60 x 60)).

From the earlier links, the minimum promised write speed of even a class 2 SD card is 2MB/s, which is approximately 20,000 times faster than 0.1KB/s. Many SD cards you could buy at your local electronics store would be faster than that - the SanDisk Ultra card I purchased yesterday is a class 4 (minimum 4MB/s), with an advertised performance of 15MB/s, which would be about 150,000 times faster than the actual write speed I experienced.

Unless I'm missing something here, it looks like we're barking up the wrong tree in thinking that SD card write speed is the cause of the data skewing.

alterego61 wrote:Examining my first night's data on the SD card, the high-res data takes up just over 2,000 KB on the SD card and was collected over approximately 6 hours. If my math is correct that implies an average data write speed of approximately 0.1 KB/s (2,000 / (6 x 60 x 60)).

From the earlier links, the minimum promised write speed of even a class 2 SD card is 2MB/s, which is approximately 20,000 times faster than 0.1KB/s. Many SD cards you could buy at your local electronics store would be faster than that - the SanDisk Ultra card I purchased yesterday is a class 4 (minimum 4MB/s), with an advertised performance of 15MB/s, which would be about 150,000 times faster than the actual write speed I experienced.

Unless I'm missing something here, it looks like we're barking up the wrong tree in thinking that SD card write speed is the cause of the data skewing.

I'm really not sure what you said.
Could you show us the skew, or did you have no skew?

Edit: Perhaps it's less about how fast it can write one single track, or a few large tracks all at once, and more about appending data to several existing files in overlapping previously-written sectors more than a few times a second. Does anyone have a clue as to the frequency with which flow data is appended to the *BRP.edf file?

alterego61 wrote:Examining my first night's data on the SD card, the high-res data takes up just over 2,000 KB on the SD card and was collected over approximately 6 hours. If my math is correct that implies an average data write speed of approximately 0.1 KB/s (2,000 / (6 x 60 x 60)).

From the earlier links, the minimum promised write speed of even a class 2 SD card is 2MB/s, which is approximately 20,000 times faster than 0.1KB/s. Many SD cards you could buy at your local electronics store would be faster than that - the SanDisk Ultra card I purchased yesterday is a class 4 (minimum 4MB/s), with an advertised performance of 15MB/s, which would be about 150,000 times faster than the actual write speed I experienced.

Unless I'm missing something here, it looks like we're barking up the wrong tree in thinking that SD card write speed is the cause of the data skewing.

I think what you are suggesting is that the S9 writes to the SD card in Real Time over the 6 hours... it doesn't seem to at all. As far as I can figure, the data is written at the very end of the mask time in a very short period of time. The Hi Rez data (25 Hz) is saved to some internal memory storage (unknown quantity and speed) perhaps with the help of some cache memory (unknown quantity or speed) on a Flow On/Off basis. It seems to be only written once per mask event and then only DL'ed once to the SD card for a maximum of 1 session... I have not been able to reload another card the same data.

For Everyone:

Flow always begins on the same second as it ends the mask event (ie 23:12:28 to 06:22:28). As DD suggests, they begin and end always/only on even numbers.
All Other Data except Indexes are 2 seconds less time than Flow (Pressure; Leak; Minute Ventilation; and Flow Limitation). They begin/ end on even numbers until Skew happens.
Indexes always begin at the same time as Other Data but are continuous until last Mask Event of the current Session.
AHI begins with Apnea, Central, Unknown or Hypopnea and ends at the end of the hour that follows Event cessation.
Events happen at correct times until skewing arrives.

In addition I found Flow always begins and ends on even numbers UNTIL the Skew begins. My skewed Flow data begins the first time that Flow begins on an odd number of seconds

I have been testing with a Scandisk 2 Gig Class 2 SD card since April 6th as follows: New - Formatted in Win XP Fat 32

Day 1 - #1 mask event... Flow begins; Other Data begins 2 seconds later and ends at same time.

Day 2 - #2 mask event... Flow begins; Other Data begins 2 seconds later and ends at same time.
#3 mask event... Flow begins; Other Data begins same time and ends 2 seconds early.
#4 mask event... Flow begins; Other Data begins same time and ends 2 seconds early.

Day 3 - #5 mask event... Flow begins; Other Data begins 2 seconds later and ends at same time.
#6 mask event... Flow begins; Other Data begins same time and ends 2 seconds early.
#7 mask event... Flow begins; Other Data begins same time and ends same time.

Day 4 - #8 mask event... Flow begins; Other Data begins 2 seconds later and ends at same time.
#9 mask event... Flow begins; Other Data begins 3 seconds later and ends 1 second later. (SKEW in numbers) NB: First time that Other Data begins/ends on odd number of seconds.

Day 5 -#10 mask event... Flow begins; Other Data begins 2 seconds later and ends at same time.
#11 mask event... Flow begins; Other Data begins 2 seconds later and ends at same time.
#12 mask event... Flow begins; Other Data begins 3 seconds later and ends 1 second later. (SKEW in numbers) NB: Other Data begins/ends on odd number of seconds.
#13 mask event... Flow begins; Other Data begins 5 seconds later and ends 3 seconds later. (SKEW in numbers) NB: Other Data begins/ends on odd number of seconds.

Day 6 -#14 mask event... Flow begins; Other Data begins 6 seconds later and ends 4 seconds later. (SKEW in numbers)
#15 mask event... Flow begins; Other Data begins 7 seconds later and ends 5 seconds later. (SKEW in numbers) NB: Other Data begins/ends on odd number of seconds.
#16 mask event... Flow begins; Other Data begins 6 seconds later and ends 4 seconds later. (SKEW in numbers)

Day 7 -#17 mask event... Flow begins; Other Data begins 8 seconds later and ends 54 seconds early. (SKEW in numbers) NB: Other Data missing 60 seconds of data at the end.
#18 mask event... Flow begins; Other Data begins 9 seconds later and ends 7 seconds later. (SKEW in numbers) NB: Other Data begins/ends on odd number of seconds.
#19 mask event... happening later

There are some patterns showing up. Skewing Data seems to begin after 3 days and maybe with Mask Event #9...
Locking the SD has not mattered for me.
ResScan deems to record whatever data the SD card has entered and it does not skew any further.
"Power Cycling" was used until the skew showed itself... then discontinued.

I will continue with same SD card until Day 10. I plan to test other elements at that time.

Comments appreciated... there may be errors in my recording (I'm getting tired)

Nord

@Nord

Those data look very interesting.

It would be good to know for sure if the data are being written to the card once from machine memory at the end of the mask event or sequentially during machine operation. How do you figure that you know one way or the other already?

One test would be to run the machine for a few minutes, disconnect power, remove the card, and see what, if anything, was written to the card for that session. One would obviously want to do that with a fresh card in case it got corrupted by the test.

If the data are all being written out at the end, then the problem would be not so much that the cards are too slow to keep pace with the data, but that the program logic for the way the data are written to the card is flawed in some way.

I'm assuming that all of the data you present is coming from ResScan? Has anyone actually looked inside the raw high-res data files to see what is recorded and how it matches up to how it is presented in ResScan? It would be helpful to figure out if the problem is the way that the data are being written/organized, or the way that they are being interpreted by ResScan.

DreamDiver wrote:I f you are suggesting it's not the card's fault, great.

I'm suggesting that any class or size of SD card that does not have a technical manufacturing fault should be quite capable of handling the accurate storage of data written by an S9.

DreamDiver wrote:What do you think is causing the skew?

Beats me..... I am not seeing any data skew issues with my data.

Cheers,

Bill

alterego61 wrote:Bill, it depends on how you define "essentially constant", but your statement is not strictly speaking correct:

Neither is it strictly speaking incorrect, as the reference was not explicitly to the fine detail of the operation of SD cards

alterego61 wrote:The amount of fragmentation can reduce write speeds so higher SD card speeds help compensate for fragmentation."

This is only in a relative speed sense (that is, it is not quite as fast), in absolute speed terms there is very little difference at all.

The issue with SD Card "speed" is almost totally related to how quickly high volume/rate data can be promptly (as close to real time as possible) cleared out of internal dynamic storage caches in digital cameras (both still and video) into persistant storage on removable media. Even tiny differences in speed can be significant for those particular applications.

Cheers,

Bill

billbolton wrote: The issue with SD Card "speed" is almost totally related to how quickly high volume/rate data can be promptly (as close to real time as possible) cleared out of internal dynamic storage caches in digital cameras (both still and video) into persistant storage on removable media. Even tiny differences in speed can be significant for those particular applications.
Cheers,
Bill

Exactly... can somebody "weigh in" on whether the Hi Rez 25 Hz data that is written to the card is equivalent to/ or much less than the Video/ Photo SD card use.

Bill... You're not seeing Skew... what is it that's different from other people here. I cannot see what, if anything, that I am doing differently/ wrong in the process that I describe above. Why would you not be encountering any skew.

Is your machine different/ later model/ different batch/ different source equipment or are you doing something differently ???

How long have you had the S9 now ???

Are you using the original card ??? Are you looking at/ DL'ing Data daily ???

Please share your wealth...

Nord

billbolton wrote:

alterego61 wrote:Bill, it depends on how you define "essentially constant", but your statement is not strictly speaking correct:

Neither is it strictly speaking incorrect, as the reference was not explicitly to the fine detail of the operation of SD cards

OK, there was no such explicit reference so you're not 100% wrong (and I'm not 100% right).

billbolton wrote:

alterego61 wrote:The amount of fragmentation can reduce write speeds so higher SD card speeds help compensate for fragmentation."

This is only in a relative speed sense (that is, it is not quite as fast), in absolute speed terms there is very little difference at all.

The issue with SD Card "speed" is almost totally related to how quickly high volume/rate data can be promptly (as close to real time as possible) cleared out of internal dynamic storage caches in digital cameras (both still and video) into persistant storage on removable media. Even tiny differences in speed can be significant for those particular applications.

Bill

Agreed, that may be an issue with SD card speed in that type of application. Since we don't yet know in detail, as far as I can tell, how/when S9 writes its data to the SD card, we don't know if a relative speed difference such as that is likely to have any impact on the accuracy of the data S9 writes to the card. My guess is not.

alterego61 wrote:@Nord

Those data look very interesting.

It would be good to know for sure if the data are being written to the card once from machine memory at the end of the mask event or sequentially during machine operation. How do you figure that you know one way or the other already?

One test would be to run the machine for a few minutes, disconnect power, remove the card, and see what, if anything, was written to the card for that session. One would obviously want to do that with a fresh card in case it got corrupted by the test.

If the data are all being written out at the end, then the problem would be not so much that the cards are too slow to keep pace with the data, but that the program logic for the way the data are written to the card is flawed in some way.

I'm assuming that all of the data you present is coming from ResScan? Has anyone actually looked inside the raw high-res data files to see what is recorded and how it matches up to how it is presented in ResScan? It would be helpful to figure out if the problem is the way that the data are being written/organized, or the way that they are being interpreted by ResScan.

We are all making some presumptions based on what we've seen and experienced so far.

The Flow data seems to be written once per mask event based on the time stamps on the files contained in the Datalog folder and the BRP.edf files. To my knowledge, no one has downloaded the program to "read" the files other than the very basic time stamps - so testing has been limited. For myself I have hoped to stumble upon a methodology of switching cards before the skew takes place.

Not so scientific but practical given the simple tools that we're using.

All the data that I presented comes from ResScan 3.10 and does not change upon further DL's. I am DL'ing daily and the Skew goes back to none upon substitution of newly formatted and empty card... thus we start over again until it progressively gets worse before 7 days are up and some have begun to lose data or have it displaced to another time event.

I have has an Apnea Event posted by the machine 4 minutes after the machine was shut down

Edit: Or... maybe I didn't have the Apnea at all since I can't find the Flow Data that it's represented. What else is happening or not happening ???

Nord

Nord wrote:... Or... maybe I didn't have the Apnea at all since I can't find the Flow Data that it's represented. What else is happening or not happening ??? ...

Sorry for side-tracking, but this could be significant. I get flow data regardless of whether there are no events or 20 events in any specific mask event. Are you saying you get no flow data when there are no apneas?

We are all learning about how the S9 collects and records its data. I did some brief testing and analysis this evening to contribute to the discussion, both by examining the data files using the EDF tools, and by experimenting with removing the card, or unplugging the machine before the mask event was finished, as well as by simulating apnea (!) to see what would be recorded on the SD card and when.

In brief I can say that what some posters have guessed, that data only gets written to the SD card when the start/stop button is pressed to start or stop the machine at the beginning and end of the night's sleep or nap, is incorrect - data seems to be written both on a timed and event-driven basis, as well as on the start/stop button press.

I haven't had time to think about any of the information below in relation to the skew problem, and in any case I don't have any skew data
to look at (yet), but I hope this is of some use. With the caveat that this is data collected from a very small data sample on one machine here's what I determined so far:

There are 5 types of EDF (European Data Format) files that my S9 maintains on the SD card:

In the Root Directory: STR.EDF (Summary Table Results?) which contains 28 parameters listed near the bottom of this post

In the DATALOG subdirectory:

YYYYMMDD-HHMMSS_BRP.EDF which contains the two 25Hz High-Resolution data series: Flow, in L/s; and Mask Pressure, in cmH2O
YYYYMMDD-HHMMSS_PLD.EDF which contains 9 named and two un-named 0.5Hz Low-Resolution data series, listed at the bottom of this post
YYYYMMDD-HHMMSS_SAD.EDF which, if I had an oximeter, should contain two 1Hz Low-Resolution data series: Pulse, in bpm; and SP02 in %

YYYYMMDD-HHMMSS_EVE.EDF which contains the details of events recorded or scored by the S9

I haven't worked out what all the file abbreviations stand for, but these are my guesses:

EVE = Events, SAD = Saturation Data? BRP = Breathing Profile? PLD = Pressure and Leak Data?


There is only one STR file, but a new set of four DATALOG files is created each time the machine is started for every start/stop cycle - YYYYMMDD-HHMMSS is the date and time when the start/stop button is pressed to switch the S9 blower on. The first three DATALOG files have data written to the SD card once a minute, beginning on the first minute anniversary of the start button being pressed. Evidence: if you have the machine switched on for less than a minute, no data is recorded in the files. If I either remove the card or remove the power supply to the machine without stopping it using the start/stop button, only data for a complete number of minutes is stored on the card. For example, if I remove the SD card after 2 minutes and 30 seconds, there will be 2 minutes' worth of data in these three files, and the update timestamp of the files is the exact minute anniversary of the machine start time.

The EVE file has a data record written in it when the machine starts for the beginning of the sleep cycle, and gets updated every time an event happens.
Evidence: if I simulate an apnea by stopping breathing, and then remove the card without stopping the machine, the EVE file contains the event. The timestamp of the file update for the EVE file is not the anniversary of the time the machine was started, but is the time the event finished.

The STR file only appears to be updated on starting and stopping the machine.

If I get more time I'll see what else I can figure out.


STR.EDF Parameters:

1. Mask On, 2. Mask Off, 3. Mask Events, 4. Mask Dur, 5. Mode,
6. Set Pressure, 7. EPR Level, 8. EPR, 9. Max Pressure, 10. Min. Pressure
11. Mask Pres Med, 12. Mask Pres 95, 13. Mask Pres Max, 14. Therapy Pres Me, 15. Therapy Pres 95
16. Therapy Pres Ma, 17. Exp Pres Med, 18. Exp Pres 95, 19. Exp Pres max, 20. Leak Med
21. Leak 95, 22. Leak Max, 23. AHI, 24. HI, 25. AI
26. OAI, 27. CAI, 28. UAI

PLD.EDF Parameters:

1. Mask Pres (cmH2O), 2. Therapy Pres (cmH2O), 3. Exp Pres (cmH2O), 4. Leak (cmH2O), 5. RR (BPM)
6. Vt (ltr), 7. MV (L/min), 8. Snore Index, 9. FFL Index, 10. Unnamed
11. Unnamed

DreamDiver wrote:

Nord wrote:... Or... maybe I didn't have the Apnea at all since I can't find the Flow Data that it's represented. What else is happening or not happening ??? ...

Sorry for side-tracking, but this could be significant. I get flow data regardless of whether there are no events or 20 events in any specific mask event. Are you saying you get no flow data when there are no apneas?

Hi DD...

No... I believe that I'm getting all the Flow data normally. I think that for some reason, when the skew gets worse and it has been in my instance and maybe when it happened to you and Dave21... it may not print all the Flow Data to the SD card. I'm certainly, not sure why, and I believe we can trust the data until the skew begins to "misplace" events or data.

[ EDIT: If what Alterego reports is correct... then Events as we thought are recorded separately and independently of Flow Data. In other words the machine evaluates an Event and records it according to it's clock. Then Events can be counted on to be correct and in position since it is recorded at lower speed. Maybe Flow data to support the event might be "missing" if skewed but the event still happened. ]

I am presently testing methods to eliminate skewing that I would find practical to use "day in and day out".

I am convinced that ResScan is not the culprit at this point and since I can't test the S9 memory except to "power cycle" or replace the unit... that's not my focus right now. Some people have suggested they are not getting skews and are not using different cards or power cycling - I presume they are not looking yet or some units have to be replaced. Meantime...

I am going through a process with SD cards to see if I can eliminate the skew myself. We just don't have enough control over the process to make this effort scientific except through elimination of some of the variables.

Are you still getting the skew now ???

Nord

Just a thought...if it is true that the EVE file is written to the SD card on an event-driven basis (I must do some more testing on that tomorrow to be sure), a potential cause for data problems might be a cluster of events happening close together that the S9 doesn't buffer properly in on-board memory and/or is unable to write to the EVE file on the SD card fast enough.

If so, people with slow(er) cards and clusters of events would be more likely to see data problems, and those with widely spaced events and/or faster cards less likely. I'm new to the boards - does that fit the pattern we're seeing from other posters?

The following document shows what is recorded in the machines and what is not -- anything you can't download via an S9 USB adapter card (direct connection to machine) is stored only on the SD -- look at the table on page 1.

Resmed's data management guide

1. In ResScan, via the SD card, data for all parameters is available for viewing, as shown in the table above.
Via the S9 USB adapter and cable, data available for viewing includes only values for AHI/AI/CAI/OAI/UAI,
Leak, Pressure, and Usage.

alterego61 wrote:Just a thought...if it is true that the EVE file is written to the SD card on an event-driven basis (I must do some more testing on that tomorrow to be sure), a potential cause for data problems might be a cluster of events happening close together that the S9 doesn't buffer properly in on-board memory and/or is unable to write to the EVE file on the SD card fast enough.

I think you're right. It's not amount of data writted that is relelvant, its the speed of the hardware when switching from file name creation to writing, to new file name, etc.

Furthermore, according to the above document, the S9 is limited to recording 500 "events" per session -- a cache that only gets cleaned by power cycling may cause problems in this case.

Events
An event is the occurrence of a residual apnea or hypopnea. Events are recorded as they occur. The maximum number of events stored per session is 500

The above may be imprecise -- flow limitation are supposdely not events, and not counted, but they are recorded, and may therefore also be "events" in the cache.

alterego61 wrote:We are all learning about how the S9 collects and records its data. I did some brief testing and analysis this evening to contribute to the discussion, both by examining the data files using the EDF tools, and by experimenting with removing the card, or unplugging the machine before the mask event was finished, as well as by simulating apnea (!) to see what would be recorded on the SD card and when. ...

Awesome research, alterego61

So others can follow along, here's the link to EDF tools:
http://www.teuniz.net/edflib/
There's a free reader available here:
http://www.teuniz.net/edfbrowser/

It's pretty amazing what this software can visualize. Check it out!


This basically means the data format is an open, standardized format. Anyone who can access the edflib tools can create software or even a web app to view the data from this flow generator. Sweet.

That said - it looks like the data is written to the card for two parameters: flow and pressure at mask 25 times per second. Sounds to me like a slower card could hamper that.