timestamp for recorded patches (this automatically includes frames)

[Neumann-A]

due to the discussions of #72 we also may need timestamps between patches/frames if the hardware has to use different delays between the acquistion of a new patch/frame.

Maybe a flag must be introduced to describe wether those timestamps are necessary for the given data.

The timestamp of a new frame would always be the timestamp of the first patch within that frame.

Those timestamp can be then used to calculate a timestamp for a reconstructed image.

[hofmannmartin]

Maybe a flag must be introduced to describe wether those timestamps are necessary for the given data.

I think we wont need a flag. We would make the field optional and assume that the data is obtained contiguous if the field is not present.

The timestamp of a new frame would always be the timestamp of the first patch within that frame.

Would one use use a global time stamp such as the one describing the creation of the MDF file, or would one derive a time differences from the receiver clock to be easily capture the phase relations between measurements at different patch positions?

[Neumann-A]

Would one use use a global time stamp such as the one describing the creation of the MDF file, or would one derive a time differences from the receiver clock to be easily capture the phase relations between measurements at different patch positions?

I would vote for time difference between patches/frames. Seems to be the one with the most precision. Calculating the absolute timing from that would be max of the order O(N*J). Reason why I prefer dt instead of absolute timings -> Rounding errors if t gets large and may want to choose another frame as t = 0

[hofmannmartin]

I would vote for time difference between patches/frames. Seems to be the one with the most precision. Calculating the absolute timing from that would be max of the order O(N*J). Reason why I prefer dt instead of absolute timings -> Rounding errors if t gets large and may want to choose another frame as t = 0

I would modify your proposal.

Time differences derived from the sampling rate of the receiver as this provides exact knowledge about the phases, which are not prone to rounding errors.

[tknopp]

Ok, lets do this. Lets first discuss the semantics and after that bikeshed the name.

Proposal: we introduce a new (optional) field /acquisition/pauseSamples that is of dimension J and type In64. It describes the number of samples that are measured after each drive-field cycle but which are dropped after acquisition and therefore neglected in the stored data stream. Usually pauseSamples will be a multiple of the numberOfSamplingPoints

[hofmannmartin]

What if we put it into /acquisition/receiver/pauseSamplingPeriods? To indicate that it is derived from the sampling rate of the receive channel.

[tknopp]

don't care about naming. your proposal sounds good. @NeumannIMT Since you opened this issue: Are you fine with the solution? Given your approval we can update the specification.

[Neumann-A]

Proposal: we introduce a new (optional) field /acquisition/pauseSamples that is of dimension J and type Int64. It describes the number of samples that are measured after each drive-field cycle but which are dropped after acquisition and therefore neglected in the stored data stream. Usually pauseSamples will be a multiple of the numberOfSamplingPoints

although I like the precision of the proposal I think not all implementation of scanners can fullfill it because it is assuming that the acquisition is not stopped and that the scanner can actually keep track of how many samples have been dropped (which must be implemented in the scanners acquisition logic). Usally scanners dont work in that way and the acqusition logic just waits until a trigger condition for acq. is recieved. We as a user might be able to listen in on how many triggers have been dropped and thus derive some value for pauseSamples but i dont think this is always the case. In addition to that pauseSamples actually needs knowledge of the sampling rate of the recievers (which my not be the same for all recievers).
So having a fallback to a less precise timestamp seems favorable.
(Question: Do we need sample accurate timing for patch timestamps?)

maybe
/acquisition/pauseAfterPatch and allow it either to be in sampling cycles (UInt64) or in seconds (Float64)

[tknopp]

We should check if we can convert between seconds and samples in a lossless fashion. But I think we are basically fine here. Its 52 bit mantisse vs 64 bit. So I think we can just use seconds.

(Question: Do we need sample accurate timing for patch timestamps?)

Depends. There is a scenario, where one just uses a fraction of a DF period for movement. Then one would need that (+shifting the DF phase accordingly)

[hofmannmartin]

We could solve the precision issue by using a pauseAfterPatchUnit field. Either the unit is seconds, or the unit is something like "number of sampling cycles".

[tknopp]

Yes, but we do this only if it is really necessary. After thinking more about it my precision argument is not really valid. A Float64 can handle our use cases just fine. You only get rounding errors in a scenario where you have a very long pause time. So the only thing that we are optimizing using an Int64 is how to get 12 bits longer pause times without losing precision.