ornlneutronimaging / mcpevent2hist

Contains software that is used to process the raw tpx3 data into hit and events.
GNU General Public License v3.0
4 stars 2 forks source link

Unexpected jumps in SPIDERTIME #47

Closed suannchong closed 1 year ago

suannchong commented 1 year ago

Describe the bug I started seeing jumps in spidertime (a jump of 2^30 = ~26.84 ns). This has not been observed before implementation of FastSophiread and needs further investigation.

To Reproduce Steps to reproduce the behavior:

  1. build the next branch.
  2. Run ./Sophiread -i data/suann_socket_background_serval32.tpx3 -H hits.h5 -E events.h5 -v
  3. Plot the spidertime after parsing the hit.h5 file, you will obtain the plot below Figure 8 (1)

Expected behavior The expected result should be a roughly linear plot as shown below: spidertime_before_fastsophiread

suannchong commented 1 year ago

Just verified that this issue didn't occur on the main branch (prior to the implementation of FastSophiread).

To reproduce this:

  1. build the main branch
  2. Run on the same dataset to generate h5 files ./Sophiread -i data/suann_socket_background_serval32.tpx3 -H hits.h5 -v
  3. Plot the spidertime from the h5 file and you would get a plot like this: Figure 9
suannchong commented 1 year ago

I have a suspicion that the error comes from FastSophiread passing the gdc by reference for every single pixel data packet, which cause the logic of retrieve spidertime on the global clock to fail (see code snippet).

Currently, the gdc is set to send at an interval of 1s. With our system that consists of 4 Timepix3 chips, each chip sends a gdc packet (with slightly different values). We can see from the plot below that the jumps occur every 1s (which is the GDCTimestampInterval=1.0)

Figure 20 (1)

The reason behind the jump occurring at GDCTimestampInterval has to do with how the gdc is passed by reference from packet to packet regardless of chipID. Basically hits that are parsed between gdc packets will be affected. Additionally, there are also micro-disorderedness in the pixel/tdc/gdc data packets. So there might be oscillations observed within a jump.

Screenshot 2023-09-27 at 11 56 47 AM

Note: With a single-chip system, this error won't occur.

suannchong commented 1 year ago

One of the ways to resolve this could be adding an extra check that the difference between spidertime and gdc should not be larger than GDCTimestampInterval. Need to revisit this..