Draeger bin has a variable format

[psomhorst]

It turns out Dräger *.bin data is not always formed the same. According to the manual the medibus data exists of 52 channels of 32 bit data. However, in some files there are more channels (and potentially fewer in others?).

It is therefore unknown how many channels there are beforehand. Also, it is now unclear whether the order is always the same. There are multiple ways to solve this that I can think of:

Method 1: loading until you find a timestamp

Continue loading medibus data until a value is found that could be the next timestamp (i.e. the first data in the next frame). We could try this without actually loading data beforehand, and test e.g. 10 timestamps before concluding this is the proper frame size.

This method does not tell which channels there actually are, and what the order is.

Method 2: divisors

This assumes the file size is always a integer multiple of the frame size. Find the divisors of the file size and select the most probable one to be the actual frame size. The frame size is at least 4150 (without any medibus channels) but likely at least 4358 (with 52 medibus channels).

This method does not tell which channels there actually are, and what the order is.

https://alexwlchan.net/2019/finding-divisors-with-python/

Method 3: combine 1 & 2

First use method 2 to find candidate frame sizes. Then see whether the first four bytes of each frame conform to an expected time axis (i.e.: continuously increasing value with a predictable value gap).

This method does not tell which channels there actually are, and what the order is.

Method 4: require *.asc-file

The ASC file can be exported using the PulmoVista software at the same time as the BIN files. Among other things ASC files contain the medibus data in a CSV-like format, including a header with the column names.

This method tells the names and order of the channels.

[psomhorst]

Thanks to @JulietteFrancovich for finding the issue.

[DaniBodor]

To me it sounds like method 4 is the safest/most accurate, with main drawback being less flexibility for users, is that right?
Do I understand correctly (seeing #194) that this would mean that two separate files are needed, the bin-file for the pixel impedance data, and an asc-file for all other data?

[psomhorst]

To me it sounds like method 4 is the safest/most accurate, with main drawback being less flexibility for users, is that right?

Yes, this reduces flexibility. I think that 4 is the way to go for now, maybe creating the option to use 3, with the caveat that there is uncertainty about what the signals actually mean (because BIN-files don't have labels, ASC-files do).

Do I understand correctly (seeing #194) that this would mean that two separate files are needed, the bin-file for the pixel impedance data, and an asc-file for all other data?

Yes, that is correct. I've started work on a loader for ASC-files. After this is done we could adapt the Draeger loader to also accept an ASC-file (or search for a similarly named file with the ASC extension) so you can load them both and merge them.