Central Apneas and Respiratory Rate

[idamtnboy]

It's my understanding that Central apneas are caused by the brain failing to send signals to the respiratory muscles to breathe. If the respiratory muscles don't receive a signal from the brain then they don't move, right? If they don't move then there is no flow in or out of the lungs. Respiratory rate is defined as breaths per minute. So how come when I have a CA and supposedly am not breathing, the S9 still reports me as having about 20 bpm? Can anyone explain why the Resscan graphs show me as having an RR of about 20 when the flow graph shows the flow rate near zero? The graphs also show me as having a minute ventilation volume and a tidal volume when I'm shown as having a CA.

In the graph below all the graphs other than events need to be shifted to the left about 17 seconds with respect to the flow graph because of data skew.

[Lizistired]

I don't know but, how do you get Respiratory Rate and Tidal Volume? I've never seen those. Is that new on version 3.7?

[-SWS]

Can anyone explain why the Resscan graphs show me as having an RR of about 20 when the flow graph shows the flow rate near zero? The graphs also show me as having a minute ventilation volume and a tidal volume when I'm shown as having a CA.

I'm guessing the graph designers decided the flow graph alone reflects apnea low-flow moments adequately. They probably made a design decision to reflect rate type graphs with larger granularity and likely using one of several curve-fitting techniques: http://curvefit.com/avoid_linearizing.htm .

I don't know but, how do you get Respiratory Rate and Tidal Volume? I've never seen those. Is that new on version 3.7?

These instructions compliments of gvz:
viewtopic.php?f=1&t=54652&st=0&sk=t&sd=a&#p510493

[jedimark]

I'm guessing data points aren't recorded during the events (because they are 0, or less than a threshold)

Note the flat line between points. There may not actually be any data points between these times. (as in it's just the method used for graph display)

PS: Thanks for posting that picture. I like the look of the way ResMed does it. Respironics Encore is mostly a rats nest.
I may "borrow" a couple of those User Interface ideas and reimplement them for my open-source software.

[NotMuffy]

I'm guessing data points aren't recorded during the events (because they are 0, or less than a threshold)

Note the flat line between points. There may not actually be any data points between these times. (as in it's just the method used for graph display)

In looking at an event from an S8 file, it appears that data continues to be updated:



so my guess in the pool is that initiation of FOT in the S9 algorithm suspends data point update, otherwise you'd get a Respiratory Rate of 240 (although I imagine they could have increased that threshold a bit)(yet upon further reflection, why go through this humongous list of IF THENs that you'd have to turn off once FOT's off just to make waveforms "accurate" (cause Vt and VE are trend values) that no one normally sees anyway).

[deltadave]

...initiation of FOT in the S9 algorithm suspends data point update, otherwise you'd get a Respiratory Rate of 240 (although I imagine they could have increased that threshold a bit)(yet upon further reflection, why go through this humongous list of IF THENs that you'd have to turn off once FOT's off just to make waveforms "accurate" (cause Vt and VE are trend values) that no one normally sees anyway).

It wouldn't be all that involved. Simply setting up a high filter at FOT (4 Hz) would eliminate FOT "artifact" and the calculations could easily be made, as seen in this respiratory effort channel pre- and post- filter application:



One would, however, need to also run an unfiltered signal in order to be able to visualize FOT in the flow channel.

[NotMuffy]

Oh you think you're the cat's banana.

[-SWS]

I was going to offer that filtering the fixed FOT frequency obviates having to suspend data-point collection. Also, if the rate type graphs never go close to zero, then I still suspect some type of curve-fitting is at work rather than continuous plotting of discrete points.

In any event, I think this is the result of a graph-design decision rather than a software bug:

Can anyone explain why the Resscan graphs show me as having an RR of about 20 when the flow graph shows the flow rate near zero? The graphs also show me as having a minute ventilation volume and a tidal volume when I'm shown as having a CA.

[dilbert]

Does the 32 in the above graph represent the seconds of an apnea event? I just started on CPAP this week and I am trying to interpret the charts and learn the language.

[idamtnboy]

Data recording is not suspended during a central. Here's the numbers from the PLD file for RR for that time period. The start and stop may be off a little from the graph but there's numbers like this all through that time period. The graph line is an exact plot of the numbers. There's no curve fitting being done.
18.2
18.6
19.8
19.8
20.4
20.4
20.4
19.0
19.0
19.0
19.0
19.0
19.0
19.0
19.0
19.0

[idamtnboy]

Does the 32 in the above graph represent the seconds of an apnea event? I just started on CPAP this week and I am trying to interpret the charts and learn the language.

Yes.

[-SWS]

... there's numbers like this all through that time period. The graph line is an exact plot of the numbers. There's no curve fitting being done.

Rhetorically are those: 1) sensor-sampled discrete RR points (a signal-processing impossibility), or 2) already-processed plot values sitting in a graph table?

No curve fitting if case one were possible. But curve fitting is entirely possible if case two. And since those points are each a "calculated rate" they are already processed. After all, there is no such thing as a raw RR data sample at the sensor. So individual rate plot-points sitting in a table implies that SOME signal processing had to have already occurred... And we cannot infer how much signal processing went into those table values. Curve fitting might very well have been part of the preliminary processing that went into filling out the table of plot values.

[idamtnboy]

... there's numbers like this all through that time period. The graph line is an exact plot of the numbers. There's no curve fitting being done.

Rhetorically are those: 1) sensor-sampled discrete RR points (a signal-processing impossibility), or 2) already-processed plot values sitting in a graph table?

No curve fitting if case one were possible. But curve fitting is entirely possible if case two. And since those points are each a "calculated rate" they are already processed. After all, there is no such thing as a raw RR data sample at the sensor. So individual rate plot-points sitting in a table implies that SOME signal processing had to have already occurred... And we cannot infer how much signal processing went into those table values. Curve fitting might very well have been part of the preliminary processing that went into filling out the table of plot values.

I would say they fall into the #2 category. These numbers are what the S9 writes to the SD card. How much signal processing is done inside the S9 is anybody's guess! Well that is anybody outside of Resmed! I was thinking just today with as much data as that baby sucks in and spits out, and the real-time processing it does to classify the events, etc., there actually must be a fairly powerful computer chip inside.

I suppose curve fitting could be being done inside the S9, but it's not being done by Resscan.

[-SWS]

How much signal processing is done inside the S9 is anybody's guess! Well that is anybody outside of Resmed!

Yup... and a fun guessing game at that...

I was thinking just today with as much data as that baby sucks in and spits out, and the real-time processing it does to classify the events, etc., there actually must be a fairly powerful computer chip inside.

Agreed. And in the case of APAP, there's the treatment algorithm that must respond in real time as well.

[quote="="idamtnboy"] I suppose curve fitting could be being done inside the S9, but it's not being done by Resscan.[/quote] I'm guessing Resmed had portability and commonality in mind for some of their xPAP data routines. The Resmed adaptSV, for instance, uses a sliding-average of minute volume toward real-time treatment responses. That would be an example of a data-normalized rate calculation necessarily occurring inside the PAP machine---versus PC-side. So in that case, Resmed would WANT all the signal-processing and data-normalization residing in the PAP firmware toward executing those rate-based treatment decisions.

[DreamDiver]

following