I'm volunteering for a task -- how big would it be?

[cathyf]

Awhile ago I decided that it would be useful to have an option for a joint graph showing inspiration time and expiration time together (in two contrasting colors, of course.) This seems like it would be a pretty straightforward addition -- more like a tweak since there is fully-functional code to produce two separate graphs, and I think it's based upon QT so it's a matter of passing parameters correctly to the QT functions?

I am officially volunteering to try to implement this... It's been a dozen years since I've done any QT programming (the line I always used: "I've slept since then") so it would obviously take me some time to come up to speed.

Can someone who is more intimate with the OSCAR source offer an opinion on how big a task this would be? Give me a rough outline of steps? A cookbook procedure for how to download the source, and set up a develop/build environment? Give me some opinions on your favorite tools?

[pholynyk]

I'm not sure any of us have looked at the graphs code very much. In that sub-directory, there are 18 cpp files and 18 header files, totalling about 18000 and 4000 lines of code respectively.

I'd be delighted to have somebody work through that code and understand it, and even better, document it. Mind you the lack of documentation hasn't stopped any of us from modifying it...

[sawinglogz]

It's also worth looking at some of the charts that *do* show multiple channels per graph, like leak (both unintentional and total) or EPAP/IPAP/etc. for reference.

For example, in daily.cpp:

Code:

   bool square=AppSetting->squareWavePlots();
   gLineChart *pc=new gLineChart(CPAP_Pressure, square);
   graphlist[schema::channel[CPAP_Pressure].code()]->AddLayer(pc);
    ...
   pc->addPlot(CPAP_EPAP, square);
   pc->addPlot(CPAP_IPAPLo, square);
   pc->addPlot(CPAP_IPAP, square);
   pc->addPlot(CPAP_IPAPHi, square);
   pc->addPlot(CPAP_PressureSet, false);
   pc->addPlot(CPAP_EPAPSet, false);
   pc->addPlot(CPAP_IPAPSet, false);

