-
Notifications
You must be signed in to change notification settings - Fork 4
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
Phase-unwrap-reset should not trigger a record #286
Comments
Edge multi has |
Sure. We have not previously been bothered by this problem just because we can use Edge Multi Triggers. They have been creating some problems still not understood and not even filed as an issue yet. Anyway, as long as classic edge triggers exist, it seems like we ought to be able to make them work with µMUX data. |
I brought up |
One reason to do this change, even if only the traditional/advanced triggers need it, is to help as we try to reduce the CPU burdens associated with EMTs. Anyway, yes, I get that we might grab the n_monotonic concept as the right way to fix this issue. It has the nice advantage that you can use it without knowing whether data is a phase value from a µMUX or a TDM feedback signal (though you do still end up with a free parameter: what n_monotonic should be; maybe it's okay to let this just be 3?). |
Standard / classic / "advanced" triggers based on the very simple edge trigger formula are inevitably fooled when a µMUX channel has to undergo a phase-unwrap-reset.
If a pulse caused a lost phi0 on the rising edge of a pulse, then the new baseline will end up lower than it used to be. After a user-determined time, we reset the baseline to its desired level by the addition/subtraction of an integer number of phi0 steps (i.e., multiple of 4096 under present conditions).
This reset invariably triggers a channel if its edge trigger is turned on. Is there any sensible way to prevent this? Like compute triggers not based on raw values but on the mod-4096 of them? If so, where do we learn the value 4096, and the on/off state of this check?
The text was updated successfully, but these errors were encountered: