frame_time = detector frame time

[tgruene]

The data collected 2025-02-21 shows the entry /entry/instrument/detector/frame_time 0.05s
h5dump -d /entry/instrument/detector/frame_time /data/epoc/storage/jem2100plus/UniVie/Bismarck/PHVE39/2025-02-21/009_PHVE39_round_particles_2025-02-21_1226_master.h5 HDF5 "/data/epoc/storage/jem2100plus/UniVie/Bismarck/PHVE39/2025-02-21/009_PHVE39_round_particles_2025-02-21_1226_master.h5" { DATASET "/entry/instrument/detector/frame_time" { DATATYPE H5T_IEEE_F32LE DATASPACE SCALAR DATA { (0): 0.05 } ATTRIBUTE "units" { DATATYPE H5T_STRING { STRSIZE 2; STRPAD H5T_STR_NULLTERM; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } DATASPACE SCALAR DATA { (0): "s" } } } }
And the count_time read 0.048s
In my opinion, fame_time and count_time should be really the detector-specific frame_time, i.e. 1/2000 s for frame_time
The summing is not done by the detector, but afterwards. In my opinion, we should add a data path for post-processing, that includes the number of summed frames stored in the hdf5-file.

[KiyofumiTakaba]

In the latest version (as of 28 Feb 2025), both frame_time and count_time are provided by JFjoch.
As /entry/instrument/detector/number_of_cycles, also provided by JFjoch, is '100' for the recent datasets, this might be the number of summed frames.
We should confirm the definition of this tag. Basically redundant descriptions should be avoided.

[tgruene]

I agree that redundant entries should be avoided. Once it is confirmed that number_of_cycles is active and represents the number of summed frames stored in the hdf5, no more action is needed and this issue can be closed.

[kferjaoui]

Frame_time = Count_time/ Summing_factor

In our case count_time = 0.048s (~20Hz) and for a summing factor (i.e. number_of_cycles in JFJ) of 100, the frame time equals 480us (as displayed in web frontend)

[KiyofumiTakaba]

The tag '/entry/instrument/detector/framerate' (=2000) added by GUI can now be removed. Some other tags are still duplicated, which come from both JFjoch and the GUI. Another issue will open.

[tgruene]

Has anyone actually confirmed that the number_of_cycles is being updated when changed? As long as it has not been confirmed that number_of_cycles is correctly updated, please do not remove any tags from the header!
Personally I would prefer original data over derived data, and the effective frame_time is derived from (summed_frames times actual frequency). NB @khalil: count_time and frame_time are different things. The count_time is the time that the detector actually counted (per (effective) frame), while the frame_time is the period between two adjacent frames, i.e. count_time+dead_time.

[tgruene]

I also just noticed that the data file (e.g. /data/epoc/storage/jem2100plus/UniVie/Bismarck/PHVE39/2025-02-28/1200_powderrings_image_2025-02-28_1954_data_000001.h5) contains an entry /entry/detector/timestamp for each frame. The difference between consecutive numbers is 500050, not 500000. This piles up between frames. @khalil: would you discuss with Filip the meaning of the offset +50 from 500000? It affects the rotation rate by 0.0001% This is little, but it is there.and would mean that instead of 150.000 degree, the data covers 150.015 degree, which is not too far off from the precision of unit cell axes. The entry 'timestamp' lacks a unit, presumably ns.?