Spurious step at end of bias_steps throws off analysis results

[dpdutcher]

Many of my bias step timestreams have a large signal at the end that is falsely interpreted as a bias step. This throws off both the fit time constant and the resistance value. I think we should limit the number of detected steps to the number of commanded steps.

See the image below plotting bias step timestreams and the found location of edge_idxs.

The extra step throws off the average step response and the fit resistance, see below:

I propose limiting the number of returned edge_idxs to match those commanded when taking the bias step, specifically by changing _find_bias_edges from https://github.com/simonsobs/sodetlib/blob/60592c8d34b32a7d4c0899438df141465644c0a9/sodetlib/operations/bias_steps.py#L345-L347

to something like

nsteps = self.run_kwargs['nsteps']
for bg, bias in enumerate(am.biases):
    edge_idxs[bg] = np.where(np.diff(bias) != 0)[0]
    edge_signs[bg] = np.sign(np.diff(bias)[edge_idxs[bg]])
    edge_idxs[bg] = edge_idxs[bg][0 : 2*nsteps]
    edge_signs[bg] = edge_signs[bg][0 : 2*nsteps] 

After implementing this change, I obtained the following new version of the step response and R0 histograms:

There's still a population of channels with a measured resistance half that of the actual value, which is due to some other mechanism. The number of channels with a negative resistance value is greatly reduced, although not completely eliminated. I've seen a similar improvement when analyzing 8 other bias step measurements, taken across five different UFMs, four different cryocards, and three SMuRF slots.

[jlashner]

Hi Daniel, so the spurious step here is actually just coming from the fact that currently we're setting the biases to low-current-mode before we stop streaming, which it is counting as a step. I actually fixed this issue but unfortunately it's in PR #209 because I was testing in that branch at the time. I think we should wait until that's merged (which will be as soon as I can conduct final tests), and if you're still seeing issues we can add a restriction on the number of steps. Though we'll need to restrict to 2* (nsweep_steps + nsteps) instead of 2*nsteps.

During testing on k2so we were also seeing channels that somehow responded to bias-steps from multiple lines, and if you plotted the step response, you could see 2-3 individual steps, like this: This would cause the step height to be 2-3x as large as it should be, giving you resistances that were 1/2 or 1/3 of their actual value. I wonder if this is what you're seeing? We were able to get these to go away by only running sweep-steps so that multiple bias-groups were not stepping at the same time. If this is a large problem we should just make running steps on 1 bg at a time the default.

[jlashner]

Hi Daniel, so the spurious step here is actually just coming from the fact that currently we're setting the biases to low-current-mode before we stop streaming, which it is counting as a step. I actually fixed this issue but unfortunately it's in PR #209 because I was testing in that branch at the time. I think we should wait until that's merged (which will be as soon as I can conduct final tests), and if you're still seeing issues we can add a restriction on the number of steps. Though we'll need to restrict to 2* (nsweep_steps + nsteps) instead of 2*nsteps.

During testing on k2so we were also seeing channels that somehow responded to bias-steps from multiple lines, and if you plotted the step response, you could see 2-3 individual steps, like this: This would cause the step height to be 2-3x as large as it should be, giving you resistances that were 1/2 or 1/3 of their actual value. I wonder if this is what you're seeing? We were able to get these to go away by only running sweep-steps so that multiple bias-groups were not stepping at the same time. If this is a large problem we should just make running steps on 1 bg at a time the default.

[dpdutcher]

That doesn't appear to be what I'm seeing, I've looked at several channels that have R0 1/2 of what it should be (there's 169/1568 that meet that in this set I'm looking at), and their steps all line up. Almost all the ones that have 1/2 Rn are from one or two bias lines, though exactly which depends on the data set I'm looking at, and it doesn't seem to be purely fixed to which UFM or which cryocard I'm using, but I might have to look into that more.

I like the idea of at least making it an option to run on 1 bg at a time, since that also address that random commit comment I had about create_bg_map.

Ah, yes you're right that it would have to be 2 * (nsweep_steps + nsteps). While it's nice that this may be solved after that PR, I'd also want a solution that can fix the problem in data already on disk.

[dpdutcher]

fixed by #209