The graphlist[] is the set of charts shown in Daily view, currently identified by channel (so you can't have multiple pressure charts currently).

(I don't remember off the top of my head why AddLayer is needed. Guessing I would say it's so you can have layers like the dotted average lines be drawn as a separate layer?)

Then you can add multiple channels to the line chart via addPlot().

I think if you did something similar with the gLineChart below it might work:

Code:

graphlist[schema::channel[CPAP_Ti].code()]->AddLayer(lc=new gLineChart(CPAP_Ti, false));

e.g.:

Code:

lc->addPlot(CPAP_Te, false);

That should plot both Te and Ti on the same Ti chart.

Note that this would be a quick hack that can't really be merged into the master branch, since we'd first need to think about how to handle Ti vs. Te vs. Ti+Te graphs in daily view. (Should both Ti and Te graphs have the option to overlay the other? Or should we create a new channel that represents both? Should it have the option of charting breathing rate as well? etc.)

But for your own purposes this should get you started.

[2SleepBetta]

Great to see you taking this I&E project on, Cathy.

I have no clues about the programming, a total dunce there. I include, prematurely, some first-cut approximation results in the attachment to illustrate a cardio-data-"contamination "problem, which I think you will want to have simmering on a warm burner in the back of your mind as you work. 

Aside from cardio problem I write of  here there is an unresolved problem with timing in the attachment--timing seems OK part of the session, then seems out of whack at times. Gotta run that down. Nevertheless, the visible singlet-doublet problem, as well as how it is explained below, reflects an analysis and presentation challenge.

Using Excel to do breath by breath TVs and their drops for other posts it was a challenge, partly met, dealing with the complications from cardiogenic effects. Again with Excel, my recent  I and E work (relevant to flow limitation) has been an inadequate simple minded approach. The cardiogenic effect seems far more daunting and disruptive for I/E and duty cycle ratios than it had been for computing and presenting individual TVs. A low pass filter works well.

At this stage, given that I and E were not given by my old Autoset data, I naively used sign changes to mark breath phase changes,  dividing expiration time or total breath time into the I-time for the two ratios. I/E, estimated that way, was/is "wild" and for the graphs a huge high pass filter had to be applied--not so much for the duty cycle (I>0)  which can't be less than 1.0.

In this first cut, sampled as below, I didn't much care about absolute ratio values, just wanted to see variation and how that might relate to FL so scaling was only to make changes visible. 

In the graphic you see singlet and doublet spiking in the Somnopose window views of the two ratios. Singlets are most typically coincident with I-waves that have little or less cardio effect close to the zero axis than is the case of doublets. Sign changes trigger the spikes, but quite frequently (both in IE and TV work) the visible cardio is distinctly below the zero-axis as presented by OSCAR--as if there were no sign change at an I-E boundary. 

I believe OSCAR passes on the the effect of data it gets, no error there. But one can see in reading Resmed patents that pains are taken to be sure when true I begins for each I-wave. Cardio effect is a problem that will haunt one after rough work is done to get the lay of the land. My sense is that the zero-axis has a drift that may be set/rebalanced according to algorithm balancing of inflow and outflow across the session or some time window--maybe in some kind of post processing before the BRP file is closed. The zero axis is handled by the algo in a way it seems fixed, but by some Resmed "magic" it fits the FR curve quite well.

Far smarter heads here may disabuse me of confused thinking here. However, way back in my AB visits it seems I saw one of our AB experts dismissing as wrong (?) some kind of I/E type presentation that may have been available in Sleepyhead. (I had no idea what that meant then.) 

Good luck. I doubt I can help but would be glad to if shovel work I could handle needs to be done.

Meanwhile, I suggest those interested in I vs E times put the I graph above the E graph and look at large divergences between the curves for meaningful impressions of relative work done in drawing their breaths.

Note: The Somnopose Orientation view shows relative duty cycles, likewise, I/E is in the Inclination slot.

   

[SleepyCPAP]

Wow cathyf, what a great offer.

Please note that OSCAR reverses I and E on the machines I use most (right now ResMed AirSense 10 Autoset), but not for the time I used a ResMed AirSense 10 VAuto.  I don’t know if you’ll spot why it does that when you look in the graphing code, but it may not be an error there in that section.

[Gideon]

Cathy, After getting input from several of the developers, and you are still serious about tackling this. PM me and tell me where you are at with your thoughts on this development.

[Sleeprider]

As a side-note to this effort, the Resmed I/E times that are provided by the machines have always seemed pretty accurate, while Philips I/E is interpolated by Oscar. The Philipss I/E times are clearly inaccurate, nearly always showing the inspiration time as too long and expiration too short to be realistic. The problem seems to be the code was written to initiate Inspiration time precisely when respiratory flow reaches zero flow. In actuality, inspiration needs to begin at some point after positive inspiratory flow begins because expiration often includes a period of zero flow before inspiration begins. Actual inspiration is characterized by a rapid increase in flow from zero and determining the time from when flow increases from zero to when it decreases to zero indicating the start of expiration. We will be glad to show you graphically what this looks like and we have written an Inspiration/Expiration wiki that shows this. I would assume that the code for graphing I/E flow in both Resmed and Philips is accurate, however the algorithm to show the actual inspiration and expiration time is much different, again, with Resmed taking this data from the machine, while Philips is interpolated in a known inaccurate manner.

Great to see you taking on this project that exceeds my pay-grade.

[sawinglogz]

Yes, OSCAR's calculations generating Ti and Te (only used for Philips machines) are known to be broken. However, even broken they're evidently of some use to clinicians (spiky vs. not), so I haven't removed them.

[pholynyk]

Considering that the AS10 AutoSet doesn't report Ti and Te, I suspect OSCAR calculates those for ANY machine that doesn't report them.

The AC10 vAuto does report both the Ti and Te, as well as the I:E ratio.

So it's just as well you didn't remove that code...

[Crimson Nape]

Concerning the I:E ratio on the AirCurve 10; It seems that the S-mode doesn't report this value on the Daily screen, but it can be turned on in Preferences to display on the Overview screen. I've never thought about it until it was mentioned here. This is in both v1.2.0 and 1.3.0-Beta.