Calling all F&P Icon users!

I am not up for a compile but when you are ready for Mac OS X testers just let me know. I used to work support lines for software companies so I am used to documenting errors along with replication path.

Okay, I finally have managed to extract the Icon's Flow Waveform into SleepyHead... It's stored at a reasonable resolution.. (Edit about ??.?Hz..)
Pity they didn't bother recording the exact positioning of events.. (Lame! :-/)

Anyway, there is one last little problem to solve, as shown in the screenshots below.

Note the flow waveform does not follow the centreline.. (and I need it to for doing anything useful with it)

The pressure is constant (CPAP) in this data set, and it does not appear to follow leaks, so I'm not sure what the hecks going on..

All the waveform lengths fit into the session lengths for multiple sessioned days, so I am quite sure timing is correct.

Anyone have any suggestions on what might be going on here?




A single days flow waveforms are stored one constant sized (3.7mb) file, with each session stored in subsequent blocks.
There is a 0x200 byte header like all other binary file types, followed by a single 4 byte timestamp for the whole file, followed by the waveform data.

Each session constists of a repeating pattern of 50 16bit samples, followed by a 5 byte footer, until a end of session marker is met. (The first section may be short)

the footer consists of
a 16bit value that's always either 900 or 400 decimal,
a variable 8 bit number, seems to hover between 0x1b-0x20
followed by 16bit 0xffff end marker.

a sessions end is marked by a 0xff7f after the last 0xffff marker, followed by a zero filled gap to the end of the 0x200 byte page, and then start of the next sessions data (the real timestamps for each session are taken from already loaded session data for the day). If there are no more sessions for the day, the rest of the file is filled with zeros. (also Lame!)

(also Lame!)

