I am testing fast readout mode using 6 STF-8300 cameras, connected via C interface of the SBIG DLL. When I transfer images without fast readout, it takes 1800 ms for the first camera, and 800 ms for all other cameras. With fast readout, it takes 800 ms for all cameras. I also observed that with fast readout, image from first camera has some faint vertical lines (artifacts?), and it slightly brighter than without fast readout. Other camera images did not visibly change. My DLL version is 4.9.9.3 and firmware version 2.58. So does the fast readout mode work only for the first camera? Is this a bug? Why does the first camera have longer readout time when fast readout is not enabled? Or is it the other way around (always enabled for every other camera except the first)? How should I expect transfer times to change when using fast readout with 6 cameras? What kind of artifacts are to be expected?
Hi Ville, There should be no difference between the handling of the first camera and subsequent cameras when it comes to exposure/readout settings. Each camera has a completely separate entry of all relevant parameters—so if you're doing any special driver/camera/exposure/readout setup, you need to call it for every single instance. I'm seeing round-trip start-exposure to end-readout durations of about 1.8 seconds for regular readout, and 0.9 seconds for fast readout for every camera in my imaging train. Note that while you can take simultaneous exposures, readout must occur sequentially, and SBIGUDrv is *not* thread-safe. Can I see your exposure setup calls? I'd like to better understand what's going on. Cheers, -Adam
Actually it seems that first camera takes longer time when hardware triggering is enabled. In these logs, first camera takes 1577 ms and other cameras take short time. Without hardware triggering, all cameras take short time. This is with fast readout not enabled for any camera. And after we enable fast readout, the only change is that the first camera also takes a short time. We send identical start exposure parameters for each camera. We have noticed before that with firmware 2.62 all cameras take 1800 ms to readout, while with 2.58 and older cameras 2-6 take only 800 ms. This was with hardware trigger enabled and fast readout not enabled, I don't know how the times look with hardware trigger not enabled. Do you know what explains the difference between the versions? With hardware triggering enabled, no fast readout (some commands have been omitted from the log): Code: 2018-12-18 09:48:48.437534 Sending command to camera A1: CC_START_EXPOSURE2 2018-12-18 09:48:48.444347 Sending command to camera A2: CC_START_EXPOSURE2 2018-12-18 09:48:48.449850 Sending command to camera A3: CC_START_EXPOSURE2 2018-12-18 09:48:48.454970 Sending command to camera B1: CC_START_EXPOSURE2 2018-12-18 09:48:48.460241 Sending command to camera B2: CC_START_EXPOSURE2 2018-12-18 09:48:48.465890 Sending command to camera B3: CC_START_EXPOSURE2 2018-12-18 09:48:48.473659 Sending trigger signal. 2018-12-18 09:48:51.726236 Finished exposure. 2018-12-18 09:48:51.755219 Sending command to camera A1: CC_END_EXPOSURE 2018-12-18 09:48:51.775821 Sending command to camera A1: CC_START_READOUT 2018-12-18 09:48:53.352588 Sending command to camera A1: CC_END_READOUT 2018-12-18 09:48:53.371924 Sending command to camera A2: CC_END_EXPOSURE 2018-12-18 09:48:53.392720 Sending command to camera A2: CC_START_READOUT 2018-12-18 09:48:54.045134 Sending command to camera A2: CC_END_READOUT 2018-12-18 09:48:54.066213 Sending command to camera A3: CC_END_EXPOSURE 2018-12-18 09:48:54.086994 Sending command to camera A3: CC_START_READOUT 2018-12-18 09:48:54.881038 Sending command to camera A3: CC_END_READOUT 2018-12-18 09:48:54.910642 Sending command to camera B1: CC_END_EXPOSURE 2018-12-18 09:48:54.931975 Sending command to camera B1: CC_START_READOUT 2018-12-18 09:48:55.690016 Sending command to camera B1: CC_END_READOUT 2018-12-18 09:48:55.725742 Sending command to camera B2: CC_END_EXPOSURE 2018-12-18 09:48:55.746257 Sending command to camera B2: CC_START_READOUT 2018-12-18 09:48:56.500691 Sending command to camera B2: CC_END_READOUT 2018-12-18 09:48:56.537078 Sending command to camera B3: CC_END_EXPOSURE 2018-12-18 09:48:56.558090 Sending command to camera B3: CC_START_READOUT 2018-12-18 09:48:57.325589 Sending command to camera B3: CC_END_READOUT Without hardware triggering, no fast readout: Code: 2018-12-18 09:50:41.833806 Sending command to camera A1: CC_START_EXPOSURE2 2018-12-18 09:50:42.130472 Sending command to camera A2: CC_START_EXPOSURE2 2018-12-18 09:50:42.428238 Sending command to camera A3: CC_START_EXPOSURE2 2018-12-18 09:50:42.535268 Sending command to camera B1: CC_START_EXPOSURE2 2018-12-18 09:50:42.639879 Sending command to camera B2: CC_START_EXPOSURE2 2018-12-18 09:50:42.746832 Sending command to camera B3: CC_START_EXPOSURE2 2018-12-18 09:50:45.976087 Finished exposure. 2018-12-18 09:50:46.015293 Sending command to camera A1: CC_END_EXPOSURE 2018-12-18 09:50:46.036561 Sending command to camera A1: CC_START_READOUT 2018-12-18 09:50:46.870187 Sending command to camera A1: CC_END_READOUT 2018-12-18 09:50:46.887846 Sending command to camera A2: CC_END_EXPOSURE 2018-12-18 09:50:46.908745 Sending command to camera A2: CC_START_READOUT 2018-12-18 09:50:47.642081 Sending command to camera A2: CC_END_READOUT 2018-12-18 09:50:47.679262 Sending command to camera A3: CC_END_EXPOSURE 2018-12-18 09:50:47.700293 Sending command to camera A3: CC_START_READOUT 2018-12-18 09:50:48.451444 Sending command to camera A3: CC_END_READOUT 2018-12-18 09:50:48.473104 Sending command to camera B1: CC_END_EXPOSURE 2018-12-18 09:50:48.494411 Sending command to camera B1: CC_START_READOUT 2018-12-18 09:50:49.206634 Sending command to camera B1: CC_END_READOUT 2018-12-18 09:50:49.223616 Sending command to camera B2: CC_END_EXPOSURE 2018-12-18 09:50:49.244209 Sending command to camera B2: CC_START_READOUT 2018-12-18 09:50:49.930683 Sending command to camera B2: CC_END_READOUT 2018-12-18 09:50:49.947094 Sending command to camera B3: CC_END_EXPOSURE 2018-12-18 09:50:49.968053 Sending command to camera B3: CC_START_READOUT 2018-12-18 09:50:50.681395 Sending command to camera B3: CC_END_READOUT
These are the parameters we use. Width and height are the full sensor dimensions retrieved from the camera. Exposure time 3000 ms was used for these tests. Code: ::StartExposureParams2 sep; sep.ccd = CCD_IMAGING; sep.exposureTime = (std::max(1u, static_cast<unsigned int>( exposure_time.total_milliseconds() / 10))) & EXP_TIME_MASK; sep.exposureTime |= EXP_WAIT_FOR_TRIGGER_IN; sep.openShutter = SC_OPEN_SHUTTER; sep.top = 0; sep.left = 0; sep.height = height; sep.width = width; sep.readoutMode = 0; ::StartReadoutParams srp = { ::CCD_IMAGING, ::RM_1X1, 0, 0, height, width }; ::ReadoutLineParams rlp = { CCD_IMAGING, RM_1X1, 0, width }; ::EndReadoutParams erp = {::CCD_IMAGING};
There were a number of changes between 2.58 and 2.62 relevant to the STF-8300. This is the changelog: 2.59: doesn't apply to STF-8300. 2.60: Fixed auto-offset issue in STF-8300. 2.61: Delayed start of readout until user calls CC_START_READOUT due to imaging artifacts in bias frames. 2.62: doesn't apply to STF-8300. Are you able to revert the firmware on your first camera back to 2.58?
This should explain the difference, because we send CC_START_READOUT to the each camera after we have finished reading data from the previous camera (see the logs in previous message). So while we are reading data from the first camera, with version 2.58 the other cameras are doing something that allows their readout to process faster. What can we do to decrease the readout time with the newest version? Could you make the old behavior optional? If we start using fast readout mode instead of default mode, what kind of artifacts are to be expected? Are they in every image or happening occasionally?
There's no way to make that behavior optional without sacrificing image quality. If you're able to live with the artifacts in the image, we suggest you roll all your cameras back to the same firmware version. The old adage, "if it ain't broke, don't fix it," applies here. The artifacts you should expect from rolling back are vertical stripes due to LED toggling, and some vertical "bumps" in your images (our internal documentation didn't have any example images, sadly). They would occur in every image. As for Fast Readout vs Default Readout: there is no difference for the STF series. Fast readout used to be defined as the simultaneous readout & download of the image (as opposed to readout, followed by download), but the STF series is clean enough that we can do both simultaneously with little impact on image quality. I advise saving yourself the extra bit-bashing and just call default readout mode.
