PTU files in snAPI

[fbbarnes]

Hi, I was wondering if there are any differences in the way .ptu files are recorded using snAPI vs the included software for HydraHarp and PicoHarp devices?

Previously, I have used the trattoria python package for post-processing of .ptu files created using the measure T2/T3 mode in the HydraHarp software. However, using snAPI to record T2 data and processing using trattoria is returning blank records. I am able to read the files fine using snAPI, so I wondered if this is expected due to the way .ptu files are recorded having changed? Cheers!

[fbbarnes]

Update: I have realised the header information is not fully filled out when a FIFO error occurs during the measurement. This leads to an error in trattoria which looks at the number of records before processing the tags. It would be very helpful if this behaviour, and how FIFO errors are recorded in the .ptu file, was more clearly documented.

[tpoint75]

You are right. Many information will be written after the measurement is finished. That means the ptu header must be updated afterwards. I don't know, how trattoria works. But you can read the ptu files with snAPI. So there is no need for any 3rd party tools that we cant support.

Just look at https://github.com/PicoQuant/snAPI/blob/main/tools/Tool_ReadPTU.py. Here you can see how to get the data out of a ptu file.

[tpoint75]

I don't exactly know, what you mean with 'FIFO error'. But that means you lost data, what would be better not should happen.

[fbbarnes]

Hi, I understand that snAPI has recently made analysing and recording T2 and T3 files easier but for years we have relied on using software developed in-house. In fact, we still need to use these tools for more advanced analysis such as accessing raw number of coincidence events (not normalised g2), third order autocorrelation measurements and post-selected histogramming. As far as I can see, none of these are supported by snAPI so the need for 3rd party tools is certainly still necessary. Simply reading out the individual tags as above is not an efficient way to implement such algorithms. Furthermore, I beleive that Tool_ReadPTU.py example script would also fail in this instance due to the reason you explain that the header is written after the measurement is completed but in the case of an overflow error the measurement is not completed.

[tpoint75]

Hmm, what do you want? Is the number records wrong, if a FIFO error has occurred? Is there something you expect to fix?