We have a Princeton Instruments VersArray 1024 frame-transfer camera with a USB interface. These notes were originally written for Linux Fedora Core 4 with PVCam version 2.7.1.7. We then updated to Scientific Linus 6.3 and a newer non-official USB driver and that significantly reduced the frequency of computer hangs. We then updated to PVCam 2.7.4.2, but we still see corrupt images if we don't close and reopen the camera after every exposure sequence, and the camera sometimes fails to respond to a trigger pulse. Note that PVCam 2.7.4.2 is likely to be the last version because newer PI cameras use a different library called PICam and an ethernet interface.
Tidbits
The position fields for rgn_type (s1, p1, s2, p2) are 0-based unbinned pixels and the end position (s2, p2) is included in the region. I could not find some of that information in the manual.
Annoyances
PVCam calls are not protected against ctrl-C interrupts. For instance it takes 20 seconds to open the camera and a ctrl-C during that time can crash your computer. My solution is to mask interrupts during any PVCam call other than one that simply reads state.
The camera's sync pulse input is level-triggered, not edge triggered, despite what the manual says. If the output is still low when the camera has finished reading the exposure, it will read another exposure.
Minor Bugs
The overscan has problems. Overscan by "n" pixels in y seems to change the top "n" rows of the science image. If you overscan by "n" pixels in x the science image looks OK, but the first 18 unbinned pixels look different than subsequent pixels. This could be due to the postscan pixels, but the number reported by PVCam is not 18 so this answer is not the whole story.
Close and re-init the camera, as follows:
...
pl_cam_close(0)
pl_pvcam_uninit()
pl_pvcam_init()
The call to pl_pvcam_init returns false but pl_error_code is 0 and it doesn't sem to cause any problems. Sleeping for a second between the uninit and the init does not help. I'm not sure if there's anything that will avoid pl_pvcam_init returning false if the same process has already opened the camera and then closed it.
If the camera is not quite ready when you connect you may see this nonsensical error in response to pl_cam_get_name(0, <camera name>) (nonsensical because 0 is the index of the first camera):
C0_CAM_NAME_OUT_OF_RNG The number must be in the range 1≤num≤=totl_cams
Serious Bugs
The USB interface requires special device drivers. Unfortunately they are buggy and only work with very old versions of Linux. After using the camera for awhile we cannot unload the driver without bringing the whole machine down: it freezes, requiring a power cycle of the computer and camera to recover, which in turn destabilizes the camera temperature. This strongly suggests a corrupt kernel.
The camera will sometimes no longer respond to an external trigger pulse.
One can reliably get corrupted images (a band of zeros of varying width along the top of the image) using the following procedure (and this can put the camera or computer into a bad state). However, we found a workaround: close and reopen the camera between every sequence of exposures. Unfortunately this takes 20 seconds.
- reset the camera:
- unload device driver
- power off camera
- delete device
- power on camera
- open the camera
- take 3 full-frame unbinned 0-second exposures using a circular buffer and internal timing (bias frames).
- take 3 full-frame binned 2x2 1-second exposures using a circular buffer and external sync pulse for timing.
- the 2nd set of exposures are all corrupted; they have strange bars running through them and look as if the data is not properly aligned.
Here is source code to reproduce the problem.
Call pl_exp_start_cont (to start a continuous exposure sequence into a circular buffer) with a circular buffer that holds too many images and you will hang your computer. I think the limit is in the ballpark of 32k images. Note: it is the number of images, not the buffer size, that matters; you can get into trouble using a reasonable sized buffer with tiny subimages.
A related but less serious problem: if you call pl_exp_start_cont with a buffer that holds many (small) images but not so many as to crash, then it will work but closing the camera can take 30 seconds. Normally close is very fast.