HELP: Summertime exposes a big bug in OSCAR

[Crimson Nape]

If you used the Time Drift feature in the Preferences, it was designed (coded) to have a global effect, and is not specific to a day or range of days.  

The actual start time of your sleep session isn't really important, only the length of the sleep session is.  The only exception to my last statement is if the sleep session would occur at a day change, noon.

The oximeter data import feature allows for the oximeter's time to be adjusted to easily sync to the reported time of the CPAP.  This was to allow for any clock drift the CPAP may experience.

- Red

[PjotterHasApn]

Thanks. But it’s not helpful. 

The time drift function has nothing to do with this.
And it IS important to me that it is correct. Not only the start times, but also to be in sync with other device data. 

It seems to me that the goal should be to make OSCAR handle everything correctly. And not to say to it’s users that they should take everything with a grain of salt.

[darral.freund]

Hi,

I think you are correct that there is an issue of some sort.

I’ve also noticed irregularities in the times on certain days.  In my case, the time headings under the graph are an hour off, but when I point the cursor to a certain location on the graph, the time shown at the bottom of the OSCAR display is correct — differing from what the is shown on the graph scale immediately below the plot.  

See the attached figure.  The cursor is approximately at the 0400h point as shown on all the times immediately below the graphs.  But the time at the bottom of the screen is different by an hour (and in this case is the correct time — ~0300h).

The times on the Session Information tab are also correct, but are off from what is shown on the graph.

This issue doesn’t occur all the time, but I haven’t bothered to look at it more closely.  

Perhaps this is the issue you are seeing?

[PjotterHasApn]

Yes, I see you have the same issue..
This really should be fixed. It affects pretty much everyone with an Airsense 10/11. I know friends of me in the NL all have this issue.

Is there some developer of OSCAR that can pick this up? I would be glad to help him/her.

[PjotterHasApn]

I have some new info on the subject.

First, What I wrote previously isn’t entirely correct.
In actuality the graph is wrong, and the shown statistics are right. So it is the other way around then I initially thought.
Still a bug of OSCAR though. I’ve cross-checked this with ResScan (software from ResMed itself).
This goes wrong for older data (that is already imported into OSCAR), so data that was perfectly in sync (graph and everything else) in the wintertime, now isn’t in sync.

Another issue is something that isn’t a bug in OSCAR and that involves the new data (that hasn’t been imported yet). An Airsense 11 (don’t know for the 10) needs to be set to a timezone, and the timezone isn’t automatically adjusted going from winter- to summertime or reverse. So my Airsense 11 was set to GMT+1 (Netherlands), and now needed to go to GMT+2 because of summertime. This is something that one needs to do by hand 2 times a year. Not of this day and age if you ask me. To be able do this you have to clean the data from the machine first (not the SD-card).

[PjotterHasApn]

I like to add that I've checked it in ResScan (official software from ResMed), and it does handle summertime correctly. Its start times and graphs are perfect still for every day. Also the historical days that were already in there. This really only goes wrong in OSCAR! 

It is definitely a bug!

[PjotterHasApn]

I've reported the bug to OSCAR's GitLab project. We'll see..

[pholynyk]

It's not a bug... it's a design flaw inherited from SleepyHead.

As such,,it requires changes to each of the loaders - cpap, oximeters, all of them, changes in the display code, and additions to the Preferences window.

As Crimson Nape pointed out, the displayed times are not as important as the durations, so this design rewrite has taken a back seat to making sure the loaders collect data properly and the graphs are displayed with proper formatting. And all the oximeter importers need work, especially the CMS oximeters.

Both of the active developers are experience, retired programmers, volunteering their time. This problem has been in the back of my mind since I first noticed it in SleepyHead. We will get to it some time. Additional programmers are welcome, of course. OSCAR is written in C++ and uses the QT platform and Git for source control.

[PjotterHasApn]

Thanks for the feedback! It seems a bit passive aggressive, to be honest. I understand your point of view, but I disagree that this is a small issue. Especially since it effects probably all users, and it renders so much data invalid (half a year per year). 

I understand now that it isn’t a straight up easy fix. Maybe the time zone isn’t included in the records? 

I might have a look at the source myself. Can it be build in Visual Studio 2022?

[Crimson Nape]

At one time OSCAR could be built with Microsoft C++ compiler, but most of us use the free version of Qt to maintain uniformity across all OS platforms. Currently, the code compiles best with Qt version 5.12.8 with MinGw 7.3.0.

- Redwith