umux: phase unwrap should only apply during triggering

[ggggggggg]

In MATTER phase correction could lead to baseline shifts, which are undesirable. In DASTARD currently we have a matter like algorithm with the additional feature of not letting a phase offset persist for a long time. The correct phase offset in a flat pretrigger mean is always zero, so there is no value in keeping track of a phase offset over time. The only time we should consider phase correction is on the rising edge of a pulse, this will both be more computationally efficient and simplify the code.

[joefowler]

To make this issue a little less confusing, let me point out that "phase correction" here does not refer to the analysis step of correcting for sub-sample arrival time.

It means the addition of integer multiples of 2π in a µMUX system to account for full cycles of 2π that were presumed to be lost due to large slew rates.

Are you suggesting that this algorithm that adds multiples of 2π be run only after the trigger point, and only after trigger criteria have been met? I agree that this would be more efficient, though I am not sure how it would simplify the code. Are you sure that tracking the amount of added phase across long times is truly unnecessary? Let's make sure to discuss with our local expert, @danbek before we conclude this!

[joefowler]

Hey. Just discussed this over cookies with Mazsi and Ben. While your idea seems like a reasonable proposal, Mazsi was keen to do the unwrapping in firmware. Obviously that would be ideal.

If firmware-unwrapping can happen soon, then we don't want to invest any effort in making software unwrapping more efficient, because that would be a dead end.

(On the other hand, no one seemed to think that your idea of unwrapping only after triggering was obviously unworkable. One challenge might be that it makes the trigger computation a lot more branch-y, if we stick to the traditional filters that compare 4 or more samples.)

[DarkTyr]

Keep in mind, this decision is to be made by the full firmware team including the manager. Probably should have a fully working firmware first and I also see no reason why dastard can not do this, the ndfb_server certainly had no issues why take a step back?

John

On Thu, Jan 16, 2020, 5:09 PM Joe Fowler notifications@github.com wrote:

Hey. Just discussed this over cookies with Mazsi and Ben. While your idea seems like a reasonable proposal, Mazsi was keen to do the unwrapping in firmware. Obviously that would be ideal.

If firmware-unwrapping can happen soon, then we don't want to invest any effort in making software unwrapping more efficient, because that would be a dead end.

(On the other hand, no one seemed to think that your idea of unwrapping only after triggering was obviously unworkable. One challenge might be that it makes the trigger computation a lot more branch-y, if we stick to the traditional filters that compare 4 or more samples.)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/usnistgov/dastard/issues/177?email_source=notifications&email_token=ACBE77QDOHH25R4MDN6GGQTQ6DZJVA5CNFSM4KHXASD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJF75HY#issuecomment-575405727, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBE77SJS2EJSGTO6HLLYATQ6DZJVANCNFSM4KHXASDQ .

[joefowler]

Don't worry! We already have a working version of phase unwrapping in Dastard. The issue is only that phase unwrapping demands a measurable proportion of Dastard's total CPU load (though with smarter code, we did improve this from a massive load to a modest load back in early or mid-2019). We are worried that this could eventually be an obstacle to running larger arrays with higher sampling rates. (Why isn't this a concern with the NDFB server? I think it will be, if compared at equal array sizes and sample rates.)

One way to avoid this obstacle is to trigger on still-wrapped data (somehow), then unwrap only the triggered records (as Galen proposes here). But in the limit of high photon rates, and potentially with variable-length records, you'd still be unwrapping much of the data, as triggered records comprise an ever-higher fraction of all data.

A different way to avoid it is to unwrap phase in the firmware. Just hoping the electronics team will keep this possibility in mind. Of course we'll make Abaco+Dastard work without waiting for this feature.

[ggggggggg]

This is also looking forward to implementing Kelsey's ideas about how to unwrap in the presence of a high slew rate, and my understanding of the algorithm is that it depends on knowing there was a trigger event. So unwrapping after trigger may be either helpful or required to handle higher slew rates.

[joefowler]

I just discussed this with Kelsey. I think you're right. As I understand it now, you could consider her idea as a supplement, done after triggering has already been performed. So in the long term, we might have phase unwrapping done in multiple places. The basic, biased unwrapping could be done either in firmware or in Dastard. Kelsey's rising-edge correction could then be an improvement on that, done in software only after triggers are found.

[ggggggggg]

We also talked about in firmware measuring the slew rate at the "mix" step. Then we could test simple algorithm like "if slew rate ? threshold add twopi".