Poorly aligned stacks with OCPI2

[Cody-G]

I'm still trying to make sure I understand the reasons that back-to-back stacks do not align well on OCPI2. These factors probably don't help:

1). Noisy piezo readout (MON) signal. It's unclear whether noise in this signal is a problem for normal microscope operation, because according to the company our 30V300 uses a different signal for its closed loop controller. It's certainly a problem for our future plans to do real-time triggering based on the MON signal, but that is a different issue.

2). Noisy analog output from the DAQ. We get 2mV RMS noise on the control signal that we're sending to the piezo. This seems too high, but it's not clear whether it's responsible for our misalignment. The company doesn't seem to be helpful unless you pay them. I'll post back here with updates.

3). The camera and piezo are started sequentially every stack. Thus we get some variability in relative start times due to the Windows scheduler. I have a PR on the way that takes care of this by using the camera exposure signal to trigger the piezo motion sequence for each stack.

[timholy]

I think your 3rd choice seems very likely. What's your typical frame time---a few ms, right? So if there's ~1ms of jitter it's a significant factor?

[Cody-G]

That is true, but this shows up even on relatively slow stacks would work fine on OCPI1, even though OCPI1 starts them sequentially. I did more tests over the weekend, and the new triggering method has not fixed the problem. I still think it's a good change, but we have a bigger problem somewhere.

My main new observation over the weekend is that the stack-to-stack misalignment is actually periodic, meaning that the alignment shifts smoothly between good and bad at a reliable frequency during recording. Some important points:

• The length of this period is not fixed, but depends on the speed of scanning
• The oscillation, when seen, is always a bit slower than the scan rate. The period seems to range from 2 - 5 stacks in length, and I haven't found a simple rule for what determines this length.
• At extremely slow scan rates (~4 seconds per stack) the oscillation is not seen

This is pretty puzzling. The dependence of the frequency on the scan rate suggests that it's not coming from some other vibration or noise in the room, but from the motion of the piezo itself. My current best guess is that the motion of the piezo is actually inducing some swaying in the entire microscope relative to the sample (Recall that all of the optics are on a breadboard suspended by a single large support beam). I plan to add another support beam in the hopes of stabilizing the breadboard. But I'm skeptical that this will fix the problem, so if anyone has other ideas I'm happy to try them. I'm especially skeptical because it seems unlikely that this kind of sway would exist only along the axial dimension...

To follow up on my earlier points, I think I can eliminate point number one (noisy MON) because this problem occurs in open loop mode as well. I think I can eliminate point number two (noisy MOD) because I can't imagine how it could cause slow oscillations like the ones I'm seeing, though there may be some obscure electrical explanation that I'm missing....

[timholy]

Random musings:

