Central Apneas and Respiratory Rate

[rested gal]

...following...trailing along at the rear...stumbling...following...panting to try to catch up... but always "following"...

Aw heck... gonna take time out to bake some muffins, then will get back in line to follow again.

Always interesting stuff. And I like to read it whether I follow well or not.

[john.michael]

I just recently got access to the detailed data from my Resmed VPAP Adapt AutoSV and I was wondering just this sort of thing. As far as I can tell, none of the graphs indicate that I am not breathing at the time of a recorded apnea. I will be looking at it more tonight and tomorrow night (in preparation for sleep Dr follow-up on Weds) and will post further details after that.

[idamtnboy]

Here's what I've got figured out. It's pretty much what has been suggested by NotMuffy, with a little of my own spin.

My explanation may sound a little bit simplistic, but if it gets the idea across, so be it. For this exercise think of the S9 as having two calculation routines running. The first I'll call Flow Analysis Routine or FAR. The second is the Respiratory Rate Routine or R3. FAR is constantly looking at the flow data and doing half a million things with it, including measuring the duration of each breath, which I'll call BD for breath duration.

Every time FAR sees a complete breath cycle it measures the duration of it and puts that number into a stack of numbers. What NotMuffy says about using 5 consecutive breaths makes sense, but it could be 3, 4, or 6, unless NotMuffy has some inside info to say for certain it is 5. After two iterations of trying to determine that for sure I give up. It's not critical to understanding what's happening. I haven't figured out just where in the breath cycle the stop watch is started and stopped, but I think it's probably when the expiratory to respiratory part of the cycle crosses the zero Y axis. The numbers I came up with come close to what's shown in the data from the S9, but not exact enough for me to say I have it figured out for sure.

Anyway, back to the process. FAR measures a BD and puts that number on the BD stack. Every time he does this the number on the bottom of the stack disappears so there are always 5 numbers in there. This is an irregular process because breathing is irregular. R3 is sitting on the side and his only job is to calculate the average of the 5 numbers in the BD stack. He divides the result into 60 to determine breaths per minute (BPM). He then gives this number to the little guy who is writing data to the SD card. R3 does this calculation every 2 seconds. He pays no attention to when FAR is putting a number on the stack.

During a central FAR is waiting for the next breath so he can measure it's duration. In the meantime R3 just keeps on calculating a BPM from the numbers in the stack, which of course are not changing. It's not practical(?) to try to put zero numbers on the stack. In order for R3 to calculate a number dividing into 60 come out zero, the number has to be infinity. This causes two problems. It's not feasible for FAR to wait long enough to decide he should put infinity in the stack because by then the patient is either breathing again or dead, and R3's calculator can't handle infinity anyway! So FAR says, "To heck with it, R3 can just keep using the numbers I already gave him."

Some have suggested the S9 routine suspends RR calculation during a central. Suspend implies deliberately stopping the update of data. I don't think it's so much suspend as it is just sitting there spinning wheels waiting for the next opportunity to measure a breath duration.

Now, we as humans can look at the graphs and immediately recognize that the BPM number should be zero. But it's not so simple for a computer to that, so once again we have an example of man beating machine!

Watson, you may have won the battle, but you haven't won the war yet!! Long live Watson, but longer live man!!

[NotMuffy]

What NotMuffy says about using 5 consecutive breaths makes sense, but it could be 3, 4, or 6, unless NotMuffy has some inside info to say for certain it is 5.

I believe there are 2 methods that ResMed uses to calculate Respiratory Rate:

Adaptive Servo Ventilation, which out of necessity must be breath-by-breath; and
VPAP (S/T), which employs signal averaging over a period of time:

Respiratory rate is sampled once every 2 seconds. The displayed rate is an average of the previous 5 breaths.

Given how the application is used here (which is actually an Easter Egg), it most certainly has to be the latter. This is evidenced by observing the behavior of premature, isolated breaths ("rogues"), which appear to artificially inflate Respiratory Rate for 5-breath periods.

In the sample below:



a 2-second grid has been placed demonstrating the signal sample update (coinciding with ResMed clock). Of interest is how the rate, which should have begun increasing with Breath 4, starts earlier. While there may be several explanations for this, I believe that the Respiratory Rate is calculated from initiation of inspiration (the upwards deflection which starts from -0-), and the ballistocardiographic artifact at 3A has contaminated the RR calculation.

Similarly, while respiratory rate should have slowed at Breath 6, another ballistocardiographic artifact at 5A (although without simultaneous EKG tracing, we can debate the the actual origin of the artifact) artificially maintains the high RR.

[-SWS]

Some have suggested the S9 routine suspends RR calculation during a central. Suspend implies deliberately stopping the update of data. I don't think it's so much suspend as it is just sitting there spinning wheels waiting for the next opportunity to measure a breath duration.

