Times they are a changin'

Here's a dandy chart showing the decrease in frame rate as the WFS image size is increased. Each sub-aperture is around 22 px across, and each pixel is around 6 um, so that gives you an idea of the beam size necessary. I also varied the shutter speed, but this should obviously be set to the minimum value necessary to see the centroids.



Aligning the beam is turning out to be problematic because the divergence is significant as the beam size shrinks. The good news is that a windfall in our equipment budget means I'm finally getting a HeNe laser like I always wanted. expanding it is slightly more involved than with the diode laser I'm using now, but I should be able to clean it up using a spatial filter and get a pretty nice spot.

As a matter of fact, we also ordered a new DM to use in place of the retarded SLM I've struggled with. The new DM contains around 60 actuators compared to the 31 in the current model. It might seem odd to use the higher density DM as a disturbance generator, but in RL atmospheric turbulence is always going to generate higher (spatial) frequency distortion than can be corrected with a finite actuator DM.

This basically means that all the active components of my experiment are going to be repaired/replaced in the next few weeks. I really really hope that's it because frankly i'm tired of dealing with all this optics shit.

A word about speed

Even with the latest improvements its unlikely that I'll every be able to run my experiment fast enough for real real time (need 10's of kHz for that). Still, 50 Hz is better then 3. There are several factors that affect the temporal sampling rate of my experiment. Most of them are interrelated, so it helps to sort out just what impacts what.

Essentially, there are 3 time-comsuming operations that have to be completed each iteration. Ignoring the time to calculate control signals, these are: Commanding the DM, capturing the WFS image, and processing the image to generate the slope vector.

Sending DM Commands:
This is basically fixed around 100 Hz currently. I'm still not sure if the actuators actually reach their steady state positions at that speed, hopefully I'll have that sorted out next week. The unknown here is that the fwrite command used here can time out, basically crashing the whole enchilada.

Capturing WFS image:
As I found out last week, the frame rate of the WFS is a function of the frame size and the shutter speed. The frame size dictates the number of sub-apertures used, and hence determines the spatial sampling frequency. Intuitively, reconstructing (and hence controlling) higher spatial frequencies means a slower frame rate.

Short shutter times also increase the frame rate, but only up to a certain point. Beyond that, the frame size basically determines how fast the thing can go. Generally, the idea is to select the minimum shutter speed necessary to accurately image the sub-apertures.

Computing Slope Vector:
Again, this is a function of how many sub-aperatures are being used. I'm not exactly sure how this varies though since its cumbersome to alter the code every time for a new image size.

Clearly a lot of these parameters are fixed by the experiment. The DM only has 31 actuators, so there's a limit to the required spatial sampling frequency. Whats more, for a given laser the shutter speed can just be set to the smallest value that still allows the centroid algorithm to work. That basically leaves the WFS frame size as the only parameter that can effectively be varied. I'm hoping to write up a little script this weekend to see how the overall frame rate is affected by this.

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.

One word: plastics

Its nice to find out, after almost a year of running experiments, that my DM is f0xred and probably has been for quite some time. I was always suspicious since my reconstruction errors were sometimes astronomical, but control always seemed possible nonetheless. I found out the thing was screwed by accident.

Basically, running the DM faster involved using a new command that allowed multiple actuators to be commanded simultaneously, rather than one at a time as before. The command rate of the DM should therefore be ~30x faster, easily into the hundreds of hertz. However for whatever reason using this command on my DM caused havoc, essentially freezing it in the zero position until I manually unplugged it. Days went by as I tried various explanations, before I eventually wrote a script that seemed to work on the other AO experiment we have using the same DM and driver box (I had to make some creative guesses on how to format the parameters used in the command). The code was indeed around 30x faster, but my DM was still crapped out.

Coincidentally, I ran some test using the old command to look at the linearity of the DM surface to voltage commands. As expected, some of the them responded quadratically, but the large majority didn't respond at all. After some back and forth with the manufacturers, I was able to trigger the WFS asynchronously as a command was sent, and was able to actually catch the actuators moving. Sure enough, some seemed fine, but in many cases the influence functions decayed significantly (sometimes to zero) within milliseconds of the command.

[insert pic]

Clearly something was fucked. After another week of test to convince everyone I wasn't hallucinating, we finally got a new DM yesterday. This mirror has some odd annular actuator arrangement, so I doubt we'll end up using it permanently, but so far it seems to be taking the new commands without complaint. I haven't checked for actuator decay yet, but so far there's no evidence of funny business. I also have a voltage sampler to check the response of the drive box, but I doubt that's malfunctioning.

Its irritating though that even after demonstrating what I consider to be a significant amount of code (instead of just using "their software"), the guys who make the mirror still seem to think I'm something of an optical retard. I guess its always better to overachieve.

Tomorrow:
- test the DM for actuator decay
- use the voltage sampler to test the drive box
- examine the runtime errors I get with the manufacturer's software