Rewriting the slope estimation code turned into quite a shit storm of coordinates and indices, so it took me most of Wed. and Thurs. to write it and test everything. To answer the questions from before:

(1) The slope algorithm runs at 100 Hz as written for an array of 10x10 sub-apertures and an image around 220x220px. The image actually needs to be slightly larger since each sub-aperature isn't exactly 22 pixels wide (something I need to fix later). Suspiciously all three control processes: sending commands, reading a WFS image and processing the slope, top out around the same speed. The slope script can be sped up to around 300 Hz if I pass in the file containing the lenselet coordinates rather than load them each iteration (TURBO MODE!).

(2) Currently with a 10x10 sub-aperature WFS image, the whole process runs around 50 Hz. The strange thing is that the speeds aren't consistent with simply adding the speeds for individual processes. For example sending a DM command and just reading an image occurs at around 100 Hz, even though that is approximately the individual speed for each of those. Adding the slope finding script knocks this down to 50 Hz. Using turbo mode on the slopes causes the DM command script to hang (at fwrite).

(3) 50 Hz is probably sufficient for now, and reducing the shutter further doesn't result in much faster frame rates. The issue now is going to be alignment since a 220x220 px square is less than 2mm^2. Pushing to faster frame rates would mean even smaller beam sizes.

(4) Its probably possible to work with the current laser, but we have some equipment money to use so a new laser is probably in the cards.

I'll be out Mon and Tues taking advantage of my strict grad student schedule. The goal for next week is to have the beam resized with the current laser (probably minus the target splitter), and run the classical controller at 50 Hz. If possible I'd also like to look at the actuator dynamics with this faster WFS frame rate.

Word.

I'm an Idiot

Today I finally relented and had a telecon with some of the guys who manufacture our DM and WFS. They basically took over my PC and were able to get high frame rates right away by reducing the shutter speed to small values. I don't know why I didn't do this or do it successfully before now. Let this be a lesson to you kids: even if you're a moron don't give up hope on that phd.

I'm able to get rates >1000 fps if the shutter is small enough and the image size is 10's of px. The problem now is that, for a given image size, the exposure of the WFS image is entirely determined by the required frame rate. Obviously Nyquist's sampling theorem applies to spatial sampling, and increasing the number of lenselets used to measure the beam increases the image size. This means that there's a trade off between the spatial and temporal sampling resolution that I can get for a fixed laser intensity.



Right now it doesn't make much sense to sample much faster than the rate at which I can spit out DM commands (since I'm ignoring actuator dynamics atm), so a frame rate around 120 fps should be good for now. Screwing with the number of lenselets is a hassle since it requires changing the beam size and computing a new reconstruction matrix, but it appears I can get around 120 fps and still have an exposure sufficient to image the spots if I use a grid of around 10x10 sub-apertures (a WFS image of around 220x220 px).

Tomorrow I want to get an idea of what kind of rates I can expect in the finished product to determine what the bottleneck is now. Hopefully it'll be software this time. This will involve:

(1) Adjusting the slope-finding code to work with a 10x10 lenselet array. How fast will it run with this smaller size?

(2) Test out how fast the system can apply a command and return a slope vector -- no need to resize the beam quite yet. Does it matter what part of the frame is used? Prob not with a CMOS cam would be my guess.

(3) If thumbs up on the overall frame rate, figure out what the new beam size needs to be and start on the hardware changes.

(4) Once the beam size is good, determine if the shutter can be sped up at all. Today I had to remove the splitter to the target cam since these new exposures were too short to capture all the centroids. If adding that splitter requires too high a shutter it might be time to think about a class IIIa laser.

Once this is all hunky dory I'll need to know if the actuator dynamics are important at these higher frame rates. Shouldn't be a problem figuring this out using the code I wrote to test the messed up DM.

Finally, time to step off on this shite.