I am using a Lodestar X2 for guiding. I have “pause guiding during image download” checked. I get a “Pause guiding during image download … camera does not support this feature” warning screen:
I’m surprised that the X2 would not be supported. Is this a pulse guide vs ST4 thing (I’m using ST4)? Or perhaps I’ve totally missed the boat on something here? (always an option!). I’m using PHD2 ver 2.6.2 Dev4.
DaveNL
I don’t know the answer to your specific question, but why not go with
pulse guiding and ditch the ST4? Give it a try at least and see what
happens. I dropped the ST4 cable with my Lodestar years ago.
I’ll make this a bit more clear in the warning, but the reason you are seeing this is because SGPro is not able to determine your imaging CCD (not your guider) is definitively downloading. Technically, the ASCOM interface does provide us with this info, but we have had some problems using it to support features like this because of differing manufacturer implementations. I suppose we should just go ahead and use it at this point…
Hi @Ken,
Thanks for the clarification. So this works for some imaging cameras but not others? My imaging camera is an Atik 460EX. I guess I’ll just uncheck the “pause guiding during download” for now.
Dave
In 2.5.2.6, it works for SBIG, FLI Canon and Nikon cameras. In 2.5.2.7, I have a (not super well tested) implementation of this for ASCOM and QSI cameras (QSI should be pretty safe, but there might be some variance in other ASCOM cameras).
@Ken how are you using ASCOM to determine that the camera is downloading? Looking for CameraState to report downloading I guess.
I’m a bit puzzled because AFAIK this is implemented in the Atik camera driver.
Chris
I get the same with my SX guider camera - in PHD2, are you using the ASCOM driver or PHD2’s own SX driver. I ditched the ASCOM driver after reliability issues. The PHD2 driver seems better behaved.
This is true.
Sorry, puzzled by what? Maybe my cryptic comment about ASCOM driver variance? If that’s it, I only mean to convey that we cannot guarantee that authors implement this state. If it works for Atik, that’s great (I don’t have one so I can’t test).
Puzzled because @dnube said he was using an Atik 460EX so reading the camera state should be OK.
Not sure how long this takes for download, do you show the message if the state is not downloading when you expect it to be?
For me, this message comes up as soon as I start the sequence.
I have just noticed that there is a newer driver for the Atik 460 which I have downloaded and installed. Will test at earliest opportunity - possibly tonight or tomorrow night.
If it is actually working, how will I know (besides not seeing the initial warning message)? Will there be evidence in the log? I guess PHD2 will flash a “PAUSE GUIDING” message?
DaveNL
The latest versions of PHD2 (v2.6.2dev4 and newer) indicate when PHD2 has been paused by SGP:
Earlier versions won’t show that, but you’ll notice it stop looping exposures.
Andy
Really puzzled again. CameraState will only return the downloading state at the end of an exposure, before ImageReady is true, while the camera driver is downloading the image data from the camera CCD to the PC. This isn’t happening at the start of a sequence.
Chris
Maybe because none of the code I referred to exists yet? Not sure. Right now SGPro, in 2.5.2.6 does not support Pause PHD2 during image download for ASCOM, thus the message @dnube sees is received when the sequence is validated (at sequence start) and sees that the option is checked, but the camera is not supporting it. In 2.5.2.7, ASCOM cameras (in SGPro) now report that they do support this.
I think I’m getting there.
The reason for the pause during image download is that the USB bus will be busy during the image transfer - by USB - from the camera to the PC.
The camera MUST read the data from the sensor to somewhere where it isn’t affected by dark current as soon as the exposure has finished. In many cameras this is done by reading the data from the CCD and sending it to the PC. This must be done at the end of the exposure and, if supported, the camera should report the Reading state.
Once the image is in the PC memory - handled by the camera driver - the transfer that’s done in the camera.ImageArray() call is internal and the USB bus is not used.
In this case guiding should be paused when an exposure has started but has not finished and the camera state is Reading.
The exception is for a camera has a memory buffer in its hardware that can hold a full image AND does not transfer the data in this buffer to the PC until the camera.imageArray() call. In that case the USB transfer is done in ImageArray, not just before ImageReady goes true.
It seems to me that pausing during image download could be implemented in two places:
While waiting for an exposure to finish (ImageReady -> true) when CameraState is Reading or CameraDownload. (Some drivers will probably return CameraDownload at this point)
Just before calling ImageArray until it returns. ImageArray blocks until the image is ready. In theory a check for CameraDownload could be called in another task but there doesn’t seem to be any harm in pausing guiding anyway, you definitely aren’t imaging, and not checking the state avoids the complications of multiple threads calling the camera driver.
If pause hasn’t been implemented in SGP then the message seems a little misleading and it should say that SGP hasn’t implemented pause rather than saying that the camera doesn’t implement it. Blaming the camera gives the impression that the camera needs to do something.
Chris
All valid points.
Pause is implemented in SGPro, just nor for ASCOM cameras. I have never blamed this on ASCOM only that SGPro does not support it for our implementation of ASCOM. I suppose we could get nit picky with the verbiage, but there is not much point now that it has been implemented.