v2.6.13dev5 (Garage Lamiaud's fork)

[je-lamiaud]

PHD2 Experimental fork up to date with the original PHD2 v2.6.13dev5
Additional features are:

• Fix for synchronous image capture on QHY cameras
• Simultaneous dual axis guiding (when the mount allows it)
• EQTrack scope support
• Fix of polar drift hemisphere setting, when using the "Ask coordinates" mount
• Fix of a crash in INDI mount and guider
• Fix INDI scope and guider connection issues
• Fix issues with simultaneous use of INDI mount and guider

---

This discussion was created from the release v2.6.13dev5 (Garage Lamiaud's fork).

[MasterPIC]

Hi Jean-Etienne,

I see you're keeping the source updated.
I don't know if recent updates by Dale about QHY solve the async image capture issues or if they still need your source changes.
Anyway simultaneous dual axis guiding is still missing in original fork.

Please feel free to let me know when your source is ready for a new release.
I'll upload new W32 builds on your request...

Thanks again
Armando Beneduce

[je-lamiaud]

Hello. When analyzing guiding issues with a low end mount, I've discovered in the logs that the exposures of my QHY5III178, using PHD2 "QHY Camera", were not scheduled between guiding actions on the mount, but instead "back to back". I.e, the delay between the call to ExpQHYCCDSingleFrame and the return from GetQHYCCDSingleFrame, where the exposure is supposed to take place, was anything from some milliseconds to the intended exposure duration, while the delay from each GetQHYCCDSingleFrame was quite accurately the exposure duration (or an integer multiple of it).
As the exposure is meant to be synchronous between the guiding actions, this is obviously a wrong behaviour. But when I opened an issue on the subject, it was simply dismissed (I wouldn't say kindly 😉). I therefore dug into PHD2 code, and performed some experiment, with the help of some other QHY related code, such as Indigo.
It turns out that the fix is extremely easy : the call to SetQHYCCDParam(m_camhandle, CONTROL_EXPOSURE, duration * 1000.0) in Capture needs to be done before each exposure. By removing the test for a change in exposure value, the exposure now correctly spans its intended time slot.
By the way the guiding statistics of my mount was greatly improved; in particular, the oscillations did disappear.
As there was no interest on this subject, I kept it in my fork.

Maybe you could test with your cameras if you see the same behaviour. I observed it only with my QHY5III178 on macOS, and later also on Linux.

Armando was interested in simultaneous guiding on RA and Dec. An idea which I independently also came upon, and implemented in my fork. This further improved the guiding on my mount, to a point which I now find quite satisfying.
As Armando's suggestion was also dismissed by PHD2 team, we worked together to implement the simultaneous guiding in the ASCOM mount.

Now, please forgive me for being blunt: I don't mind not being credited for any of the fixes I've made, but I don't have time to enter into a lengthy discussion if the team is reluctant to them.

[daleghent]

Hello Jean-Etienne, thanks for this background information. I have not observed this exact effect myself, but I do not doubt that what you have observed is true given what I know about the QHY SDK. I created the QHY native driver in NINA and I know that exposure timing has always been a peculiar thing with QHY cameras.

All the same, it makes no difference in the grand scheme of things whether the exposure duration is set occasionally or set prior to each exposure, so I made that change in my code and ask that if you or @MasterPIC could test it. I am not currently set up to test under an actual real guiding scenario. My improvements to the QHY native driver in PHD2 stem from my preparation to use a QHY5III-174M on a new system I am installing at a remote site in two weeks, so it will be some time before I get around to being in the position of testing it.

You can get a test phd2.exe with this change here:
https://daleghent.com/misc/phd2/PHD2-QHY5.zip

Since you have a QHY5III-178, do you also get the "High gain mode" option in the new settings window? The control for this option should be returned for QHY178 cameras, but I have had some reports from other testers with 178 cameras that they do not see it. Attaching the PHD2 Debug log would be helpful there.

Thank you for any help. If this change in the exposure setting works, then we can make your discovery available for everyone.

[MasterPIC]

Hi Dale,

unfortunately I had no opportunity to test your latest build and weather doesn't help.

I agree with you about the usefulness of this change that could be made available to the entire community.
Sharing the simultaneous guiding could be considered too: I see no reason why all these improvements should not be included in the official repository/fork.

Clear Skies
Armando

[je-lamiaud]

As I said, I'm using macOS and Linux. I was able to copy the exe to a PC into a portable version of PHD2 that Armando had prepared. PHD2 starts fine, but it does not detect my QHY cam. I suppose that I should install some QHY driver in Windows first, but unfortunately, not being admin I can't.
I had a look at the source code change in your repository. It is exactly what fixed the problem for me in macOS and Linux. As the problem looks like it originates in the camera firmware, it is probably identical in Windows.

[je-lamiaud]

And for the other topic, indeed, the "High gain mode" does not appear. Yo can see the panel below.
I also attached the debug log.

Clear skies
Jean-Etienne

PHD2_DebugLog_2024-11-20_122639.txt.zip