Skip to content
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

Open
joefowler opened this issue Sep 23, 2022 · 4 comments
Open

Phase-unwrap-reset should not trigger a record #286

joefowler opened this issue Sep 23, 2022 · 4 comments

Comments

@joefowler
Copy link
Member

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?

@ggggggggg
Copy link
Collaborator

Edge multi has nmonotonic which requires consecutive monotonic samples to trigger. It can avoid this. In principle we know when the resets happen, so we could also pass that info along to not trigger there.

@joefowler
Copy link
Member Author

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.

@ggggggggg
Copy link
Collaborator

I brought up nmonotonic as a solution we could re-use. Eventually it would be nice to have only one version of edge triggers, but until there are no problems with EMT is seems premature to merge.

@joefowler
Copy link
Member Author

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?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants