Closed suannchong closed 1 year ago
Just verified that this issue didn't occur on the main
branch (prior to the implementation of FastSophiread
).
To reproduce this:
main
branch./Sophiread -i data/suann_socket_background_serval32.tpx3 -H hits.h5 -v
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
)
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.
Note: With a single-chip system, this error won't occur.
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..
Describe the bug I started seeing jumps in
spidertime
(a jump of 2^30 = ~26.84 ns). This has not been observed before implementation ofFastSophiread
and needs further investigation.To Reproduce Steps to reproduce the behavior:
next
branch../Sophiread -i data/suann_socket_background_serval32.tpx3 -H hits.h5 -E events.h5 -v
hit.h5
file, you will obtain the plot belowExpected behavior The expected result should be a roughly linear plot as shown below: