Length of time trace not the same as acquisition time

[nzijlstra]

So I converted a ptu file to the photon-hdf5 format using phconvert. We have a setup with a hydraharp400, PIE excitation, 2 color detection, and 2 polarizations. When I load this file in fretbursts, the length of the time trace is not the same as the acquisition time. In this case, the acquisition time is 1800s (as is also stated in the header of the ptu file), and the loaded time trace seems to be 1473.95s.

My measurement_specs is now defined as this (no alternation):

measurement_specs = dict(
    measurement_type = 'generic',
    detectors_specs = {
          'polarization_ch1':[2,0],
          'polarization_ch2':[3,1],
        'spectral_ch1':[2,3],
        'spectral_ch2':[0,1],
    },
    laser_repetition_rate=20e6,
    #alex_excitation_period1=[1550,3125],
    #alex_excitation_period2=[50,1500]
    )

In fretbursts I get the following information: d.time_min = 9.150054900329402e-06 d.time_max = 1473.9453087218524 d.clk_p = 5.000030000180001e-08 (not exactly 50ns, but this is what the picoquant header specified)

If I now apply alternation (d.add(A_ON=(50,1500),D_ON=(1550,3125))), I get the exact same: d.time_min = 9.150054900329402e-06 d.time_max = 1473.9453087218524 d.clk_p = 5.000030000180001e-08

However, d.nanotimes_td gives the error "AttributeError: 'Data' object has no attribute 'nanotimes_td'", and when trying to plot the alternation histogram (bpl.plot_alternation_hist(d)), it gives the error that the data has no positive values.

[nzijlstra]

Sorry, the nanotimes_t had a typo, this gives an array of nantimes, so that works fine.

[tritemio]

Wierd, seems like photons stopped to arrive at 1473 seconds. Can you check that the number of photon in the PTU file is the same as the in the Photon-HDF5 and the same that you get in FRETBursts?

[nzijlstra]

The number of photons is exactly the same in all cases, so it seems all the data is there.

Detector    Counts
--------   --------
       0    3942710
       1    2670070
       2    2066433
       3    1518518
     127    5558495

where detector 127 is the sync signal I assumed.

When I now load the ptu file using pqreader.load_ptu, and I extract the separate channels and length of the trace etc myself, it also has the correct number of photons, but the length of the trace here is also 1473s. I guess this would mean that something with the loading goes wrong or I am using the wrong numbers somewhere.

The first part of the header of my ptu file looks like this:

(array([        183,        1025,        1945, ..., 29478724157,
        29478728709, 29478729301]),
 array([  1, 127,   0, ...,   3, 127,   0], dtype=uint8),
 array([1780,    0, 2077, ..., 1728,    0, 1697], dtype=uint16),
 {'timestamps_unit': 5.000030000180001e-08,
  'nanotimes_unit': 1.5999999936067155e-11,
  'acquisition_duration': 1800.0,

from which I used the same timestamps_unit and nanotimes_unit. The first array is the timestamps, which I just multiply by the timestamp_unit to get the total time trace. The nanotimes information looks fine to me, 50ns total length (3125 bins * 16ps, as I expect)

[nzijlstra]

Okay, I looked at a few more recordings, and they are all good. I guess I just picked one where something weird was going on in the file, sorry about that!

[tritemio]

Yep, it looked like an hardware fault. Thanks for reporting back. Let us know if you encounter other issues.