detailed explanation about configuration files

[Pascal Olivier Gaggero]

Dear all,

The main challenge is to design configuration files that are flexible enough to accommodate the variety of existing EIT system while at the same time being simple enough. The core idea is to define measurement tasks (<meas_task>); inside a measurement task all task are being executed at the same time i.e. in parallel. For EIT systems their are 2 main tasks: stimulation and measurement( <stim>, <meas>). Individual stimulation and measurement tags do refer to a "type". This type refers to which kind of stimulation or measure was made. The detailed description of the stimulation and measurement are being done inside <meas_type> and <stim_type> tags. Stimulation and measurement tag also contain information about which electrodes and gain are used. The value of the attribute "electrode" (e.g. electrodes="[1, 2]") do refer to the electrode index number (i.e. [1, 2]) defined in an other xml file also available in the OEIT file structure in the Header folder (this is going to be discussed in further posts).

Detailed explanation about <meas_type>:

<demod_freq>            is the demodulation frequency

<physical_quantity>   is the measured physical quantity {voltage, current, temperature}

<signal_gain>            is the gain

<signal_offset>          is the signal offset, thus signal measured is given by (offset + gain x signal)

 <I format=”float”/> <Q format=”float”/>, gives the format of the stored binary, possible value are {double, float, int8, int16, int32, int64}

The I and Q tag also mean that those value are the I/Q value given by the demodulator. Other possible tags are {I,Q, amplitude, phase, real, imaginary}

Detailed explanation about <stim_type >:

<stim_freq>           is the frequency of the produced signal

<stim_type>          is the kind of signal {voltage or current}

<stim_wave>         is the shape of the wave {sinus, square}

<stim_amplitude>  is the amplitude of the signal

We are looking forward to your comments,

Pascal, Bartek, Hervé and Andy

P.S. see previous post for a concrete first example.

[Andy Adler]

Overall, I like this format. My question is on the details.

For the line:

<I format=”float”/> <Q format=”float”/>

I'm wondering about the choice of "I" and "Q". WOuld it be better
to use "In-Phase", and "Quadrature". I'm also not sure I like the
terms "real" and "Imaginary". These have a specific meaning to
communications engineers, but mean different things to other people.
--
Andy Adler <ad...@sce.carleton.ca> +1-613-520-2600x8785

> --
> You received this message because you are subscribed to the Google Groups
> "Open EIT Format" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to open-eit-form...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Pere J Riu]

Hi everyone,

I have been a bit off for the last few moths, so I tried to recover all the info sent, but may have missed something. Sorry if raising already agreed topics or things clear to everyone else.

- Units for variables in the config file. The format currently "assumes" units, if I got it well. That is, volts for "voltage", hertz for "frequency", ms for "time" and so on. In my opinion the format should explicitly state the units of the variables.

-time resolution. Since the format timestamps individual measurements rather than frames (I like this), using ms resolution may be a problem (e.g. our system takes 50 frames/s with 8 electrodes, collecting voltages in parallel. Individual measurements are 2.5 ms apart. If using ms resolution the cumulative error in a large sequence can be very big).

- Since binary data is stored, is endianess an issue in modern operating systems? (e.g. Linux is big-endian or little-endian depending on the platform where it runs. LabView is always big-endian, irrespective of the OS or platform,....). Should the config file specify the endianess?. or always use the same irrespective of OS and platform?. e.g Unicode or TIFF files do specify the endianess. JPEG on the contrary is always big-endian, if I am not confused.

  Prof. Pere J Riu

  DEE-UPC

  c./ Jordi Girona, 1-3, Edifici C4, 08034 Barcelona, Spain

  tel.: +34 93 401 6768   FAX: +34 93 401 6756  pere...@upc.edu

[Pascal Olivier Gaggero]

Dear Pere,

You actually made very good points. Let me address your comments point by point.

About the units: 

Between Andy, Bartek and myself we had a discussion about the units, although we did not made the results public yet. Our idea was to assume all physical quantities in arbitrary units, which require to be corrected by a given scaling factor. We could conveniently store those scaling factors (one per physical quantity) inside the <general> tag pair. As a example, if the user decides to store all times in ms, this factor will be 1000. A single scaling factor per configuration file and per physical quantity is permitted.

about the time resolution:

1. We do not require integer numbers, the user can very well use time stamps such as 2.5 ms or 2.455454 ms if required.
2. Alternatively the user could also used smaller time unit such as micro second.

Additionally, the time stamps you are referring to is the one specified in the configuration file. In this case, time "zero" is always at the start of the frame which prevents rounding error for large acquisition sequences. In the proposed design of OEIT a second time stamping mechanism is implemented for the binary frame storage. This 64-bit timestamp is planned to count the number of 10 ns from a given date in time (e.g. 01.01.1900 at 00:00). Thus with a combination of both timestamps, it is possible to accurately calculate the position time of each measurement.

(2^64*10e-9)/(365*24*3600*1e9) = 15000 years. 

about endianess: 

Here I see 2 solutions as you also already pointed it out:

1. We could use a fixed endianess
2. We could add an additional information in the configuration file which indicate the endianess.

Personally, I would prefer the first solution because it is the easiest to implement. Does anyone have good argument to select one or the other?

best regards,

Pascal

2013/3/21 Pere J Riu <pere...@upc.edu>

--
Dr. Pascal Olivier Gaggero

voice: 0041 79 228 43 39

skype: rameur_1

[Pascal Olivier Gaggero]

Dear Andy,

In my mind, I/Q was reserved for the measurement coming out of the demodulator,

real/imaginary would already be hardware phase compensated values.

Clearly, we could also name the tags with full name as you proposed.

Pascal

2013/3/20 Andy Adler <ad...@sce.carleton.ca>

[Andy Adler]

Let me give my comments. I personally hate giving too much flexibility. That makes the file readers too hard to write.

1. I think we should have mandatory units. If the data isn't scaled to the units, then a gain becomes mandatory.

2. It is good that we have fractional time. This will allow fast process systems and slow geophysical systems.

2. Let's not allow both ms and micros. Let's choose one or the other.

3. Let's not have optional endianness. We can choose either, but it should be fixed.

--
Andy Adler <ad...@sce.carleton.ca> +1-613-520-2600x8785