Bad DPPH Fit

[ldeviveiros]

The DPPH field value varies wildly for Z>110mm. I suspect it's the fitting function. Looking at the oscilloscope, we see the crossing frequency decreasing smoothly as we increase Z, so it's not random fluctuations. We need to improve the fit.

See Elog entry: https://maxwell.npl.washington.edu/elog/project8/Project+8/549

[laroque]

Can you provide more information about what "fluctuating wildly" means. The ddph_scan script supports (or is supposed to support) dumping the raw data. Could you post either a plot of the amplitude values being used, a plot of them, or a screenshot of the scope for a case which isn't working?

Some notes on what is done vs what should be:

• We currently use the lock-in amplifier's amplitude output and an optimal filter based on a gaussian lineshape (and therefore use the derivative of a gaussian as the target for the filter, since the lock-in outputs derivatives).
• We're using a filter based on a target line shape and not simply looking for the zero-crossings as is done when looking by hand on the scope. This is much better for several reasons including 1) not being sensitive to any DC offset the lock-in has been observed to have 2) it makes maximal use of the data available from the scan rather than relying on only those points bracketing the crossing
• The correct line shape would be Lorentzian, using that as the filter target should give more accurate results, but I wouldn't expect it to have any impact on the stability of the output.
• The correct configuration, I believe, should have the phases such that the lock-in output signal is all in one channel (which it calls X,Y and to be understood as components of a complex number). In the past there appeared to be significant signals in both channels and the relative contributions were not always the same. As a result, I've used the amplitude to avoid missing a signal by looking into the wrong channel. If someone were to figure out why the signal's complex phase sometimes changes, and from that how to ensure it doesn't happen, we could address this. However, I do not expect that this would cause instability in results either.
• Because communication with the old sweeper was not possible, and communication with the new one was not initially available (it is quite easy to add things now, except that the programming reference is very long and one has to go through it to find the feature you want), options related to it are not very flexible. The value of the width used in the filter's target function should be computed based on an expected line width for the dpph and can only be included by accounting for the sweeper's sweep rate and the lock-in amplifier's sampling rate Without having seen anything more, I would bet that this is the most likely source of trouble. By having dpph_scan output data, we can plot the lock-in response vs frequency, as well as the filter's response and target line shape. That gives a huge amount of information about what is going on and what may be causing problems.

[laroque]

After further feedback from Megan and Luiz, I'm more confident that there are two problems:

1. The Weiner filter needs to be given a signed input. The magnitude values are better than x or y alone, but is positive definite. Normal rules for complex numbers should allow one to compute a sign from the product of the signs of X and Y. (This is the sign of the derivative of the absorption lineshape)
2. Originally the sweep speed and range, the lock-in ADC rate, etc. were all fixed, and so the target function to the Weiner filter was hard coded based upon all of those values. We've since changed all of those values and so this hard coded value is not well motivated. The correct thing to do would be to query the sweeper for not only the frequency sweep range, but also the number of points and dwell time. This gives a Hz/s for the input. Next select a lock-in ADC sampling rate that should resolve the line shape (based on its expected width), and a number of points for the lock-in sampling to over-cover a sweep (I like 110% of the sweep time). This should allow one to compute the (Hz swept)/sample in the lock-in data output. The "width" in samples used to construct the Weiner filter's target function can then be computed.

[ldeviveiros]

Although that has already been discussed elsewhere, I added a plot of the DPPH Field vs Insert Z-position to the elog entry, to illustrate what I mean by "varying wildly". The problem is that when we use the magnitude of the lockin signal (as already addressed above), the filtered curve will have extra minima, and the dpph_scan code can pick a different minimum to calculate the field. So the field just jumps up and down arbitrarily for different measurements.

[laroque]

Above comments are wrong, X and Y don't mean quite what I thought that they did. The Lock-in supports tuning the phase such that most signals are purely in X and Y is zero. If we're able, we should add this to the lock-in tuning procedure and then filter on X. If not, perhaps we can systematically get a sign from the phase output channel. If not we can go back to just using the X data and deal with the fact that the signal is less clean because part of it is in Y.

[ghost]

I suggest you take the signal as X+iY. Then take the magnitude of the filter output.

On Fri, Jul 24, 2015 at 8:05 AM, Ben LaRoque notifications@github.com wrote:

Above comments are wrong, X and Y don't mean quite what I thought that they did. The Lock-in supports tuning the phase such that most signals are purely in X and Y is zero. If we're able, we should add this to the lock-in tuning procedure and then filter on X. If not, perhaps we can systematically get a sign from the phase output channel. If not we can go back to just using the X data and deal with the fact that the signal is less clean because part of it is in Y.

— Reply to this email directly or view it on GitHub https://github.com/project8/dripline/issues/96#issuecomment-124552481.

[laroque]

@mwachtendonk @ldeviveiros Is this issue still active or does the complex valued filter input give reasonable/stable results? Or maybe it is expected to work but hasn't been tested enough because there were troubles getting everything cabled and configured correctly?

[mwachtendonk]

So far we've run two scans with the new filter; one on Friday of last week and one on Monday. Luiz had me compare the average field values between the two days. Monday's average was 9.58205 and Friday's average was 9.58775, so a difference of 0.0057kG. I don't know if this difference would be due to the filter or something else, but if we decide that the filter isn't doing something weird do the data, then I think it's safe to say that this issue is no longer active.

[laroque]

I'm less interested in the difference between days as if you do many measurements at the same z one after the other. Also, just plotting everything does it look reasonable.

On Thu, Aug 6, 2015, 9:55 AM mwachtendonk notifications@github.com wrote:

So far we've run two scans with the new filter; one on Friday of last week and one on Monday. Luiz had me compare the average field values between the two days. Monday's average was 9.58205 and Friday's average was 9.58775, so a difference of 0.0057kG. I don't know if this difference would be due to the filter or something else, but if we decide that the filter isn't doing something weird do the data, then I think it's safe to say that this issue is no longer active.

— Reply to this email directly or view it on GitHub https://github.com/project8/dripline/issues/96#issuecomment-128440873.

[laroque]

Closing this issue as mostly resolved (the bugs anyway). Opened issue #108 to cover the upgrades to the script that it would still be nice to implement.