Writing interfaces is always so difficult (why am I saying this to YOU?... I guess for others' benefit). ATTENTION: MARK IS DOING A WONDERFUL JOB WITH ALL THESE INTERFACES ! (there, loudly proclaimed). I must praise you for your detective work, patience and surviving the process. Kudos to you sir. I just got done messing with ResMed's S9 AutoSet. It seems they leave out some important information here or there, the EDF file format is a bit odd even with EDF reader source "out there" available, with levels of information (header, signal) which one has to sleuth a bit to sort out just what is going on, particularly with the high density wave forms. Not impossible, just a PITA.

MaxDarkside wrote:

(also Lame!)

Writing interfaces is always so difficult (why am I saying this to YOU?... I guess for others' benefit). ATTENTION: MARK IS DOING A WONDERFUL JOB WITH ALL THESE INTERFACES ! (there, loudly proclaimed). I must praise you for your detective work, patience and surviving the process. Kudos to you sir. I just got done messing with ResMed's S9 AutoSet. It seems they leave out some important information here or there, the EDF file format is a bit odd even with EDF reader source "out there" available, with levels of information (header, signal) which one has to sleuth a bit to sort out just what is going on, particularly with the high density wave forms. Not impossible, just a PITA.

Lol.. I'm just too foggy to do much else but hack some days... most of the time, this is what keeps me sane..

My EDF parsing code in SH not a great example, but I found ResMed stuck pretty well to the EDF+ standard.. (http://edfplus.info/)
Hacking around with the Annotations was the main bit I found ugly. I must admit nothing was all that well described in those docs though.

The ResMed file handling bits are a total nightmare, as ResMed didn't include a sensible way to link common session files together..

The "drift" issue is exposing more and more problems with this.. Headache central!

Why can't manufacturers let the sensible people design the data formats?

jedimark wrote:Hacking around with the Annotations was the main bit I found ugly. I must admit nothing was all that well described in those docs though.
The ResMed file handling bits are a total nightmare, as ResMed didn't include a sensible way to link common session files together..
The "drift" issue is exposing more and more problems with this.. Headache central!
Why can't manufacturers let the sensible people design the data formats?

And remember, these are "medical devices" ... heh... but what they write out is, well, rather a bit off. We didn't have much trouble with the Annotations. We created an "EDFEvent" object, got the stop time and duration (with some head scratching) and then later in our software we convert them into our own Event objects and send them off to our real-time "object" historian and archive them.

BTW, OT, they don't make Bundy Rum in your town, do they (slurp... mmm).

MaxDarkside wrote:BTW, OT, they don't make Bundy Rum in your town, do they (slurp... mmm).

Heck yes..

The fumes of the Rum factory are what keep me going..

jedimark wrote:

MaxDarkside wrote:BTW, OT, they don't make Bundy Rum in your town, do they (slurp... mmm).

Heck yes..
The fumes of the Rum factory are what keep me going..

OMG !!! You are so lucky! I'll be right over (let's see, take Delta to Minneapolis, then to LA, then on to Sydney, then...) We have an office in Sarawak, Malaysia (north shore of Borneo), and the guy who runs that office is from Australia and his son is still living there and brings me a bottle up to Malaysia and when I get over there, I take it home. I'm not sure you can get Bundy rum in the USA. Maybe now it is possible. It's more fun to go to the South China Sea to get it

MaxDarkside wrote:

jedimark wrote:

MaxDarkside wrote:BTW, OT, they don't make Bundy Rum in your town, do they (slurp... mmm).

Heck yes..
The fumes of the Rum factory are what keep me going..

OMG !!! You are so lucky! I'll be right over (let's see, take Delta to Minneapolis, then to LA, then on to Sydney, then...) We have an office in Sarawak, Malaysia (north shore of Borneo), and the guy who runs that office is from Australia and his son is still living there and brings me a bottle up to Malaysia and when I get over there, I take it home. I'm not sure you can get Bundy rum in the USA. Maybe now it is possible. It's more fun to go to the South China Sea to get it

http://www.ministryofrum.com/rumdetails.php?r=33

I think us Aussies drink it faster than they can make it here..

The factories pretty darn big though..

jedimark wrote:I think us Aussies drink it faster than they can make it here..
The factories pretty darn big though..

LOL ! Yes, Bundaberg Black is what I get, the 10 year old delight. I bow in your general direction Next time I come to Australia, maybe we can share a bottle. The last time was in 2008, so I'm about due for a visit

jedimark wrote:Note the flow waveform does not follow the centreline.. (and I need it to for doing anything useful with it)

I'm pretty sure the other machines use a low pass filter function on the waveform data to get the zero line. Or some very similar function like an exponential moving average, which is really easy to calculate.

archangle wrote:

jedimark wrote:Note the flow waveform does not follow the centreline.. (and I need it to for doing anything useful with it)

I'm pretty sure the other machines use a low pass filter function on the waveform data to get the zero line. Or some very similar function like an exponential moving average, which is really easy to calculate.

Thanks arch, I'll give that a try..
I've already tried a basic version of the second one, but I don't think I went far enough back. (was just looking at a 50 sample window)

Okay, I just found the 8bit number in the 5 byte footer following each data block is the adjustment value / 100. (I scaled the flow waveform rather than this value, to make it consistent with other machines)

It follows the leak lines trend, but does not look like the leaks graph (which I know is correct, as it matches the F&P report)

Now the flow waveform looks (Edit: mostly) right, and the RespRate, TV, MV, Ti & Te calcs work.. Still have to check my user flagging algorithm works..


Edit: Still needs some fine tuning.. but almost there..

Damn.. That doesn't work with APAP data.. it's all over the place..

Plus the timing was only correct for that set of data.. It appears there is more segments that sessions in a day per file, and the initial timestamp is different.

back to the drawing board..

jedimark wrote:Thanks arch, I'll give that a try..
I've already tried a basic version of the second one, but I don't think I went far enough back. (was just looking at a 50 sample window)

I might have the terminology wrong. What I'm thinking about as exponential moving average is something like:

F=flow rate
A=weighting coefficient

Initialize EMA=F on first sample
Do for each sample
EMA=EMA*A+F*(1-A)
End

There is no "window" per se, but the value chosen for A varies the speed at which old values fade out of the picture. The closer A is to one, the slower the response.

It beats a moving window because you don't have to remember a bunch of past values and add them up or subtract for each new sample. The new value is based on the previous value, the current value, and a weighting factor.

I took my PRS1, and alternatively plugged and unplugged the end of the hose. The true flow rate should be roughly a square wave, but the result looks a bit like a normal RC circuit exponential decay function.

I think the flow rate reported is probably actual flow rate minus exponential moving average, which gives you a zero center line.

Of course, just because that's how Respironics does it doesn't mean that's the best way to do it.