tpoint75
commented
6 hours ago The default behavior of the timetrace is to get the counts per second for each bin. The bin with stands for the resolution with it is displayed in the chart. If you want to get the absolut number of counts per bin, you have to set normalized to false in the getData function:
getData(normalized=False)
https://picoquant.github.io/snAPI/snAPI.Main.html#snAPI_Main_TimeTrace_getData
This can be tested in Demo_TimeTrace.py for example. The documentation seems to suggest that setHistorySize defines the total length of time bins used (this is similar to how it is set in the AdvancedT3 labview example). However, changing the setNumBins changes the counts per second values, and summed values (over a measurement of 1s for example) to unrealistic (non-physical values).
Specifically, I have the multiharp 150, with two SPAD detectors (dark counts ~ 100cps), if the ratio of setNumBins and setHistorySize is small (e.g. History = 1, and Numbins no more than 25) then the counts per second make sense. However, if the ratio is set 1 / 100 for example then the counts per second suddenly shoot up to 200 cps per channel. And a ratio of 1/1000 gives average counts per channel of 1000 (which again, does not correspond to the real case). I checked the cps on Multiharp as well, and they are always ~100cps per channel (as expected for the SPAD array). It seems that if you print out the counts from timetrace, the more bins you have, the higher the peak counts become. The counts are also always a N*10, where N is an integer.