ALL CLEAR about the urgent warning

[BernieRay]

...I always download the data before noon and choose "Discard Duplicate Data" when prompted.

Me, too. That had nothing to do with the loss of stats/summary data.

[mstevens]

I understand what you are saying but that gap SHOULD be between 0200 and 0300 SUNDAY morning, not MONDAY morning.

Agreed. Since the same thing happened for a single night last year, this may be an artifact of ResMed's convention of having a "day" run from noon to noon instead of midnight to midnight.

And there would ONLY be a gap if the CLOCK had ACTUALLY changed DURING data collection -- it did not.

I'm not so sure. Data may have been collected without a gap. Collection and display are different things, though. The software (ResScan) still needs to reflect reality. Reality says there is no clock time between 0200 and 0300. If the software shows data then, you know something's screwy.

Here's a far-fetched but plausible real-world example: let's say a traffic camera made in Peru with a long focal length tracks a slow car over a straight stretch of road for 4 minutes starting at 0158 local time on Sunday morning. It doesn't stop filming or recording speed at all over that time. The clock on the camera is set to the time in Peru where it was manufactured and they don't observe DST, so the time on the recordings never skips. Later, in court, a witness shows a graph of the car's speed (or position or any other variable) vs. clock time. If there's no one-hour gap, the person who made the chart is making something up, either filling the gap with something that didn't happen or misreporting the time when the car was present.