I don't understand the distinction. How would suspending or temporarily stopping any given update algorithmically differ from waiting to update? I'm formally trained in microprocessor algorithms and these two machine states sound equivalent to me.

[deltadave]

Following...

[KatieW]

...following...trailing along at the rear...stumbling...following...panting to try to catch up... but always "following"...

Me too!

[Pugsy]

rested gal wrote:...following...trailing along at the rear...stumbling...following...panting to try to catch up... but always "following"...

Me too!

Not me. I gave up a mile back. Sitting on a rock with eyes glazed over.........

[idamtnboy]

I don't understand the distinction. How would suspending or temporarily stopping any given update algorithmically differ from waiting to update? I'm formally trained in microprocessor algorithms and these two machine states sound equivalent to me.

The end result is the same. And this just may be a case of semantics.

The way I'm thinking is that there are two separate routines, among many, running in the S9. One, the FAR, is looping at a frequency of 25 Hz. One of the data points it's looking for is when the flow rate hits zero on the upward move (actually some minor +/- value as it will almost never sample the flow rate exactly on the zero point). At that moment it sets a time mark. The next time it sees the zero point it sets the next time mark and calculates the time span. It then puts that time value on the stack. Since breaths are variable in length the new number can be put on the stack at any point in time, regardless of the elapsed time since the previous update.

At the same time we have the R3 loop running constantly at 0.5 Hz. It runs regardless of the state of the breath flow, and outputs the BPM # every two seconds.

When we have an apnea the flow stays near zero. I'm suggesting the FAR continues to run at 25 Hz. But it doesn't set a time mark because the conditions to do so are not met. The way I see it, suspend means the part of the FAR that is looking to set the time marks is stopped by some other command from outside of itself. Its frequency of looping drops to zero, hence it does not update the stack because it stops watching the flow rate and so has no new number with which to update the stack. "Spinning its wheels" means the part of the FAR that sets the time marks continues to sample the flow rate at 25 Hz, but it does not see the conditions required to set the time mark, so it does not have a number to put on the stack. Either way, the end result is the same, the BPM number stays stagnant because the data used to calculate it stays stagnant.

I would think that in all of the microprocessor routines you've been involved with some are designed to loop forever, never stopping except for loss of power, but only spit out a result when certain conditions they read are met. Others, on the other hand, check for some outside parameter, and if that parameter is at the correct state, the loop stops dead in its tracks. The second one is suspended or killed depending on whether or not it can be restarted by an outside parameter, the first one is not, but neither is updating its result. Now, if I have it wrong please set me straight. I have no direct microprocessor experience but am a little bit familiar with command languages, do loops, computer program routines, logic diagrams, etc.

[idamtnboy]

Given how the application is used here (which is actually an Easter Egg), it most certainly has to be the latter. This is evidenced by observing the behavior of premature, isolated breaths ("rogues"), which appear to artificially inflate Respiratory Rate for 5-breath periods.
.....
Similarly, while respiratory rate should have slowed at Breath 6, another ballistocardiographic artifact at 5A (although without simultaneous EKG tracing, we can debate the the actual origin of the artifact) artificially maintains the high RR.

I wondered about the impact of those blips, or rogues, when I was looking at my flow graph and trying to determine where to set the zero crossover.

Are you expanding the definition of ballistocardiographic?

[idamtnboy]

Not me. I gave up a mile back. Sitting on a rock with eyes glazed over.........

You want glazed eyes?? Try Googling ballistocardiographic!!!

[Pugsy]

You want glazed eyes?? Try Googling ballistocardiographic!!!

So true. Though in all honesty I have been trying to follow this discussion but since I don't even have software that I can zoom in on I am truly watching with glazed eyes because I can't duplicate anything discussed in front of me and that is my easiest way to learn.
Probably best that I don't have ResMed so I won't be tempted to start down this road. I just look at my simple M series reports and go on my merry way, oblivious to any finer details I might be missing.

[idamtnboy]

So true. Though in all honesty I have been trying to follow this discussion but since I don't even have software that I can zoom in on I am truly watching with glazed eyes because I can't duplicate anything discussed in front of me and that is my easiest way to learn.
Probably best that I don't have ResMed so I won't be tempted to start down this road. I just look at my simple M series reports and go on my merry way, oblivious to any finer details I might be missing.

You are wise!

I steep myself at times in things technical because its in my blood and I like it. But, by God, I'll be the first to say it's not for everyone and you are probably far better off to keep it at an arm's length. Sometimes I wish I would! But I don't have an iPhone, and I'm running Win XP, which I upgraded to only when support died for Win 2000! And I don't own a GPS yet either! Maybe there is some modicum of sanity left in me!

[NotMuffy]

Are you expanding the definition of ballistocardiographic?

No, I'm sure the ones that are out there are OK.

[deltadave]

Are you expanding the definition of ballistocardiographic?

No, I'm sure the ones that are out there are OK.

I think he meant "WTF is 'ballistocardiographic?' "