User:Steven J. Koch/Notebook/Kochlab/2009/07/09/Beginnings of OT Calibration

From OpenWetWare
< User:Steven J. Koch‎ | Notebook‎ | Kochlab‎ | 2009‎ | 07‎ | 09
Revision as of 23:34, 9 July 2009 by Steven J. Koch (talk | contribs) (→‎Power spectrum possibility?)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Link to data directory: http://kochlab.org/files/data/Kochlab-daq2/koch.steve/July%2009%20Calibration/090709

Steve Koch 22:58, 9 July 2009 (EDT): Even though we only had about an hour, Andy and I tried out some OT calibration. We were hindered by the power spectrum VI not working (I think this is because it uses traditional NI-DAQ stuff, which no longer works on this computer). However, I was pleasantly surprised that we got some things working with the Feedback 96 software. In fact, except for the memory leak (which I've now fixed), I think it worked very well at least as far as "position ramp piezo" is concerned. We achieved two things:

  • Saw a square wave X signal when doing triangle wave piezo
  • Saw a DOG (derivative of guassian) curve with stuck bead.

Andy made a nice dual stuck bead (4 M NaCl) / free bead (water) sample, which made this very convenient. I'll post some graphs below, but not sure if will do much analysis, since we can do things better tomorrow. It's also not clear yet whether we need to realign the tweezers after a mirror bump. Actually undoubtedly we do, but since we're trying for some preliminary data within one week, it may be more prudent to wait. Having the power spectrum would help.

  • Andy Maloney 23:29, 9 July 2009 (EDT): I knew you were going to say I needed to realign the laser. I will do it first thing in the morning tomorrow. I'll be sure to be done with it before you get in.
    • Steve Koch 00:04, 10 July 2009 (EDT): Let's talk about it. It definitely will need it at some point. But what if we discover something else after that? and after that??? Those 4 hours of alignment add up and add up and also tire you out like crazy.
      • Andy Maloney 00:52, 10 July 2009 (EDT): I agree. Should I get some more stable mirror mounts then?
      • Steve Koch 00:57, 10 July 2009 (EDT): Maybe. Let's talk about it tomorrow?

Data set notes (from memory)

  • 0000 & 0001 -- bad / DAQ set to DIFF
  • 0002 -- I believe this is the free bead that we can look at the power spectrum perhaps
  • 0003 -- Don't remember what this file is
  • 0004 -- Bad. Global variable reset to DIFF
  • 0005 -- Piezo triangle / X square wave #1 -- piezo reaches max limit. See graph below.
  • 0006 -- Trying to find DOG, but I believe we missed the bead?
  • 0007 -- Garbage
  • 0008 -- Same as 6, I think.
    • I note substantial rigning in this data set. That's not good.
  • 0009 -- "Half a dog" -- we started with the trap sort of centered on the bead, so we wouldn't miss it during sweep.

Viscous drag triangle wave

This is pretty cool! The graph on the right shows the piezo sensor. You can see that we maxxed out the travel, and thus that's why we see the three steps in the square wave (showing where "zero" force is).

Steve Koch 22:58, 9 July 2009 (EDT): We used "position ramp piezo" to drive the piezo first in one direction, and then in the other. This provided a nice detector signal. We did not loop the process, only back and forth one cycle.

Half a DOG

Steve Koch 23:04, 9 July 2009 (EDT): We had trouble with some sliding of the sample (not sure why exactly) and also with knowing which way the piezo would sweep relative to the camera. Basicaly we were pretty rushed. SO, the first couple DOG tries, we missed the bead. The final file, when we decided to call it quits we put the laser right on top of the bead. Thus, you only get slightly more than half of the DOG on each side. With 5 more minutes, we could have easily done better, but it's enough to see that things are behaving as expected.

Showing the distinct antisymmetric X signal when sweeping stuck bead through trap
Same as previous graph, showing piezo (linear) sweep data as well
Same as previous, but showing Y signal instead of piezo. The Y has substantial signal, because the bead is not centered in Y. Ideally, not being centered, the Y should have a Gaussian-like signal (that is, symmetric).


Showing sum signal as well. You can see that this looks a lot like the Y. I remembered that this QPD does not normalize by the sum, and thus X and Y will have substantial components of the sum signal. We should probably fix this hard-wired in the DAQ software, to make it like how it's set up (for the On-Trak amplifier, which did divide by sum). Also, this shows some serious cross-talk between the Sum and the bead deflection. We definitely need to look into this. It could mean the bead is too big for the detector, which is not difficult to change.

Above is shown the X signal along with Piezo and Y. To the right is shown the sum signal. Read the caption for description of problem.

  • Andy Maloney 23:37, 9 July 2009 (EDT): Do you really want to have the software normalize because I can hardwire it with a chip very easily wihout having the software do it. I'm thinking that it will slow things down in the software and you mentioned things are running slower than usual.
    • Steve Koch 00:04, 10 July 2009 (EDT): One thing Richard and I discovered back in the day is that once you start involving data transfer over the PCI bus, everything is dominated by the PCI bus latency (about 3 microseconds per data transfer request). Thus, if you're reading X,Y,Sum, Piezo, two counters, and also setting Piezo, that's a minimum of 18 microseconds. In our case, we're up at around 300 microseconds already, because of a lot of DAQmx overhead, I think. This is a long way of me telling you that simple arithmetic operations on the CPU are completely negligible. And thus, building our own hard-wired thing is not at all necessary.

Power spectrum possibility?

Steve Koch 23:59, 9 July 2009 (EDT): Looking at file 0002, I modified simple plotter to extract a power spectrum (hard-coded the time step as 0.000350). I then wrote a quick VI to fit the power spectrum (deleting the two lowest frequency points first). Doing this, I get a corner frequency of about 75 Hz. My initial thinking is that this is very low, given the laser power we were using. But it's all so hastily done that no conclusions are probably good except to say it definitely looks like a trapped bead power spectrum. Cool!

Steve Koch 01:07, 10 July 2009 (EDT): If I'm doing the quick calculation correctly, this would put the stiffness very low. Based on Richard's Master's thesis, I would have expected much higher corner frequency for the laser power we were inputting. This stiffness would be about .002 pN / nm:

  • Viscosity about 1 cp = 1 pN * ns / nm^2
  • eta for 250 nm radius @ 1 cp = 6 pi eta * a = 4712 pN * ns / nm
  • omega = 2 pi f = 471 (coincidentally the same digits as eta calc, due to 75 and 250 being off by factor of 0.3)
  • stiffness = 2.22 E6 pN / m = 0.0022 pN / nm.



Andy Maloney 02:15, 10 July 2009 (EDT): Would overfilling the back aperture help in making the stiffness too low? Also, would the fact that the QPD is overfilled do the same?

  • Steve Koch 02:34, 10 July 2009 (EDT): There should be a maximum in stiffness as a function of input beam diameter. The cool thing is we can try to measure this since we have that bad-ass beam expander. In fact, we can now see it in real time with Richard's awesome real-time power spectrum module! Shouldn't we probably do this before realigning??? As for QPD, if we're really doing something wrong, it could matter. But otherwise, I don't think so (if we're in some reasonable range).

As of now, need global variable set to RSE for DAQ

Steve Koch 22:58, 9 July 2009 (EDT): Not sure how to properly use DIFF at this point.

Retrieved from "https://openwetware.org/mediawiki/index.php?title=User:Steven_J._Koch/Notebook/Kochlab/2009/07/09/Beginnings_of_OT_Calibration&oldid=322897"