Tidal volume and Flowrate out of sync? [Airsense 11]

[dataq1]

Please pardon me if this question has been asked before (and if so just point me to the answer!)
My values in my tidal volume graphs don't seem to line up (timewise) with  expectations based on Flowrate graphs.

(see the attached)

Where I would expect a tidal volume minimum (based on a period of clear airway no flow, marked "c") I read 524 ml, but where I see a "big gulp"-maximum inspiration (marked "a")  I read  400 ml. And then a medium inspiration (marked "b") i reads  759 ml (maximum of the group)

On the other hand, perhaps the tidal volume values are averaged, so the values are always lagging. Or the Resmed calculation is indexed to an incorrect time. 

Any insight?
   

Equipment: Resmed Airsense 11 AutoSet mode, E30 mask

[dataq1]

bump - and is my question unclear?

[Crimson Nape]

I'm not aware of any Resmed documentation that states the parameter synchronization accuracy, or tolerance bandwidth.   I can tell you that not all parameters start reporting at a same time after startup.   Some parameters can take up to one minute before they start reporting.  This startup reporting time delay is variable also.   I would suggest that you zoom in on the very beginning of a session graph in the Daily Screen and look at when various parameters start reporting for that session.

This is the best answer I can provide.

[dataq1]

Examine Start time - Good Idea!
In the following example it appears that the first inspiration time plotted is two seconds after the first recording of a flowrate.
The first rational Tidal Volume and Respiration Rate appear 14 seconds after the first recording of a flowrate
Flowrate start 22:27:12
Inspiration Rate start 22:27:14
Tidal Volume Rate start 22:27:26
Respiration Rate start 22:27:26

(because the graph trace on the Tidal Volume and Respiration Rate is a straight line from the origin to what I've called a rational or sensible value,  I'm inclined to believe that the values are actual (rather than averaged), but potentially lagging by 14 seconds.) 

For the record this was on a Resmed Airsense 11 in Autoset mode in "smart-start".

   

[Grandpapa-G]

The derived quantities such as Tidal volume and Minute Vent. are very likely determined from some form of weighted rolling averages of the measured quantities. The averaging is necessary to reduce noise but will introduce the observed time lag since only backward averaging is employed. The time constant used in the weighting scheme is probably fixed but could vary with the inverse of the respiration rate. This would be in line with commonly used method of presenting data for analysis.

[dataq1]

The derived quantities such as Tidal volume and Minute Vent. are very likely determined from some form of weighted rolling averages of the measured quantities. 

Yes, it would seem like the values are averaged. My followup question would be, is the averaging/derivation being done by the OSCAR software or by the machine firmware?

(if being done by OSCAR, the developers should be able to give a direct answer as to the method of averaging. OTOH, if the machine's firmware is doing the averaging the manufacturer may hold that as a "secret".

In this same line, I've been looking at inspiration and expiration times (not specifically to sync issues) , but rather who calculated these values. From the EDF files inspiration and expiration times are not values that are recorded to the SD card. Prior that discovery, I've assumed that the OSCAR software just presented a graphic of signals and did not create any new signals, nor modify those recorded signals (the exception being scaling).

Is this your understanding as well?

[pholynyk]

A quick check shows that the ResMed AutoSet, VAuto, and ASV all report RespRate, TidalVol, and MinuteVent in the PLD.edf files. I dont have the Respironics files for comparison.

>>> "if being done by OSCAR, the developers should be able to give a direct answer as to the method of averaging"

... this is assuming some OSCAR developer has looked at that particular chunk of code...

[GuyScharf]

As pholynyk says, the answer depends on the machine in question. ResMed machines record respiration rate, tidal volume, and minute vent. SleepStyle CPAP does not record those so OSCAR calculates those numbers from the flow graph. DeVilbiss is in between with resp rate and tidal volume being reported and minute vent calculated as the product of resp rate and tidal volume. I haven't look at the PRS importer to know how it handles those values.

[dataq1]

Just to simplify, lets stay with Resmed.
Is there something that I'm not quite understanding?
I've assumed that the signals (for daily time graphs) come from the SD card. The flowrate data is obtained from the BRP_data.edf  for each session/day. That data is acquired from the device's sensors at 25 Hz (one reading every 40 msec).  Converted to CVS format the beginning of that file would look like this:
   

Other signals, like Mask Pressure, Pressure, EPR Press, Resp Rate are contained in the PLD files on the SD card. That data is recorded every 0.5 Hz (one datapoint each 2 seconds). So a small session, lasting only 9 minutes would have generated only 4 rows of data.

But when I plot the OSCAR data for those 9 minutes I get many more inflection points (suggesting "new" data), but Resmed has only provided 4 data points.

Why, to my eye, does OCSAR have so much more data for that short session than Resmed has recorded on the SD card?

Example:
   

[2SleepBetta]

deleted

I hope this inadvertent post will have been deleted after this attempt to do so.