I have been evaluating Voyager on a friends equipment, and his camera (A QSI 6162) appears to be a little on the fussy side, occasionally the camera will start throwing exposure errors (A generic error first time and after that “Camera not idle”) The only way to recover it is to disconnect the setup, power cycle the camera and reconnect the setup.
I am sure I could manage it with a dragscript, Viking and a relay board to remotely power cycle the camera, but all sequence errors would result in the same action as far as I can see.
Would it be possible to have a dragscript block for “If expose error” to be able to manage a problem like the camera hangup explicitly, instead of the generic “If Error” which would react in the same way to a passing cloud interrupting guiding as to a camera problem.
i’ve a friend using this camera with Voyager. The first versions of firmware have this problem but they have fixed in the last. Was a problem on a temperature management (just try without cooling to check). Try to reach the QSI support.
About your request, you can manage the sequence specific error using the DragScript Environment Variables:
Fantastic info thanks Leonardo, firstly I will delve into better error management, but knowing that the cameras had a firmware issue (This would be a very early build 6162) I will try to get on to QSI and see if they can help out with a firmware update before Christmas or at least confirm what the current version is to make sure this camera has an old version on it.
It would be nice for it to have a simple resolution, it has been frustrating my friend for some time. I have had more success in two weeks managing isolating his problems and managing his camera with Voyager than he has had in months with another package.
I thought I would add some information here in case it is useful to someone else.
I have not had time yet to implement different management strategies for different errors (I started looking at that in depth last night) but we finally made progress on tracking this issue down. It appears to be related to changing to or from an ROI.
It has taken some time to establish that there was a pattern but I realised two nights ago that the camera always failed after a focus run, normally on the first plate solve exposure after slewing back to target. A couple of experiments showed that high speed/high quality download mode made no difference, and neither did binning level, that left the ROI used for focus downloads in V curve mode. I changed him from V curve to Localfield focus and the camera has performed flawlessly since. Previously it was throwing errors every night, often more than once.
Next steps are some bench tests using a dragscript to take multiple test exposures at full frame, followed by more with an ROI set, followed by going back to full frame exposures. If I can repeatably break it that way we finally have something solid to discuss with QSI for a fix.
It is good to finally spot the common factor in all the times the camera has given trouble. It is obviously not a common problem (Perhaps like one of the ZWO issues last year where only some ASI2600’s would produce a corrupt first full frame image after an ROI was used, this might not even happen to all 6162 cameras)
Now I am just tyring to prove repeatability of the issue with logs to send to QSI/Atik so they can bench test for themselves and hopefully fix it.