-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gating needs to do a proper job of handling timestamps associated with each frame #8
Comments
So: I believe the solution is to associated timestamp metadata with our frame data, and use those timestamps throughout the trigger prediction code. I will try and tackle that as part of the refactor. |
So, for prosperity, are you still trying to decide between a np.ndarray subclasses and something like h5py and hdf5 file sinks? |
Yes, I have not given this any more thought since we spoke, and don't feel any option is yet jumping out as self-evidently the best solution. Was going to have a bit of a read back through what we actually do with the frame objects, and think about it some more. |
3 similar comments
Yes, I have not given this any more thought since we spoke, and don't feel any option is yet jumping out as self-evidently the best solution. Was going to have a bit of a read back through what we actually do with the frame objects, and think about it some more. |
Yes, I have not given this any more thought since we spoke, and don't feel any option is yet jumping out as self-evidently the best solution. Was going to have a bit of a read back through what we actually do with the frame objects, and think about it some more. |
Yes, I have not given this any more thought since we spoke, and don't feel any option is yet jumping out as self-evidently the best solution. Was going to have a bit of a read back through what we actually do with the frame objects, and think about it some more. |
The code is not doing a great job of precise timing. It determines a delay time before sending the trigger, but then executes a bunch more code.
Oh and, more importantly, that delay time is then treated relative to “current_time”, which is set after doing the phase-matching. That is going to reduce accuracy and precision, and also makes me even more uncomfortable in terms of future-proofing.
I think it would be much better to pass around absolute times, not deltas.
Chas writes:
There was a reason, three years ago, to use relative times... but it could just have been because that was of interest to me in my offline analyses?
Originally posted by @ChasNelson1990 in https://github.com/_render_node/MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDY4MjcxOTQw/pull_request_reviews/more_threads
Jonny writes: I suspect any emulation concern you might have will be resolved if we pass around proper timestamp metadata with each frame
The text was updated successfully, but these errors were encountered: