OSCAR Suggestions & Bug reporting

[Bamford]

Is your timezone two hours different than GMT?

I am at GMT-3 (Brazil), and changing the Clock drift (Preferences>CPAP) 2 hours made the Somnopose data match the APAP time for comparison. ( both wrong by 2 hours)

If the developer/tester needs the actual data, I can share the CPAP and Somnopose files.

As you can see, the "Orientation" is mismatched from "Flow Rate" by 2 hours.

screenshot-20190831-093304.png (73.22 KiB) Viewed 6479 times

Drifting the clock by 2 hours, the data match, but indicating the wrong time ( real +2)

screenshot-20190831-100350.png (70.76 KiB) Viewed 6479 times

[Chapalauser]

In another thread I was asked for where to submit suggestions.
You can feel free to PM me if you wish, either here or over on AB. But in this thread will work.
Suggestions will be considered, but no guarantee that or when they will be implemented. Most of the suggestions we have seen so far will, IMHO, be implemented.

Anyone that would like to contribute to OSCAR, please PM me (bonjour) over on Apnea Board http://www.apneaboard.com/forums/index.php. We can always use C++ / QT developers, Testers, and Translators for languages we do not yet have covered.

Fred Bonjour - Project Manager and Lead Tester for OSCAR - Open Source CPAP Analysis Reporter

In my welcome screen it says " Your ipap pressure was under 0 cmH20 for 95% of the time."

[djams]

OSCAR isn't tracking my "changes to prescription settings" properly.

Below shows OSCAR vs Sleepyhead 1.1 prescription changes over identical time periods. The only "event" that I can point to is that I used my backup machine for an overnight trip on 08/24. But I also used it on 06/08, and as you can see it didn't cause any problems on that night. The sleepyhead information is correct.
FWIW, Sleepyhead 1.0 also shows the data correctly.

I import my data every 2-3 weeks or so, in case that's useful.

If you need anything from me that might help, let me know.

SH_1_1_PerscriptionChanges.png (30.09 KiB) Viewed 6455 times

OSCAR_PrescriptionChanges.png (36.61 KiB) Viewed 6455 times

[BlueDragon]

OSCAR isn't tracking my "changes to prescription settings" properly.

Below shows OSCAR vs Sleepyhead 1.1 prescription changes over identical time periods. The only "event" that I can point to is that I used my backup machine for an overnight trip on 08/24. But I also used it on 06/08, and as you can see it didn't cause any problems on that night. The sleepyhead information is correct.
FWIW, Sleepyhead 1.0 also shows the data correctly.

I import my data every 2-3 weeks or so, in case that's useful.

If you need anything from me that might help, let me know.

I would need to see a zip file from both of your machines and maybe the OSCAR_Data folder as well to determine what is happening. But mixing machines together can cause confusion.

The order in which you import from different machines can have a big impact. Depending on the timing and sequence in which you import from the two cards, you can get different daily summary data from which the prescription settings are obtained. This is related to the problem of not being able to import data from the same day twice. If, for whatever reason, you have summary data from one machine, you can't import it again from another. The fact that you import data only every 2-3 weeks magnifies the problem.

Of course, if you are importing always from SD cards from both machines at the same time, and the machines in the same order, on both SH and Oscar, the two programs should give the same result. Are you that methodical about importing data?

How large is your OSCAR_Data directory? I'll see if I have enough space left in Dropbox for an upload there.

If you want me to follow up on this, I suggest starting a new thread so we can keep the discussion focused on just your problem.

[djams]

Awesome response

Thanks! We're heading out early for a full day at friends lake house - It'll be tomorrow before I can get to this.

[BlueDragon]

Thanks! We're heading out early for a full day at friends lake house - It'll be tomorrow before I can get to this.

I hope you have a great time!

When you get back, I suggest two things for you to try to see what happens (before going to the trouble of sending me your data files):

First, create a new profile. Import the SD card from your regular machine. Then import the SD card from your backup machine. Next, create another new profile. This time, import first from your backup machine and then from your regular machine. How does the list of prescription changes compare in these two new profiles?

