QHY Camera seems to capture asynchronously

[je-lamiaud]

I'm using PHD2 (2.6.11dev4) on MacOS 12 with a QHY5III178 guide camera ("QHY Camera" in the selector). While investigating guiding on a lousy mount, I stumbled upon something strange. The debug log shows:

21:34:04.452 00.966 123145499979776 Exposure complete ... 21:34:04.785 00.306 123145499979776 move complete, result=0 ... 21:34:04.786 00.000 123145499979776 Handling exposure in thread, d=1000 o=3 r=(1758,883,101,101) 21:34:05.451 00.665 123145499979776 Exposure complete ... 21:34:05.779 00.301 123145499979776 move complete, result=0 ... 21:34:05.780 00.000 123145499979776 Handling exposure in thread, d=1000 o=3 r=(1758,883,101,101) 21:34:06.454 00.674 123145499979776 Exposure complete ... 21:34:06.587 00.106 123145499979776 move complete, result=0 ... 21:34:06.587 00.000 123145499979776 Handling exposure in thread, d=1000 o=3 r=(1758,883,101,101) 21:34:07.450 00.863 123145499979776 Exposure complete ... 21:34:07.682 00.205 123145499979776 move complete, result=0 ... 21:34:07.683 00.000 123145499979776 Handling exposure in thread, d=1000 o=3 r=(1758,883,101,101) 21:34:08.450 00.767 123145499979776 Exposure complete ... 21:34:09.379 00.901 123145499979776 move complete, result=0 ... 21:34:09.379 00.000 123145499979776 Handling exposure in thread, d=1000 o=3 r=(1758,883,101,101) 21:34:09.450 00.071 123145499979776 Exposure complete

Whatever the time spent guiding the mount, the exposure ends 1000 ms (exposure time) after the previous exposure, not 1000 ms after the "Handling exposure" log which is supposed to start it.

I have corrections overshoot leading to oscillation of the guiding, which can be caused by a non synchronous capture from the camera.

Unfortunately, I have no longer my mount and guide cam available for some further investigation. This will have to wait for two weeks. Does the QHY Camera exhibit the same behaviour on other OSes ?

[je-lamiaud]

I had a look at the INDIGO indigo_ccd_qhy2 driver, which is not exhibiting this discrepancy in timings. There are some obvious differences with cam_qhy.cpp :

• After calling ExpQHYCCDSingleFrame the INDIGO driver starts a timer for the duration of the exposure. This may imply that this call does return before exposure end.
• Before reading the image data with GetQHYCCDSingleFrame, the INDIGO driver ensures that GetQHYCCDExposureRemaining returns a value under 100.

When I get back my camera, I will try a modified cam_qhy.cpp, with the above modifications, to check if it makes the capture synchronous.

[bwdev01]

I suspect you’re chasing smoke here. There are hundreds of users with QHY guide cameras who don’t have problems. It looks to me like there is a forced 200ms delay imposed after the return of the call to ExpQHYCCDSingleFrame, are you taking that into account? If you have become convinced that your guiding problems are being caused by some kind of corrupted guide camera frames, you should enable diagnostic image logging in PHD2 and capture as many guide cam images as you want. You can pull them into an image display app, blink them, and see what happens. Even better, you could submit your guide logs and let us look at what’s wrong.

Bruce

From: je-lamiaud @.> Sent: Thursday, March 23, 2023 8:29 AM To: OpenPHDGuiding/phd2 @.> Cc: Subscribed @.***> Subject: Re: [OpenPHDGuiding/phd2] QHY Camera seems to capture asynchronously (Issue #1050)

I had a look at the INDIGO indigo_ccd_qhy2 driver, which is not exhibiting this discrepancy in timings. There are some obvious differences with cam_qhy.cpp :

• After calling ExpQHYCCDSingleFrame the INDIGO driver starts a timer for the duration of the exposure. This may imply that this call does return before exposure end.
• Before reading the image data with GetQHYCCDSingleFrame, the INDIGO driver ensures that GetQHYCCDExposureRemaining returns a value under 100.

When I get back my camera, I will try a modified cam_qhy.cpp, with the above modifications, to check if it makes the capture synchronous.

— Reply to this email directly, view it on GitHub https://github.com/OpenPHDGuiding/phd2/issues/1050#issuecomment-1481403313 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDHSVZ4IONNI6NCWLP3ILDW5RT4XANCNFSM6AAAAAAWFKPMFA . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/ADDHSV4JQ5T3XHPU6HKOO5DW5RT4XA5CNFSM6AAAAAAWFKPMFCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSYJRV3C.gif Message ID: @. @.> >

[je-lamiaud]

Well the debug log is quite self explantory; the capture is not synchronous. I had read that PHD2 was based on synchronous capture and move.

I now got back my camera and mount. I experimented a bit before finding out how to make the QHY camera capture synchronous. The RMS RA error is cut in half when compared to the asynchronous version, which now makes the mount usable for long exposures. I can only speak for the camera model and OS I'm using. Since you made it clear you're not interested, I will resort to using my own patched version.

Sorry for the inconvenience, I will not bother you anymore.

[agalasso]

@je-lamiaud let's not be hasty here, we are interested in your findings! Could you please share your modifications? One good way to do that would be to fork the repo in github, then open a PR (or Draft PR) using your fork.

[MasterPIC]

@agalasso He already applied the require changes on his fork.