• Does the accelerometer provide any insight?
• Does this periodic misalignment only happen near the beginning of an acquisition? (What if it's some kind of weird thermal effect? Running it a while might help temperatures equilibrate, and thus reduce the scale of the problem.)
• Do you see roughly the same thing no matter whether you're looking at the command voltage vs the MON signal?
• Is there any chance that this is somehow coupling to the sample in the dish? I.e., that the objective motion is causing changes in the sample morphology?

[Cody-G]

Does the accelerometer provide any insight?

It does seem like this should provide insight. Unfortunately I discovered over the weekend that the accelerometer I bought is not sensitive enough at the low frequencies and acceleration values that are relevant here, and also that it's poorly designed in general. I began the return process and ordered a replacement today that should be much better...the new one should be good enough for seismology ;)

Does this periodic misalignment only happen near the beginning of an acquisition? (What if it's some kind of weird thermal effect? Running it a while might help temperatures equilibrate, and thus reduce the scale of the problem.)

I'm not sure I understand how that would work but sounds worth a look. I didn't look at longer recordings since changing the piezo triggering. I should be able to check it tomorrow.

Do you see roughly the same thing no matter whether you're looking at the command voltage vs the MON signal?

I'm not sure whether this answers your question, but here is what I've done so far: I recorded the MON and MOD signals simultaneously with Imagine while doing a multi-stack acquisition. I used the MOD signal to segment the trace into multiple stacks and align the traces. I then overlaid the MON and MOD signals from multiple stacks. Observations:

• The MON signal is in general more noisy than the MOD, and has a prominent component around 100-200Hz. As a side note, I've been able to remove this by creating a simple RC filter.
• When I compare the traces within the MOD group, within the MON group, or across groups, there are no obvious differences in shape (they just look like noisy versions of the same signal, with the MON signal offset in time vs MOD as one would expect). But this is something worth looking at more closely--I easily could have missed a subtle periodic effect, and the new triggering method will improve the alignment of the traces.

Is there any chance that this is somehow coupling to the sample in the dish? I.e., that the objective motion is causing changes in the sample morphology?

In that case I would have expected to see the same thing on OCPI1, but it's possible that the effect is just stronger on OCPI2. Maybe the OCPI2 light sheet "cigarette" is less hydrodynamic? I tried switching to a higher-percent agarose gel thinking that the beads could be moving somehow but it doesn't seem to make a difference. Still it's worth trying on OCPI1 with the same exact sample, I will do that.

[Cody-G]

I've finally figured this out.

• The dovetails used to position the light sheet had a little bit of play in the joints. This meant that any bumping or fast oscillation of the sheet optics would cause the sheet to wobble into a different plane. We've made two hardware modifications to address movement in two different dovetail joints. 1) Created a mechanism to lock the focus adjustment dovetail into place, and 2) Added a small piece of hardware with a plastic screw that applies downward force on the light sheet housing.

• The hardware changes weren't enough to eliminate the low-frequency oscillation that I described previously. It turns out the piezo positioner exhibits a slight artifact when it resets to the starting position between stacks. It doesn't stop on a dime, but oscillates subtly. If the next stack starts during this oscillation (i.e. there is a very small downtime between moving back and starting the next stack) then its trajectory will depend on precisely when we decide the start the stack during the artifact period. This start time is not completely consistent because currently it is based on a software timer. So strangely I think that the slow stack-to-stack oscillations we see reflect periodicity in the timing of our code rather than in hardware. This will be completely resolved when we switch to hardware timing for all instruments (see the waveform branch). In the meantime, I've found a workaround: Set the "time for moving back" slightly longer than the "time between stacks". This of course means that every stack will be "overrun" and you will get lots of warnings. The benefit is that the piezo will never stop between stacks, so the artifact doesn't kick in. I'm leaving this issue open until our more robust hardware-timed solution branch is ready.

[timholy]

Wow, it's always hardest when there are two factors to track down. Really nice work! Are you pretty satisfied with the alignment now?

[Cody-G]

Yes I am. I'll calculate the PSFs formally (and publish a little Julia package to do so) but I think they are close to what we want in X and Y. I'm wondering if the light sheet is a bit thicker than we expected. In order to check that I guess I should compare the expected 1/e2 beam intensity from our Matlab software with the measured intensity in Z? I'm experimenting with using a wider beam for smaller samples (the wider-beamed collimator is on order).

~Cody

On Mon, Apr 3, 2017 at 10:49 AM, Tim Holy notifications@github.com wrote:

Wow, it's always hardest when there are two factors to track down. Really nice work! Are you pretty satisfied with the alignment now?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HolyLab/Imagine/issues/27#issuecomment-291184792, or mute the thread https://github.com/notifications/unsubscribe-auth/AE78hB8Xu9bPhLamOJTRSN9SRDn-p-G2ks5rsRTvgaJpZM4LwQNy .

[timholy]

That sounds like the right approach. One concern with a wider collimator might be reflections from the "carrier" for the optics; be alert for weird side lobes and check the intensity of background as well as the width of a bead.