I went to bed approximately 2200 on Sunday evening (and that's when my graphs start),

2200 Standard Time or DST? If the latter, your clock was set incorrectly at that time since the time didn't change until 0200. I'll assume you mean you actually went to sleep at 2100 Standard Time, displayed as 2200 on your S9, and woke up at 0443 DST, displayed correctly on your S9. This still doesn't explain your missing hour described below.

I awoke at approximately 0443 on Monday morning (and shut my machine off and removed the mask) and that's when the graphs stop. Note, I also was off mask from 22:21 to 22:25 and 22:31 to 22:46 (a total of 20 minutes) due to fighting with my masks.

The timespan between going to bed (2200) and waking up (0443) is 6:43 minutes and that minus the 20 minutes off mask yields 6:23 minutes which is exactly the timespan shown on my Summary data as being in mask.

Now charts show data between 2200 and 0200 (4 hours) and 0300 and 0443 (1 hour 43 minutes) for a total time of 5:43.

So if we did not lose any data -- just "skipped" over that hour then where is the other 1 hour's worth of data

Odd. My summary and detail graph match exactly in terms of total time. I downloaded from my card right before posting, or mid-afternoon. Did you download before noon?

Since ResMed has not made time setting on the S9 settable by the user and that most users probably never bother, I wonder if we're confusing ResScan by changing the time on our machines?

[Tip10]

I understand what you are saying but that gap SHOULD be between 0200 and 0300 SUNDAY morning, not MONDAY morning.

Agreed. Since the same thing happened for a single night last year, this may be an artifact of ResMed's convention of having a "day" run from noon to noon instead of midnight to midnight.

And there would ONLY be a gap if the CLOCK had ACTUALLY changed DURING data collection -- it did not.

I'm not so sure. Data may have been collected without a gap. Collection and display are different things, though. The software (ResScan) still needs to reflect reality. Reality says there is no clock time between 0200 and 0300. If the software shows data then, you know something's screwy.

I agree there is no clock time between 0200 and 0300 on SUNDAY 3/13 -- however the time period in question is 0200-0300 MONDAY 03/14 and there most definitely is a clock time for that period.

Here's a far-fetched but plausible real-world example: let's say a traffic camera made in Peru with a long focal length tracks a slow car over a straight stretch of road for 4 minutes starting at 0158 local time on Sunday morning. It doesn't stop filming or recording speed at all over that time. The clock on the camera is set to the time in Peru where it was manufactured and they don't observe DST, so the time on the recordings never skips. Later, in court, a witness shows a graph of the car's speed (or position or any other variable) vs. clock time. If there's no one-hour gap, the person who made the chart is making something up, either filling the gap with something that didn't happen or misreporting the time when the car was present.

I went to bed approximately 2200 on Sunday evening (and that's when my graphs start),

2200 Standard Time or DST? If the latter, your clock was set incorrectly at that time since the time didn't change until 0200. I'll assume you mean you actually went to sleep at 2100 Standard Time, displayed as 2200 on your S9, and woke up at 0443 DST, displayed correctly on your S9. This still doesn't explain your missing hour described below.

DST because it was 2200 SUNDAY evening -- we were already almost 20 hours into DST so the clock was indeed set correctly -- just as it was when I awoke at 0443 DST.

I awoke at approximately 0443 on Monday morning (and shut my machine off and removed the mask) and that's when the graphs stop. Note, I also was off mask from 22:21 to 22:25 and 22:31 to 22:46 (a total of 20 minutes) due to fighting with my masks.

The timespan between going to bed (2200) and waking up (0443) is 6:43 minutes and that minus the 20 minutes off mask yields 6:23 minutes which is exactly the timespan shown on my Summary data as being in mask.

Now charts show data between 2200 and 0200 (4 hours) and 0300 and 0443 (1 hour 43 minutes) for a total time of 5:43.

So if we did not lose any data -- just "skipped" over that hour then where is the other 1 hour's worth of data

Odd. My summary and detail graph match exactly in terms of total time. I downloaded from my card right before posting, or mid-afternoon. Did you download before noon?

Since ResMed has not made time setting on the S9 settable by the user and that most users probably never bother, I wonder if we're confusing ResScan by changing the time on our machines?

I agree with you however that this is likely a result of the way in which the data has been collected, is being washed through the OS and then presented to the software.
I'll go out on a limb here and speculate that even though this data is for the early morning hours of MONDAY 3/14 (clearly DST) the S9 is actually collecting it and time stamping it with a time stamp saying that it is ALL data from SUNDAY 3/13 and is relying on the software to split is back into its proper positioning for a Noon - Noon day.
I'll also guess that it may even be using a offset from end time (and not absolute time stamp) to position the points-- which would explain some of the double data entries I'm seeing on the charts.

The only way to confirm this would be to go back and look at the individual data points stored in the raw files from the machine. Unfortunately I can't do that since I'm at work and they are at home. If I get a chance tonight I'll see if I can simple extract the raw data from the card and then go about looking inside to see what it really says for the period in question.

Oh, and I don't think it matters one bit if you change the time on the machine or not -- I believe you'll see the same thing.

[DreamDiver]

You may be interested in this thread from last year around this time, also just after the change to DST: viewtopic/t61557/viewtopic.php?f=1&t=50244.

I changed the clock on my S9 yesterday afternoon, just after 1:00. I only download the data into ResScan once a week now (Sunday mornings), so I won't know until then if anything's out of the ordinary. I always download the data before noon and choose "Discard Duplicate Data" when prompted.

As a result of the post you quoted from last year, A ResMed technical associate asked for a copy of my SD card for that week. It was determined that this is an artifact of the time change, and that it is normal. No data is missing.

I'd be very surprised and would like to hear about anyone who doesn't show the gap.

[DreamOn]

Thanks, DreamDiver! I figured that you had probably followed up on the situation last year and would know more, so I was hoping that you'd see this thread.

...I always download the data before noon and choose "Discard Duplicate Data" when prompted.

Me, too. That had nothing to do with the loss of stats/summary data.

Oh yes, I know that choosing "discard" has nothing to do with the loss of data. idamtnboy had mentioned it on the first page of this thread, so I just thought I'd mention that that is my standard practice.

[BernieRay]

Here's a screen capture showing the data that was collected last night between 2 and 3 in EDFBrowser vs what ResScan shows:



I couldn't get the graphs to line up exactly to scale, but EDFBrowser clearly shows 3 peaks between 2 and 3 that aren't shown in ResScan. Since the graphs match before 2 and after 3 (and start and end at the correct times), then the only logical conclusion is that either ResScan ignored that part of the data during the download, or is programmatically not displaying it. Either way, it is effectively lost in ResScan.

The comments from last year do not explain why a save in ResScan caused my stats and summary data for all dates to be lost.

I've restored my summary.dat from yesterday morning, which got my stats and summary data back for everything prior to last night. I've also erased my card, in the hope that it will prevent my stats and summary data from being trashed again in the morning.

[idamtnboy]

Right now I'm going with the argument this is a Resscan issue. Resscan must have some screwed up DST routine coded into it. Why? Good question. This exact same problem was noted by DreamDiver last year, the day after DST. Nobody, as far as I recall, mentioned a similar problem last fall when we went back to standard time. It's rather surprising that in all the revisions of Resscan in the past year this screw-up hasn't been fixed. Especially considering the fact there is no DST option built into the S9.

mstevens, in response to some of your comments about the OS and Resscan processing the data from the S9, I don't think so. Pretty much everything I've been able to determine from looking at the files from the S9 has shown that Resscan is a relatively dumb program that does not much more than just combine various files from all the mask sessions in one day into a rather pretty graphical representation. It does very, very, little massaging of the data. In fact the only thing I've seen Resscan do to the data is scale it for the graphs, like convert flow from lps to lpm.

The data in the hi-res (BRP) and detail (PLD) files are continuous as you can see in the graphs below. In last year's post DreamDiver noted that in Resscan the oximetry data graph did not have a corresponding break. That has to be because the oximetry data is recorded in the SAD file and obviously Resscan handles the SAD file differently. Confusing? Yes. Just shrug your shoulders and keep going is about all I can say!

[DreamDiver]

Here's a screen capture showing the data that was collected last night between 2 and 3 in EDFBrowser vs what ResScan shows:
[image]
I couldn't get the graphs to line up exactly to scale, but EDFBrowser clearly shows 3 peaks between 2 and 3 that aren't shown in ResScan. Since the graphs match before 2 and after 3 (and start and end at the correct times), then the only logical conclusion is that either ResScan ignored that part of the data during the download, or is programmatically not displaying it. Either way, it is effectively lost in ResScan.

And the comments from last year do not explain why a save in ResScan caused my stats and summary data for all dates to be lost.

That makes sense that it should be contiguous in edf files.
Hit 'Discard Duplicate Data' when it asks you. That sould stop all your flow and other data from being lost. If you have been in the habit of saving images of your SD card, you will be able to recoup the missing data back into ResScan. I don't have a handle on this, but others (perhaps Idaho Mountain Boy) will likely be able to help you there.

Right now I'm going with the argument this is a Resscan issue. ...

Agreed. The solution may not be elegant, but it doesn't break confidence in the data. There would be no gap in the fall change. If anything, there would be overlap. It might be interesting to go back and look at the edf data from the days of, before and after the fall time change to see what actually happened there.

[BernieRay]

I've already said this a couple of times - I ALWAYS CHOOSE THE DISCARD DUPLICATE DATA OPTION. I even restored my entire patient folder and re-downloaded the card 4 additional times today just to be sure. I got the same results all 5 times - upon saving and restarting ResScan the summary data was lost in the charts (the correct symbol as shown in the browser) and the stats from last year are displayed for every day that I've used the S9. I would write that off to something flaky happening during the download, but after seeing the exact same thing all 5 times, I am 100% confident that I am doing the download exactly the same way that I have been doing it for 3 months. I am also 100% confident that the root cause of my trashed stats and summary data is caused by something on the card from last night.

Let me iterate this one more time. The stats and summary data for all days is okay AFTER the download. It is only after saving last night's new data that it is trashed, and that only becomes apparent after ResScan is closed and re-started. I'm convinced that something in regards to the DST gap is the cause of this but I am at a complete loss as to why this has only happened to me.

Right now I'm going with the argument this is a Resscan issue. Resscan must have some screwed up DST routine coded into it. Why? Good question.

I agree completely. It is as if ResScan was able to detect the manual time change we made on the S9 (my guess is through STR.EDF) and assumed it needed to create a gap in the next day's data. I wonder what would have occurred if we'd set the clock ahead 1 hour on Saturday night instead of Sunday. It certainly seems as if that is what ResScan expected. Then again, if it had done that and simply shifted the 2:00 and later data by 1 hour, then my session for last night would have ended at about 6 this morning, instead of the correct 5.

I don't expect software built by others to operate the way I want it to, but I do expect to be able to figure out how it does work. Parts of ResScan are an enigma to me and that just sticks in my craw.

[idamtnboy]

I've restored my summary.dat from yesterday morning, which got my stats and summary data back for everything prior to last night. I've also erased my card, in the hope that it will prevent my stats and summary data from being trashed again in the morning.

At this point I think you were the victim of some strange quirk in your system. So far no one else has reported a loss of data and I have been unsuccessful in creating a data loss situation. I downloaded my data off the card into a copy of my patient file as it was yesterday, with all files' attributes turned off so the program was free to wipe them out, and saw no data loss.

Considering all the above I'm going to proclaim an all clear, unless someone has some reason why I shouldn't. I'll wait a few minutes for responses.

[BernieRay]

Yeah, it seems apparent that something went south on the save of my summary.dat file. I can re-produce it at will, though, which is why I now really suspect something wierd happened on the card as the root cause. That's why I'm hoping the card erase will prevent this from being an ongoing issue.

I am glad it didn't happen to anyone else.

Update - erasing the card didn't help. After letting the S9 recreate STR.EDF, it trashed my stat/summary data exactly the same way.

I've going to revert Rescan back to Thursday, and re-download my card backup from Sunday morning. If I don't have a problem with that, then the S9 is the root of my problem and I'll try a reset on the device.

[idamtnboy]

I am also 100% confident that the root cause of my trashed stats and summary data is caused by something on the card from last night.

You still have a copy of the SD card as was this morning? I'd like to see it. Do you have some place you can upload a zip file of it so I can get it? If so, and you're interested in me looking at it, PM me with info. Thanks.

I wonder if changing the time on your S9 between the last mask session and noon has anything to do with the data trashing. I, and probably most others, changed the time between noon and the first mask session of the night. So far that's the only clue I can latch onto as too why you lost your data. I do wonder also if something got messed up in the STR.edf file because of that.

[Lizistired]

Maybe it was the moon.
My oximeter report started at 01:18:00
My ResScan sleep starts at 01:00:30

I sync'd both clocks before I went to bed, and the alarm clock.
I started the oximeter record function right before I put my mask on.
I just double checked the clocks and they are exactly the same.

[idamtnboy]

Maybe it was the moon.
My oximeter report started at 01:18:00
My ResScan sleep starts at 01:00:30

I sync'd both clocks before I went to bed, and the alarm clock.
I started the oximeter record function right before I put my mask on.
I just double checked the clocks and they are exactly the same.

The S9 has a problem keeping the other graphs in sync with the flow graph, especially after several weeks of use without reformatting the card. I've seen differences upwards of several minutes. Considering the oximetry data is foreign, i.e., not native to the S9 internal program, it wouldn't surprise me to see huge differences between start times. I've also seen differences such as other graphs lagging the flow by 20 seconds in the first mask session of the night, and then switching to 20 seconds leading in the second mask session.

I am of the firm belief the S9 has a problem with its data recording system.

[Lizistired]

...I am of the firm belief the S9 has a problem with its data recording system.

I think we probably ask more of it than is usually asked. I mean really, how many hours have you spent on data today.
No Med Prof is going to look that deeply.
Most of it seems to be general info that can be used to assess sleep disorder pogress. That's good, because a doc doesn't want to ahve to look at breaths. I don't feel that it is that accurate, but am glad it is there to help me learn what I should be looking for.