Readers insert data asynchronously into the database, so at a given time the most recent data in the database is incomplete -- not all digitizers have contributed to it. The trigger queries data until a fixed time (one minute) away from the last pulse for this reason.
Such a fixed margin is not robust. If the database is too slow, or a pulse is accidentally inserted into the far future (some issues we had in the past), the trigger still queries a region of data it shouldn't, and the result is stretches of time where not all digitizers contribute.
Dan already implemented a 'status' database collection where the digitizers keep track of which collections are safe to read. There's also at least a start of code in the trigger to use this. When there is time, we should test if this works well and switch to it.
Readers insert data asynchronously into the database, so at a given time the most recent data in the database is incomplete -- not all digitizers have contributed to it. The trigger queries data until a fixed time (one minute) away from the last pulse for this reason.
Such a fixed margin is not robust. If the database is too slow, or a pulse is accidentally inserted into the far future (some issues we had in the past), the trigger still queries a region of data it shouldn't, and the result is stretches of time where not all digitizers contribute.
Dan already implemented a 'status' database collection where the digitizers keep track of which collections are safe to read. There's also at least a start of code in the trigger to use this. When there is time, we should test if this works well and switch to it.