How can I read a binary file stream with many data type, as with AcqKnowledge physio binary data file?

[Donat-Pierre]

I would like to read in and write physiological data files which were saved by BioPac�s AcqKnowledge 3.8.1 software, in conjunction with their MP150 acquisition system. To start with, I�d like to write a converter from different physiodata file format into the AcqKnowledge binary file format for version 3.5 � 3.7 (including 3.7.3). It will allow us to read different file format into an analysis package which can only read in file written by AcqKnowledge version 3.5 � 3.7 (including 3.7.3).
I attempted to write a reader following the Application Note AS156 entitled �AcqKnowledge File Format for PC with Windows� (see http://biopac.com/AppNotes/ app156Fi
leFormat/FileFormat.htm ). Note the link for the Mac File format is very instructive too - it is presented in a different style and might make sense to some people with C library like look (http://biopac.com/AppNotes/ app155macffmt/macff.htm).
I guess the problem I had was that I could not manage to read all the different byte data stream with File.vi. This is easy in C but I did not get very far in LabView 7.0. Also, I was a little unsure which LabView data types correspond to int, char , short, long, double, byte, RGB and Rect. And, since it is for PC I am also assuming the data to be written as �little endian� integer, and thus I also used byte swap vi.
Two samples *.acq binary files are attach to this post to the list. Demo.acq is for version 3.7-3.7.2, while SCR_EKGtest1b.acq was recorded and saved with AcqKnowledge 3.8.1, which version number is 41.
I would be grateful if you someone could explain how to handle such binary file stream with LabView and send an example to i
llustrate it.

Many thanks in advance for your help.
Donat-Pierre

[chilly_charly]

Don't know how far you already are.
So this is something to start with.

I believe that we shall have a number of exchanges...

What is your ultimate objective ? Extract Channel data ?

CC

[Donat-Pierre]

Hey,

Thanks for such a quick reply. I could not open your VIs since they were saved as LabView 7.1 VIs and I have 7.0.

At first I'd like to extract channel data. But for now it is the way around, I have channel data and annotation expressed relative to absolute tie I'd like to convert to an *.acq file. Not only I need to analyze skin conductance response measurement but also the AcqKnowledge program has some great tool I'd like to use to format my data before analysis.

I got to the point where I tried to make array of counter position to place myself when there should be a acqknowledge parameter and fed is teh corresponding data byte stream. It gave me numbers which seems right, but in teh smae confusing and past 5 parameters I did not see
m to get any further. Also, the data representation wired to teh data byte stream really affected what was interpreted fro the binary file... more confusing since I don't know what is a short, a long or word in LabView terms.

I'd send you teh vi but at the time I mess around so much out of frustration, it does not lok like anuthing anad totally useless. I mean the file open and read are there but the rest is mess.

I would appreciate if you could save your data to LabView 7.0. There should be an option in LV for that.

I look forward to hearing back from you very soon. If I don't hear from you until Monday, Have a nice week-end.

Donat

[chilly_charly]

Here is the 7.0 version, with a slight correction, since I confused short (= word = U16) and U8 (=single char).
Don't know yet if I'll spend much time on LV this WE (depends on my wife :)) but anyway, keep in touch.

[chilly_charly]

Another thing is that I am involved in a research project on electrical properties of cells, and also I'm working with a company that developped an optical sensor to measure, without contact, the skin layer thickness (a parameter that should play some role in skin conductivity...). Any comment ?
CC

[Donat-Pierre]

Hey charly... Here is where I was at plus using the right data type. I Think it works using the short and long, but gets really weird with double and the rectangle thing. What I find could be right.
Note that the bite swapping of array works when I do it by hand!!! (using U8).
I might be confusing short and long... now I'm going to look at your code.

Donat-Pierre

[Donat-Pierre]

Your vi is really neat and is so much more elegant. It is closer to home too sice it is how I read other file format using windows style ini text file with all the channel specs and a interleave U8 little endian integers binary file.

Regarding your example. DId you manage to read double. I can't seem to be able to. But I am getting closer, a little help I could have something by the end ofteh week-end. Great.

Regarding your question. It seems interesting. An optical sensor to measure skin layer thickness is intriguing. Does it uses sub-scattering data for the skin or some adsoprtion property of the skin.
Skin conductance/electrodermal activity is related to swet glands. Now, the skin thickness might be correlated with
a varying density of sweat glands.

I am not sure. I could ask a colleague in Germany. It is getting late here in LA, California. I'll be happy to continue any discussions.
Donat

[Donat-Pierre]

Charly,

Did you manage to read SampleTime (double) parameter in? It is at positioin 18, size 8. The sampling rate was 250Hz for EKG and 125Hz for the SCR. It should read dt=1/samplintg rate=0.004s (or 0.008s wth 125Hz).

Going to bed, Bonne nuit.
Donat-Pierre

[chilly_charly]

The reading of double is also straight forward : just use a dble float wired to the type cast node, after inverting the string (indian conversion).
See the attached example.

The measure of skin thickness is based on OCT (optical coherent tomography = interferometry) : an optical fiber system send and received light emitted to/back from the skin at a few centimeter distance. A profile of skin structure is then computed from the optical signal.

CC

[chilly_charly]

Good morning DP !
The SampleTime was NOT in position 18 !!! (16)
You really needed to have some rest :)) !

Anyway, I was not completely awake either on my side of the world, since in my last post I forgot to convert the output to Dble.
New version, dble checked, attached...

CC