Handling multiple recievers with different settings (bandwidth/sampling/gain)

[Neumann-A]

The current format implicitly assumes that all recievers have the same bandwidth/sampling and gain setting. In my opinion there is a high possibility to use different recievers with different settings.

Thus the following should be changed: /acquisition/receiver/bandwidth From Dim= 1 to Dim = C

/acquisition/receiver/numSamplingPoints From Dim = 1 to Dim = C (Wouldn't it be more natural to store the Sampling rate in Samples/sec instead of some value dependent on other Settings?)

/acquisition/receiver/unit From Dim = 1 to Dim = C

(/measurement/data could also be changed accommodating the changes to the receiver but I do not know if HDF5 supports “not rectangular” dimensioning)

[tknopp]

We have discussed this. Due to the requirement of synchrone Receivers, it would not make sense chosing different bandwidth. Data handling would be pretty Complicated.

Are you aware of a System with Differenz bandwidth?

Gain should be covered by the conversionFactor being channel aware.

[Neumann-A]

I think there is no system yet with different receiver bandwidths but for some systems it could make sense if it increases the SNR of some channels. Possible example: Your System with self build high sensitivity gradiometer -> one high sensitive coil (x), two lower sensitive coils (y,z). Instead of sampling all channels with the same sample rate/bandwidth it would make sense to use the full sampling rate for the x-channel and artificial lower the sampling rate/bandwidth for the y,z-channels using a block average or something similar to increase SNR. (sampling rate division by 2 should always be possible without any extra care). Further benefit: reduced storage/memory requirements

Due to the requirement of synchron receiver

That is not a hard requirement. It makes it a lot easier on the data processing side but what the receivers really need is a predictable phase/time difference which is repeatable between measurements, system matrix acq. and calibration. (It could be that you understand that as synchron but for me synchron means sampling at the same timepoints the whole time)

Gain should be covered by the conversionFactor being channel aware.

Then the problem is that it is optional. Maybe mdf needs some fields to be optional if some predicate is fullfilled. (In this case if measurement/data is saved as a physical unit and not just integers.)

[tknopp]

Mathematically synchron receivers are not necessary. But from a data processing point of view it makes things quite complex. There is a trade off between complexity and generically. In theory the sampling points could also be non-equidistant. But why should we support that?

We had long discussions about /measurements/data What's your idea to support different sampling bandwidth for this field?

[Neumann-A]

But from a data processing point of view it makes things quite complex

Please explain. I do not see the added data processing complexity.

In theory the sampling points could also be non-equidistant.

I would not go so far but after thinking a bit about it I think it is already indirectly supported if we stay in the time domain. (But seems to be a different topic)

We had long discussions about /measurements/data What's your idea to support different sampling bandwidth for this field?

Ignoring N x J because they are obviously correct, only C x K [ or C x W] needs a change. If compound datatype is out of question (because it would be a heterogenous container with same datatype and different matrix dimensions) I would suggest a single dimensional vector with size: Sum(1 to C)(K_C) [or Sum(1 to C)(W_C)]. If I am not wrong this should als be a good format for reconstruction using all channels?

If the topic has already been discussed could you please link the old topic so that i can read up on it?

[tknopp]

We discussed this via email and phone with several people. Anselm and Mandy in particular where involved to contribute the IMT perspective. It is (positively) surprising that you are also interested in the MDF. Timing is a little bad since we want to make a release of v2 soon.

Back to topic: I may could live with the proposal. Will think about it once I am back from vacation

[hofmannmartin]

If I recall correctly Tobias and me had the same discussion about the sum.

For the sake of simplicity I would like to address this issue with the next major update of the MDF.

[Neumann-A]

Timing is a little bad since we want to make a release of v2 soon.

Was on parental leave when the e-mail with contributions to v2 came. Did not have time to participate then.

Only a small note: Thomas suggested using different data datasets for different recievers which would also be a possibility

[hofmannmartin]

Was on parental leave when the e-mail with contributions to v2 came.

Congratulations.

Only a small note: Thomas suggested using different data datasets for different recievers which would also be a possibility

As I have written, I too raised this issue at HH in a discussion with Tobias. We agreed that it would be best to wait for someone building such a device before we make the changes to the MDF. The changes will require to rework all the code paths of our, where we have receive channel times frequencies at the moment. There would be no easy splitting into separate dimensions anymore.

But in principle once v2.0.0 is released we can start implementing the required changes to the MDF on a new branch if you like. It would be great help if you could make a proposal.

[hofmannmartin]

Only a small note: Thomas suggested using different data datasets for different recievers which would also be a possibility

That would be a possible work around which would require no changes to MDF.

[tknopp]

Lets draw a decision on this: @NeumannIMT @MandyA @profix898 @AvGladiss @hofmannmartin (and any other)

Are you for allowing receivers with different sampling rates or are you against it? Please comment and/or let the thumbs speak.

[tknopp]

This is the voting comment:

[pkvogel]

Hi all,

it is a good idea to think about different sampling rates for the future...but I think it is not necessary for this version...no one will use it at the moment because of the mentioned complexity

[tknopp]

Thanks Patrick. Do you agree with me that from the DAQ side, it would never ever be thinkable to use different receivers? They all need to have the same clock to be synchronous (fed by the same quarz).

[Neumann-A]

it is a good idea to think about different sampling rates for the future.

@tknopp: For me this seems more like the issue needs a solution instead of a majority vote if you dont want any breaking changes in the future.

[tknopp]

We can very simply solve this issue without breaking the MDF. If we want this at some point: We just will increase the dimensionality of numSamplingPoint etc and the /measurement/data field will drop the channel dimension. The user can then easily check if it is an MDF with varying sampling rates or not. Are you fine with that?

[AvGladiss]

Thanks Patrick. Do you agree with me that from the DAQ side, it would never ever be thinkable to use different receivers? They all need to have the same clock to be synchronous (fed by the same quarz).

Although I am not Patrick I would like to comment on this if I may 😃 At the IMT, we are using different receivers (for feedback and receive), so it is definitely thinkable and yet the case. These different receivers have different sampling rates but are fed by the same clock and the same trigger, which is synchronized to the clock. Right now, this is not an issue as the feedback data is not stored in the same dataset as the receive data.

Now imagine that the IMT would build a scanner with N receive channels, but our main receive IO-card (A) only has N-1 ADC channels. Then we would maybe use another (additional) IO-card (B) with a lower sampling rate to cope for the missing channel. We would feed both IO-cards (A and B) by the same clock, but the sampling rates would differ.

In my opinion, we should force the IO-card A to the lower sampling rate of B or reduce the high-sampled data of A by averaging/interpolating. Therefore, I would not support different sampling rates in MDF right now.

[tknopp]

yes it is possible to do this. But you will try to avoid it. And if you need it go with https://github.com/MagneticParticleImaging/MDF/issues/69#issuecomment-324891771

[Neumann-A]

If we want this at some point: We just will increase the dimensionality of numSamplingPoint etc and the /measurement/data field will drop the channel dimension. The user can then easily check if it is an MDF with varying sampling rates or not. Are you fine with that?

Could live with it for know although having a general applicable solution for all cases would be nicer. As others have pointed it is not so important yet. Maybe dont close the problem but give it a special tag to show that we are aware of the problem (This issue is already a duplicate of #37, #40. ) and currently does not have a good general solution.

In my opinion, we should force the IO-card A to the lower sampling rate of B or reduce the high-sampled data of A by averaging/interpolating

Please dont do that. It lowers the useability of MDF if the user has to do it to be able to store the data in MDF format.

[MandyA]

We can very simply solve this issue without breaking the MDF. If we want this at some point: We just will increase the dimensionality of numSamplingPoint etc and the /measurement/data field will drop the channel dimension. The user can then easily check if it is an MDF with varying sampling rates or not. Are you fine with that?

I agree with @tknopp. If at some point it is really necessary to have varying sampling rates, we can simply introduce them. Currently, it just makes MDF more complex/complicated without a benefit for anyone.