6-18-07

Last week I looked into software which would work well with the frame grabber that I installed in the m25 machine. I wrote up some notes on the hardware and useful software which I have found:

I. Features

• [http://www.integraltech.com/FileDownloads/fe8349_FB_SpectrimLite.pdf Official Info Sheet] on the Integral Technologies FlashBus Spectrim Lite

Notable excerpts:

• 16 MB of memory
• S-Video and BNC inputs
• Good support for Windows but not much for Linux or anything else
• Max. resolution of 640x480 in NTSC mode

II. Installation

Video For Linux (V4L) installation software can be found on Integral Technologies's website: http://www.integraltech.com/FileDownloads/e2245e_spectrim-v4linst-v2.5.tgz

Compiling and installing this software should be enough to get the card up and running. The release notes state that the software has been tested on Fedora Core 2 and 4 but it also works on FC3 (albeit with some bugs).

After installing the software, make sure to specify the amount of memory available to the card in grub or lilo as described in the README.mem file! Otherwise, V4L programs (including the test programs that come with the card's software) could crash the computer. Also, make sure to run the startFbspSupt script included the support directory. This program will output a "test.bmp" file so you can tell if your card is working.

III. Software

• There are a lot of V4L applications which have a large number of dependencies and which crash a lot. The better ones I have found for the Spectrim are:

1. videodog ([http://paginas.terra.com.br/informatica/gleicon/video4linux/videodog.html Homepage])

videodog is a simple capturing utility which is good for capturing single images from the frame grabber. It has some useful features, like optional JPEG capture and timestamps in the image, as well as optionally automatically timestamped file names so that it can be run easily from scripts (including Matlab). The loop capture has a bug which makes it output junk to the terminal, and the normal capture has a bug where there are invalid calls to the V4L API. I think these are both driver problems, but the single capture / auto-timestamped capture works. If the output is suppressed by appending ">> /dev/null 2>&1" to the end of the command it seems to work faster (i.e., looping the timestamp capture will not capture images as many times as videodog is called; it seems like commands will be lost when videodog is busy writing to stderr/stdout or capturing images).

videodog is a fairly simple program to edit. A major bonus is that it hardly has any dependencies (I think the only external dependency is libjpeg which seems to be standard), so compiling it should be easy.

2. xawtv ([http://linux.bytesex.org/xawtv/ Homepage])

xawtv is a TV application which allows you to view a live feed of the framegrabber's input, as well as capture still images in bitmap (ppm) or jpeg formats of the live feed. It has video capture capability, but as far as I can tell right now that feature either requires a lot of memory or the V4L software for the Spectrim is pretty shoddy since anything but low-framerate MJPEG capture ends xawtv in a segmentation fault or outputs a lot of errors.

xawtv comes with streamer, a program like videodog but one more prone to crashes. streamer should also allow you to capture video from the command line, but it crashes like the video capture from the xawtv GUI (probably because xawtv uses streamer to capture video and images).

motv has a cleaner GUI than xawtv itself, and comes with the whole xawtv suite of programs available on the website above.

Test Image

Here is a sample image taken at full resolution (640x480) in 24-bit color (although the video feed is black-and-white). The image is oversaturated at some points and the image is noticeably noisy. attachment:out.png

6-28-07

More Linux/hardware notes: before I forget, there is a SourceForge project which supports both the Agilent 82537A/B (the grey USB adapter) and the 82530B (the PCI card). It's called linux-gpib and it will hopefully work: http://linux-gpib.sourceforge.net/ .

It would be wise to read the documentation for supported GPIB interfaces first since the USB device needs to have its firmware flashed and messing that up would probably brick it. If I have extra time, I'll get around to this.

7-6-07

I have written a few Matlab scripts which with a bit of editing should give some good results. One script, modenum.m, is able to determine the m and n indices of HG (Hermite-Gaussian) modes given a CCD camera image. The script uses the straightforward method of taking the x and y projections of the intensity data in an RGB image, then finding the number of peaks in the projected intensity profile. This method assumes that the nodal lines are oriented roughly along the x and y coordinates of the screen on which the image was taken, so I added an option to rotate the captured images before the intensity profile is looked at. This requires a small amount of input from the user, but in the future I might be able to make the script either determine the proper image orientation or find the peaks in a more general way. The script works pretty well even for the dim, somewhat noisy images from the OMC camera. To find the peaks, I modified a simple peak-finding script, fpeak.m, that I got on a Matlab script-sharing site.

Another script, timed_capture.m, will grab frames of the OMC camera video as a scan is running, and label the files with the times at which they were taken. Then, the photodiode data will be imported into Matlab, the peaks in intensity found (to identify when the modes were scanned), and based on the time at which the peaks were scanned the script will look at the image taken around that time to identify the HG indices. The peaks in the plot will then be labelled with the correct HG mode indices (m, n). I've written the script, I just need to test it a lot and continue to write it.

Some things which I wish to add in the future include:

• A way to specify the triangle wave excitation to the OMC's PZT from inside the script, since right now this part isn't fully automated
• Actual analysis of the mode scan data, including finding the finesse, FSR, etc. and correcting for the differing length response of the PZT at different voltages
• Automatic identification of LG (Laguerre-Gaussian) modes in a scan--I think I could test this out on the PMC
• Automatically ignore all irrelevant image data (i.e., ignore everything the camera sees that is not the beam itself, as is the case with the large MC)
• Test these scripts a lot and try them out on different cavities, try to automate as much of the process as possible and make them well-documented and very unlikely to fail

Attached below is an example of an image of the TEM_00 mode on the OMC camera, and the x and y intensity projections with the peaks in intensity identified. The intensity maxima are easier to identify than the minima because the peak-finding range can be set to include less data, so that the chance of accidents is smaller than trying to identify mins, and setting this range for the maxima is more straightforward. Also, as long as the peak finder has a reasonable sensitivity to peaks it won't identify too many, even when there are many local max/min on the intensity projection due to interference patterns or noise.