Hi, We are owners of a ST-8300M camera. We want to buy a second one and I have a important question. We coded an entire Labview program to handle the ST-8300M and we want to know if the new STF-8300M will be directly compatible with what we coded for the ST-8300M. Thanks for your help. Best regards, Gaël
Gael, if you utilize API calls to SBIG universal driver, than yes. All cameras are controlled exactly the same way, you basically open driver, open device, then call requested "get/set" functions, close device, close driver. Jan
Dear Jan, Thanks for you replay. We finally bougth a STF-8300M as a second camera complementary to our ST-8300M. As you said as long as we utilize API calls to SBIG universal driver everything should work in the same way. Some how we have a problem with the Labview code and I can't figure out what is going wrong. Our code works perfectly with the new STF-8300M until we call the "Readout line" command. .... Initialisation work (I hear the mechanical shutter) CCD Temperature modification works Start Exposure 2 command works But Readout line fails... The driver reports an error = CE_RX_TIMEOUT I wonder if all this comes from the presence of two USB cameras and that the drivers mixes thoses. Because when I plug the old camera in everything works.... I hope you can help me one this one. Bests, Gael
Receive timeouts often indicate a communications problem, which can be hardware related. Are you operating the camera via a USB hub? That sometimes causes problems. Try a different USB cable, or root hub on the PC.
Have you updated your drivers? The ST-8300M is an old model, so you are probably running old drivers.
As Doug mentioned, CE_RX_TIMEOUT codes are common symptoms of firmware, driver, and hardware bugs. Can you provide us with the firmware version your STF-8300 is running (found from SBIG Driver Checker 64's Firmware tab), as well as the version of SBIGUDrv? We've released several fixes to the STF line of cameras in the last few months, and we'd like to make sure you're up to date.
Hi, Just to be clear. The ST-8300M is working and the STF-8300M is not. Here are the installed drivers: Thanks for the help. Gael
I just updated to sbigudrv.dll 4.88 build 4 but nothing changes. same problem. I don't know if you have labview or if you now labview, but I could share the software and you could have a look on whats wrong... I guess it's maybe in the initialization of the camera that something is wrong. Cheers, Gael
With that update, you should be current with your Driver and Firmware versions. Are you trying to read out both cameras out at the same time? That's the only way I can see having two cameras interfere with each other. As Jan mentioned earlier, the order of initialization is: open driver, open device, then call requested "get/set" functions, [OPERATIONS HERE], close device, close driver. We don't have a license of LabView, and we don't typically provide support for user scripts beyond ensuring the API is functioning as expected. That said, if the software source you've written is human-readable, then we would be better able to understand what's going on at your end. Another way we can get a better idea of what's going on is to turn on Driver logging (from SBIG Driver Checker 64), and to capture the error in a log for us to examine.
Hi Adam, Here is the log file. I do not really understand something which is written in the universal driver application note and this might be the problem... "The Start Readout command does discard top lines from the CCD. You do not need to call Dump Lines prior to calls to Readout Line after using the Start Readout Command." Here is a link to the log file generated when the error is appearing: On line 1256 it becomes interesting... https://drive.switch.ch/public.php?service=files&t=ede9e5ab744690412ac102ec73bbe36e
Basically speaking: the SBIGUDrv API has a specific order of operations for reading out images. After you end an exposure, you need to read out each line of the camera individually. If you're only interested in reading out a small subframe, you need to flush the lines you don't want to use, by calling CC_DUMP_LINES before and after you call CC_READOUT_LINE for each line you do want to read out. CC_START_READOUT takes care of that initial CC_DUMP_LINES call, and so the following two calls would be equivalent: CC_START_READOUT (Lines 30 - 50) CC_READOUT_LINE (Line 30) CC_READOUT_LINE (Line 31) ... CC_READOUT_LINE (Line 50) CC_END_READOUT (Flushes the remaining lines) and CC_DUMP_LINES (Lines 0 - 29) CC_READOUT_LINE (Line 30) ... CC_READOUT_LINE (Line 50) CC_END_READOUT (Flushes the remaining lines.) However, calling: CC_START_READOUT (Lines 30-50) CC_DUMP_LINES (Lines 0 - 29) ... Would be redundant, and is not advised. Since you're not doing that, you don't need to worry. I'm doing some investigation into the cause of your Rx timeout error. I'll let you know when I've got some results.
Hi Adam, Thanks a lot for this explication. If looking at the log file here: At t = 9.407: MicroCommand : MC_READOUT -> RS subcommand: RS_WRITE_AD At t = 9.408: Params: reg = 32, data = 53 At t = 9.408: ReadComPipe : Ask/Got = 2/2 -> ACK At t = 9.409: data : 06, 00 At t = 9.409: MicroCommand : MC_READOUT -> RS subcommand: RS_DL_SETUP3 At t = 9.410: ccd = 0, HB = 1, VB = 1 At t = 9.410: top = 31, height = 0, bottom = 2543 At t = 9.411: left = 28, width = 0, right = 3415 At t = 9.412: ReadComPipe : Ask/Got = 2/2 -> ACK At t = 9.412: data : 06, 00 At t = 9.412: STFDownloadReadoutParams->STF-8300->RSP3: At t = 9.413: ccd = 0, horzBin = 1, vertBin = 1 At t = 9.413: top = 31, height = 0, bottom = 2543 At t = 9.414: left = 28, width = 0, right = 3415 At t = 9.414: MicroCommand : MC_START_EXPOSURE, exposureTime=1 At t = 9.415: MC_START_EXPOSURE Flags : 0x04: msExp=0, extCCD=0, triggerOut=0, ccd=0, shutter=Closed, ABG=Off At t = 9.515: ReadComPipe : Ask/Got = 2/2 -> ACK At t = 9.515: data : 06, 00 At t = 9.516: MicroCommand : MC_STATUS At t = 9.517: ReadComPipe : Ask/Got = 6/6, -> MC = MC_STATUS At t = 9.517: data : A5, 93, A1, 01, 02, 80 At t = 9.518: CC_START_EXPOSURE2 : end, err = 00 - No Error At t = 9.519: ========================= At t = 9.519: CC_QUERY_COMMAND_STATUS : begin At t = 9.520: MicroCommand : MC_STATUS At t = 9.520: ReadComPipe : Ask/Got = 6/6, -> MC = MC_STATUS At t = 9.521: data : A5, 93, A1, 01, 02, 80 At t = 9.521: CC_QUERY_COMMAND_STATUS : end, err = 00 - No Error At t = 9.525: ========================= At t = 9.525: CC_QUERY_COMMAND_STATUS : begin ... Why is not top=0 and bottom= 2506 ??? Because I'm not passing these number to the driver in my code...
That's more than likely an overscan region of the chip that we use for bias offset calculations. It's pretty standard to not have the whole CCD sensor be an active sensing area.
