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.