Estimation of the digitizer range

[MCFlowMace]

Maybe if that is a possibility we should estimate a digitizer range based on other parameters like @psurukuc suggested in the slack channel. But to me it is not clear yet if that is universally possible. Maybe there is a trap dependent solution that we can apply?

[charstnut]

On this issue, I am not sure if the digitization error would affect our measurements (i.e. will the signal be too low to fill the minimal digitization step?) If not, then the simulation could use an automated rule for determining digitization. But in the experiment we will have to stick with one digitization setting right? It seems to me that using different ranges for simulation is not particularly useful, but defaulting it to some optimal setting which can be used in the experiment is a good point to implement.

[pslocum]

At the moment Locust is digitizing with only 8 bits, which I believe is lower than planned for the FSCD. If we want to keep the range settings constant, then we would probably need to increase the number of bits in the output.

…

On Thu, Apr 29, 2021 at 7:02 PM Mingyu (Charles) Li < ***@***.***> wrote: On this issue, I am not sure if the digitization error would affect our measurements (i.e. will the signal be too low to fill the minimal digitization step?) If not, then the simulation could use an automated rule for determining digitization. But in the experiment we will have to stick with one digitization setting right? It seems to me that using different ranges for simulation is not particularly useful, but defaulting it to some optimal setting which can be used in the experiment is a good point to implement. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVBROPHYCJS7VQIOBAIXN3TLHQRRANCNFSM43VRIRNA> .