#170 Respiration rate spikes?

[NightSkyTech]

My SH respiration rate spikes up to 50 many times per night. I'm not sure if there's a glitch somewhere in the scoring, but that seems a bit high. I've attached a few screenshots showing spikes up to 50 during centrals where I don't think I'm breathing at all..?

Any idea what's happening?

Thanks,
Joe

[Mark Watkins]

I just noticed you have a ResMed machine, I missed it in the second screenshot.. I know it doesn't help much, but I kind of get to pass the buck on this one :/

ResMed machines calculates this information inside the machine, so they are unfortunately to blame for any glitches there, I'm just passing the pre-calculated data as delivered by the machine.

I can give you a little insight into why this happens, because I wrote code in SleepyHead to generate these graphs for Philips Respironics machines from the FlowRate waveform data, which don't provide any of these related graphs by default.

Part of the issue is caused by too low resolution (Hz) of flow waveform graphs, and the other issue is the way the algorithms work.. They work by first flagging the peak, midlines and lowest portion of each breath, and then calculating the various related graphs off this data. When breathing goes haywire from apneas, the "pressure pulses" or ripples the machines generate, along with the general weirdness of what's going on in the throat/lungs/whatever can mess up the flagging, and it leads to these outlier areas spiking like this.

There is not much I can really do with ResMed, because even though I could technically replace their graphs with my own calculations, I'd rather not interfere with already provided data channels, generated by algorithms which should (in theory, according to the millions of dollars that were (hopefully) invested by ResMed into this) be better than what I came up with. Plus ResMed flow-rate waveforms are offset for some silly reason and it makes things a little more ugly to deal with. (Not hard to fix, I just haven't diverted any thought to it yet)

As for my calculations (and ResMed's too providing they give a hoot about accuracy), several things could be done to improve the results, one is better input waveform filtering. But it's incredibly difficult to tweak the filters to be consistent with all provided waveform input - even with the "best" filter selected for the task, a very small change can lead to very messed up results.

There are probably better flagging algorithms out there too, but I haven't discovered them yet.. I chose the most solid one that came to me, and I've found it's pretty much the best general purpose solution to this problem.

If I had more waveform resolution available, I'd probably have investigated a little more maths heavy approach for some of this (fourier transforms and stuff) but the flagging algorithm is still needed for the other graphs calculations.

The bottom line is, I don't trust my code enough to say it's any better. I'm still quite amazed it works at all considering the crappy resolution of the flow-rate waveform available.

Hope that made sense... it's pretty late and I'm foggy.

/Mark

[Vincent Bentley]

I think this is a reasonable explanation of the limitations of a secondary system that is receiving data that's already been processed.

I reckon this ticket can be closed.