Second, I can provide you with a custom version of Oscar that will include the machine serial number in the prescription changes list. (A prescription change is identified when you change to a machine of the same type but a different serial number. Since the serial number is not included in the report, it's hard to tell what is happening.) I'll send you a PM with directions on how to download that test version.

[djams]

When you get back, I suggest two things for you to try to see what happens (before going to the trouble of sending me your data files):

First, create a new profile. Import the SD card from your regular machine. Then import the SD card from your backup machine. Next, create another new profile. This time, import first from your backup machine and then from your regular machine. How does the list of prescription changes compare in these two new profiles?

I see the same results either way.

Second, I can provide you with a custom version of Oscar that will include the machine serial number in the prescription changes list. (A prescription change is identified when you change to a machine of the same type but a different serial number. Since the serial number is not included in the report, it's hard to tell what is happening.) I'll send you a PM with directions on how to download that test version.

After seeing in the test version that the machine SN is listed in the "Changes to prescription" area, it dawned on me that we may have a fundamental difference of opinion on how accounting for the different machines should be handled. To me, if I switch to my backup and the settings are the same as my primary machine - the Stastics tab count of days at these settings shouldn't change. I fully expected to see the machine SN listed somewhere on the daily tab somewhere. Maybe it is and I missed it.

Is the design intent to have the Statistics page recalculate/refresh when "include serial number" is toggled on/off? I'd be real happy with that.

Are you that methodical about importing data?

Most definitely not.

I hope you have a great time!

We had a wonderful day!

[BlueDragon]

After seeing in the test version that the machine SN is listed in the "Changes to prescription" area, it dawned on me that we may have a fundamental difference of opinion on how accounting for the different machines should be handled. To me, if I switch to my backup and the settings are the same as my primary machine - the Stastics tab count of days at these settings shouldn't change. I fully expected to see the machine SN listed somewhere on the daily tab somewhere. Maybe it is and I missed it.

Is the design intent to have the Statistics page recalculate/refresh when "include serial number" is toggled on/off? I'd be real happy with that.

Thanks for your testing.

You can see the serial number if you cursor over the CPAP machine information in the upper left of the Daily page. The serial number will be shown in a tooltip.

Your issue has sparked a discussion in our developer's forum about what should be on this list and what constitutes a "prescription change." There are varying opinions. I admit that my first thought was the same as yours -- combine the results from both machines. But there are complications to consider.

Currently, the "include serial number" option affects only whether the serial number is displayed on the report. There is no change in the way the report is prepared. (I will also look into why SH 1.1 and Oscar show a different summary.)

I have logged this issue in our project log. I don't know when an OSCAR version might change how this report is prepared (but it probably will be some day).

[djams]

After seeing in the test version that the machine SN is listed in the "Changes to prescription" area, it dawned on me that we may have a fundamental difference of opinion on how accounting for the different machines should be handled. To me, if I switch to my backup and the settings are the same as my primary machine - the Stastics tab count of days at these settings shouldn't change. I fully expected to see the machine SN listed somewhere on the daily tab somewhere. Maybe it is and I missed it.

Is the design intent to have the Statistics page recalculate/refresh when "include serial number" is toggled on/off? I'd be real happy with that.

Thanks for your testing.

You're more than welcome. But really, you deserve the thanks. The entire team too of course - but here at CPAPTalk, you're our OSCAR liaison, and you're doing a great job. You're committing a lot of personal time to making OSCAR a better product, and it's MUCH appreciated. So thank YOU!

You can see the serial number if you cursor over the CPAP machine information in the upper left of the Daily page. The serial number will be shown in a tooltip.

There it is! Thanks.

Your issue has sparked a discussion in our developer's forum about what should be on this list and what constitutes a "prescription change." There are varying opinions. I admit that my first thought was the same as yours -- combine the results from both machines. But there are complications to consider.

Currently, the "include serial number" option affects only whether the serial number is displayed on the report. There is no change in the way the report is prepared. (I will also look into why SH 1.1 and Oscar show a different summary.)

I have logged this issue in our project log. I don't know when an OSCAR version might change how this report is prepared (but it probably will be some day).

Discussion is always good. Long as there aren't too many cooks in the kitchen, usually comes to the best conclusion. Thanks for logging the issue.

[slowriter]

I built from master github repo on Linux a few days ago, and just noticed the screenshot function doesn't work correctly. Results in a mostly black image.

Would really help to have a bug tracker, to know if this has already been reported, etc.

[BlueDragon]

I built from master github repo on Linux a few days ago, and just noticed the screenshot function doesn't work correctly. Results in a mostly black image.

Would really help to have a bug tracker, to know if this has already been reported, etc.

Just to confirm, what version of OSCAR did you build?

This issue is not on our list. Could you include a screenshot so we can see how bad it is?

[slowriter]

I see the behavior in what's marked "testing-4"; eaf2081.

And it's literally a black image; completely.

On my other machine, there were also a few lines.

It's completely unusable.

Not that it's a huge practical problem, because I can use other ways to get a screenshot. Just thought you should know.

[jsmit86]

I am having issues using OSCAR on 2 Lenovo ThinkPad machines.

Currently, I have loaded it on a Yoga 14 Thinkpad running Windows 10.
I have tried both the 32 and 64 bit versions.

I can install, and create and load a profile.

The issue is that I cannot click on any of the Navagation menu options, and the file options are all grayed out.
As an example, clicking on Open Profile, Edit Profile, New Profile does nothing.
Same issue clicking on Statistics, etc.

Any suggestions?

[jsmit86]

I think I just figured it out.
Changed to OPEN GL, and now it works.

Now I just need to study how to format graphs and post to get an opinion.

Generally, I think I'm OK, but it would not hurt to have an expert look at the data.

[palerider]

I see the behavior in what's marked "testing-4"; eaf2081.

And it's literally a black image; completely.

On my other machine, there were also a few lines.

It's completely unusable.

Not that it's a huge practical problem, because I can use other ways to get a screenshot. Just thought you should know.

I'm using testing-4 built from gitlab on a thinkpad w520, running ubuntu 18.04 and the screenshot works fine. (as a data point).