QHY Camera owners: testers needed for updated QHY camera support in PHD2

[Andy Galasso]

We have been working for several months with the developers at QHY to integrate a new version of the QHY camera libraries into PHD2. Before adding the new libraries into an official build of PHD2 we need help testing out the new code.

The new libraries from QHY have a number of improvements including:

  - support of most (if not all) QHY cameras,

  - subframe support,

  - binning support

We currently only have a Windows build as we are waiting for QHY to deliver OSX and Linux versions of the latest camera libraries.

If you have a QHY camera, it would be great if you could help us out by installing this build of PHD2: http://openphdguiding.org/phd2-2.5.0dev5qhytest1.exe

After installing the test version, select "QHY 5-II" for the camera even if your camera is not a QHY5-II.

We would appreciate hearing if the new code works for you. If you see any problems, please let us know and post a link to your PHD2 debug log.

Andy

[RaSu Leeson]

Hi Andy, I will try it, I use the QHY5L-II, imaging right now so loathe to upset things but if I get chance I'll try it tomorrow night.

Ray

[peter wolsley]

Andy,

Program crashes...

My guider cam is a QHY5-II-M.  I downloaded the latest drivers from the QHY site and install your test build.  When I select QHY5-II I notice I cannot access the set-up window for the camera.  When I click on "connect"... PHD2 crashes.  I tried again and first tried the ASCOM flavor of the QHY5II.  This choice does not crash...I did not try to guide with the ASCOM version.  I disconnected and then attempted to connect to the QHY5II choice.  Immediately PHD2 crashes.  I attached the debug logs.

Peter

[Robert Kimball]

Hello Andy,

Thank you for all your hard work on PHD2. 

I have a new QHY5l-ll guide camera.    I just tried the version linked above "phd2-2.5.0dev5qhytest1.exe"  and for the first time my camera and PHD2 played nicely together.

Let me explain the problems I was having:

I am an Apple OS user, but my main camera is and Atik 383L and I use the Atik capture software Artemis.  Since Artemis is only available in a Windows version, I am running Windows 8.1 under Parallels.  Therefore, I am also using the Windows version of PHD2.

I downloaded ASCOM and the QHY5L-ll driver. I had no difficulty connecting the camera and my Mach 1 mount to PHD2.  Unfortunately, the camera periodically "timed-out"   If I set the capture time at 1 sec. PHD would work quite a while.  The higher I set the capture time, the sooner it would time out.  Capturing at 5 sec. intervals caused a "time-out" in 2-3 minutes.  I use the Windows systems monitor to watch what was happening. I could see the CPU graph "pulse" every time the capture occurred.  They were not evenly spaced.  the longer PHD2 ran the more time there was between captures until the maximum of 15 sec. occurred.  I attributed the problems to the fact that I was running Window with Parallels,

Then I visited this forum to ask if anyone was using a system similar to mine, and I saw your post.  I downloaded "phd2-2.5.0dev5qhytest1.exe" and gave it a try.  It worked perfectly.  Looking at the CPU monitor I could see that the capture was happening at regular intervals.  Note again, I'm connecting to the camera via ASCOM.

So thank you so much for getting this working.

Bob

P.S. I really like the new action icons you've added. When I'm out at star parties, I use "RedScreen" and anything red on the screen pretty much disappears.  Thus the Stop Sign and the Brain all but disappear.  You might change these colors.

[Robert Kimball]

Andy,

I may have responded too soon.  I tried connecting to the camera directly, not through ASCOM, and it didn't work.  Then I went back to the ASCOM connection and it failed.  I shut everything down and finally got it working again. 

I've attached a screenshot of the CPU graph.  This was at 2.5 sec. per capture.  I guess the computation time may explain the irregular CPU usage?

[Andy Galasso]

Bob,

Thanks for testing it.  Just to be clear, the changes we are looking to test are unrelated to the ASCOM driver.  If you connect to the camera via ASCOM, it goes through the common ASCOM camera code in PHD2 (which has not changed), and then uses the QHY ASCOM camera driver (which we have no control over and presumably also has not changed.)  So any differences you see are unrelated to the QHY camera changes in PHD2.

If you have a chance, it would be great if you could connect the camera as "QHY 5-II" (even though your camera is not a QHY 5-II; and *not* through ASCOM.)   If you see any problem, please post your PHD2 debug log.

Thanks for your help!

Andy

[Robert Kimball]

Andy

 

I tried every combination (different USB cables, different connection sequences, different selection sequences) I could think of and failed.   The QHY5L-II mono will not run directly of indirectly (ASCOM) with PHD2.  

Strangely, the QHY5L-II seems to work with the original PHD.  Did it work with PHD2 Ver. 2.3?

Thanks again for working on this.

Bob

[Andy Galasso]

Bob,

The QHY5L-II works already with all versions of PHD2 using an older camera library from QHY. Select QHY 5L-II (Color or Mono) as the camera and connect.

The purpose of this new test build is that we are trying to evaluate the new libraries we got from QHY. The new libraries provide the benefits I listed in the OP. If the new libraries are stable we will replace the old libraries.  Sorry for the confusion. Does that make sense now?

Andy

[Paul Peacock]

Hi Andy
I had a chance to try the new QHY build tonight. I'm using a QHY5L-II on a QSI-683 OAG. I only played around for a bit with it, but here's what I found:

• Connects fine, no disconnects
• Binning 2x2 works - needs a separate profile and bad pixel map of course
  
• Sub-frames is broken. Sometimes the sub-frame initially seems to offset the star to the edge of the sub-frame and the lose it, and sometimes it just shows a diagonal noise pattern. I tried it binned 1x1 and 2x2, and with different sized search regions but none worked. I wonder if the star position in the frame affects the degree of shear? I turned image logging on so we should be able to tell.
  

I will post the logs tomorrow (sorry I can't tonight). I'm not familiar with Google Groups - can I attach the logs to a post or do I need to put them on Dropbox?

Thanks!
Paul
  

[Andy Galasso]

Thanks Paul, that is very helpful.  A dropbox or google drive link is best.  The group accepts attachments but I do not know what the size limit is.

Andy

[Paul Peacock]

Here are all the logs from last night - raw and uncut! I was setting up last night so there's about an hour's worth of drift alignment among other things. I was also having some (user settings...) issues with SGP so I did a re-start as well. Toward the end of the night I just went back to 1x1 full-frame to figure out my SGP issues and take a light frame. Let me know if I can do anything else to help.

https://drive.google.com/folderview?id=0B54Axc56orbZWTk0QjhDMlQ5eHc&usp=sharing

Thanks!

Paul 

[Andy Galasso]

Paul, Thanks for the report. I was able to reproduce the subframe problem with my camera. I'll investigate and work it out with QHY.

Andy

[RaSu Leeson]

Re:qhy-5 test...I had a very short opportunity last night to connect and try the binning and gain adjustments.. Seemed to operate o.k.
Unfortunately no chance to guide sogged in with cloud for the last week or so and no clear for the foreseeable week..

However just for clarity; what's the benefit of the binning with respect to the qhy5l-ii

Ray

[Andy Galasso]

Ray,

Thanks for trying it.

Binning can be useful when the guide image is highly over-sampled. This is sometimes the case for example with an OAG. If your focal length with an OAG is 2500mm you would be sampling 0.3 arc-sec/pixel with a QHY5L-II. In that case you could select binning 2 to get ~ 0.6 "/px which is more reasonable and reduces the data downloaded from the camera by a factor of 4.

Andy

[RaSu Leeson]

Another opportunity to test briefly, I can confirm that the sub frame function is broken as above post but all other function worked o.k

Ray

[Andy Galasso]

Thanks Ray.

Here's a version that fixes the subframes problem AFAICT. Maybe you and Paul could give it a try?

http://openphdguiding.org/phd2-2.5.0dev5qhytest3-installer.exe

We are still waiting to get a OSX and Linux versions of the latest SDK from QHY, so it's just Windows for now.

Andy

[Paul Peacock]

Hi Andy

I had a super short chance to try the qhytest3 build. The clouds rolled in pretty quick but I managed to calibrate and mess around. Here's what I found:

• Subframes now work!
• Binning seems to work, but with minor issues:
• The binning selection is not always there in the brain settings? I couldn't tell if it's just until the camera is connected or random. This leads to confusion about the next issue:
• PHD complains about the bad pixel map not matching. I'm not sure if it's because it captured a 1x1 map, or it doesn't generate a 2x2 map, but there were many hot pixels visible after applying the generated bad pixel map. I generated a dark library and that seemed to work better.

That's about as far as I got. Here's a link to the logs:
 
https://drive.google.com/folderview?id=0B54Axc56orbZZXQ5RHBWd1pSUVE&usp=sharing

Thanks again!
Paul

[Andy Galasso]

Hi Paul,

Thanks for testing it.

I was able to reproduce the problem with the missing binning in the brain, added #474 to the issue tracker.   For now you can workaround the issue by connecting to the camera first before opening the brain.

Both darks and bad-pixel maps should work as long as binning does not change, but if the binning changes the darks and bad-pixel maps are incompatible and need to be rebuilt. PHD2 cannot automatically apply a 1x1 bad-pixel map to a 2x2 frame and vice-versa. For that reason it makes sense to have a separate profile for each binning setting if you are going to be changing back and forth between them. Otherwise you would need to rebuild the dark lib or bad-pixel map each time you switched.

There was a bug reported earlier -- #471 -- about the newly-generated bad-pixel map being incorrectly rejected as incompatible after a binning change.   I think we are still looking for the exact steps to reproduce it.

Andy

[Stephen M. Brincat]

Hello,

I had upgraded to Version 2.5.0 to use with my QHY5-II-M however I encountered a problem that was not readily apparent. Despite that the image from the autoguider showed a number of good stars that were bright enough to guide on, I could only guide on the brightest of these as the software was registering the stars as having a low SNR. From previous experience, I knew what kind of stars would be too faint. It seems that the 2.5.0 version decreased the capability of the autoguider to guide on faint stars. 

I installed  2.5.0 dev7 with the hope that the problem would be solved but to no avail. Last night, I encountered the same problem with stars through the 80mm guidescope registered as too faint. To overcome this, I had to increase the exposure to 7 seconds to obtain a value above the 3 SNR threshold. As a test, I downloaded version 2.4.1 and tried to guide on the same field. I discovered that through the latter, I can guide on much fainter stars than any of the latest version even if I reduced the exposure time to 1.5 seconds.

Can you please look into this. 

Regards,

Stephen

Flarestar Observatory

MPC171 Malta

http://flarestar.weebly.com/

[Andy Galasso]

Hi Stephen,

In this thread we are discussing evaluating a new SDK from QHY.  Your issue with 2.5.0 and 2.5.0dev7 is important to us, but it is unrelated to this thread.  Please start a new thread and be sure to include your PHD2 debug log and a sample fits image (File => save image) showing the star that PHD2 2.4.1 was able to recognize but 2.5.0dev7 was not. Please indicate which star it is in the field; we should be able to figure it out from the debug log, but it would be good to have you confirm it.

Andy

[Brendan Kinch]

Andy.....just a quick reply on this one. I am controlling the obs computer remotely and tonight during some down-time on imaging (due to clouds) I installed the build you wanted testing.

When I went to start PHD2 - I immediately got...

Seems like there is something else that that build is looking for that I don't have.

I went back to 2.5.0dev7 and it started OK (just like before). I am actually using a QHY 5 II for guiding......and back imaging again as I write this. Hope the above screen capture means something to you.....

Regards,

Brendan

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andy Galasso]

QHY provided an updated SDK which fixes the support for the QHY5II and improves performance in general. Please give this one a try:

    http://openphdguiding.org/phd2-2.5.0dev7qhytest4-installer.exe

We currently only have a Windows build as we are waiting for QHY to deliver OSX and Linux versions of the new SDK.

Andy

[Brendan Kinch]

Andy,

I gave this a brief try tonight....

Camera connected fine this time. All worked as expected in Bin 1 and Bin 2....BUT  as soon as I tried to use sub-frame (regardless of bin mode) the camera disconnected. (Would not re-connect unless I unchecked the 'use sub frame' box).

I am using a QHY 5 II.

Regards,

Brendan.

[Andy Galasso]

Brendan,

Thanks for testing it. Could you post the debug log?

Andy

[peter wolsley]

Andy,

I am using PHD2 Guiding 2.5.0dev7qhytest4 and I noticed that there is a HFD: indicator displayed on the Star Profile window.  Can you tell me what HFD stands for?  I will send another update later about my findings using my QHY5II-M.

Peter

On Wednesday, October 14, 2015 at 6:19:49 PM UTC-4, Andy Galasso wrote:

[Andy Galasso]

Peter,

The latest QHY test build picked up some unrelated changes that are in progress in the main code stream.

HFD is "Half Flux Diameter".  It is a metric similar to FWHM for assisting in focusing.  The HFD is more robust than FWHM since it is calculated over the entire 2-dimensional star profile, whereas the FWHM is only calculated along one row or column.

Andy

[Bruce Waddington]

HI Peter.  You can find a fairly succint explanation here as well:  http://www.cyanogen.com/help/maximdl/Half-Flux.htm

 

We wanted to make the switch in order to broaden use of the star profile tool to better support focusing.  The HFD parameter is generally more stable with regard to both seeing and out-of-focus conditions. That's why FocusMax and some other focusing apps use it rather than FWHM.  Normally, the HFD stat will be somewhat higher than what you're probably accustomed to seeing for FWHM.

 

Bruce

 

---

--

[Andy Galasso]

... fastest turnaround time ever from QHY! They gave me a new version of the SDK that fixes the QHY5II camera disconnect.

Please give this new version a try:

http://openphdguiding.org/phd2-2.5.0dev7qhytest5-installer.exe

(still Windows only, OSX and Linux coming soon we hope)

Andy

[Paul Peacock]

Hi Andy
Forecast is for rain until ~Nov 23rd. As soon as I get a weather window I'll do more testing.
Thanks!

[Chuck Kozlowski]

I have installed the supplied driver on my QHY5L-II setup.  I have had a miserable time trying to get the QHY5L-II to work with my setup.  This new update appears to be running pretty good so far - I am 1 hour into my imaging session and the guide camera is working fine so far. 

Chuck Kozlowski

[Chuck Kozlowski]

Well,  as soon as I hit 'send' on this note (see below).  My main image got downloaded and my QHY5L-II timed out during the imager (ATIK 490ex) download.  Since I was watching it, I just reconnected the guide camera (QHY5L-II) and my imaging session continues.  I guess that the USB is getting saturated with the image download and the guide camera is not liking that it has to wait.  Glad to discover this 'issue' and I am glad to see that I was able to reconnect the QHY5L-II with just a button push in PHD2 and not have to walk out to my telescope and disconnect and reconnect the USB (which I was doing with the previous versions of PHD2).

[Bruce Waddington]

What value have you set for the camera timeout value in PHD2?  You might try setting it to a value substantially longer than the time it takes for a full-frame download.  You might also want to look at the USB infrastructure on the system to see if you can better support concurrent activity.  

 

Good luck.

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Chuck Kozlowski
Sent: Friday, November 13, 2015 6:40 PM
To: Open PHD Guiding
Subject: Re: QHY Camera owners: testers needed for updated QHY camera support in PHD2

 

Well,  as soon as I hit 'send' on this note (see below).  My main image got downloaded and my QHY5L-II timed out during the imager (ATIK 490ex) download.  Since I was watching it, I just reconnected the guide camera (QHY5L-II) and my imaging session continues.  I guess that the USB is getting saturated with the image download and the guide camera is not liking that it has to wait.  Glad to discover this 'issue' and I am glad to see that I was able to reconnect the QHY5L-II with just a button push in PHD2 and not have to walk out to my telescope and disconnect and reconnect the USB (which I was doing with the previous versions of PHD2).

--

[Chuck Kozlowski]

My Camera Timeout is set to 30 seconds in PHD2.   At the base of my telescope pedestal:  I am running a powered USB hub (7 port device from Startech.com) which is connected to an Icron Ranger 2304 (USB over ethernet) which runs 200 feet into the comfort of the telescope man-cave.    I have been using this configuration with NO problems when I was using my SSAG (Orion Starshoot Autoguider) and I just wanted to get a more sensitive guider (QHY5L-II) - I guess I can always go back to the SSAG.  The QHY5L-II is such a tease - it is much more sensitive than the SSAG but the way it handles the USB interface is rather disappointing and definitely frustrating. 

[Andy Galasso]

Chuck, thanks for the feedback. I will second the recommendation from Bruce to increase the camera timeout setting.  For purposes of this test it would be good for us to know if the camera is truly hung, or if its just stalled during the download from the main camera. Setting the timeout to a very high value, like, say 120 seconds will help us make that distinction.

Thanks,

Andy

[Matthew Dixon]

Downloaded this new version on 11/10/2015, tested it out all night on the 11th.  Everything worked perfect except that I kept getting my pixel size reset to 5.20.  Eventually I changed after connecting the camera but before looping and saved the correct value of 3.75. 

Also the issue I posted about in another thread where I couldn't get the SNR above 3 with dev7 was gone.  This driver setup worked flawlessly on my Windows 8.1 Acer and the QHY 5LII mono.  Nice fix Andy & QHY!

[Andy Galasso]

Matthew, thanks for the testing and the feedback.  Regarding the camera pixel size, could you please try the following quick experiment with the latest test build (phd2-2.5.0dev7qhytest5-installer.exe):

- Open PHD2

- open the connect equipment window

- select Manage Profiles => New using wizard

- select QHY Camera

- click Detect

Does the pixel size come up as 3.75?  If not, please post your debug log.

Thanks,

Andy

[Chuck Kozlowski]

Andy,

I changed the timeout setting to 120 seconds in PHD2.  I was able to image for about 2 hours and then no joy.  The camera (QHY5L-ii) reported that it had disconnected and then it wouldn't reconnect unless I unplugged the USB plug from the camera (no fun since it is 200 feet away).  The camera kept reporting dropped connections after this so I finally called it a night.  I will send over my PHD2 de-log files tomorrow.

Chuck

[Matthew Dixon]

I can give it a shot tomorrow night when I'm out although the problem has been resolved and PHD now loads up and connects with the correct 3.75.  I just had to manually change it in the correct order:

-Start PHD2

-Connect camera and mount

-Change pixel size in brain icon

-Begin looping

The problem was that I was changing the pixel size before connecting the camera.  When I clicked connect it went back to 5.20.

[Andy Galasso]

Matthew, it sounds like a bug (probably unrelated to the updated QHY support.)  Could you describe the steps you did that did not work so we can try to reproduce it?

Thanks,

Andy

[Chuck Kozlowski]

I have decided to take a little more systematic approach.  I have brought my equipment indoors and I am testing with the following configuraiton:

QHY5L-IIM -> ICRON Ranger 2304 (remote USB hub) -> Ethernet Cable (200 feet) -> ICRON Ranger 2304 (Local USB Hub) -> USB Port -> Dell Computer

I have remove ALL other USB device on the remote USB hub (ICRON Ranger 2304) and will let the QHY5L-IIM run for a few hours before adding a single USB device at a time (focuser, filter wheel, imaging camera - ATIK 490ex).  I am running PHD2 at the moment and this configuration has been running for 20 minutes (so far) without a timeout.  I will then add a single USB device and let the guider camera run and see what transpires.  I have a working theory that the QHYCCD device driver is struggling with a USB contention issue (with other USB devices on the remote hub) and just doesn't recover gracefully.  Appreciate any other bright ideas out there ....

[Chuck Kozlowski]

Well,  it ran for 90 minutes and then the QHY5L-IIM  hung (no error messages - image just stopped updating in PHD2).  I have restarted it. 

[Matthew Dixon]

I can do one better.  I was recording at the time:  https://www.youtube.com/watch?v=R-pLP4fqzrU

[Andy Galasso]

Chuck,

I was able to reproduce this with my QHY5L-II-C. It worked for a couple hours then the camera hung.  I will forward the information to QHY and see if they can fix it.

Andy

[Chuck Kozlowski]

Andy,

I am glad you were able to reproduce the problem that I am having (camera hang).  Let me know if they provide a software update.

Chuck

[Matthew Dixon]

Ran the latest version (test5) all night last night without any issue.  Windows 8.1, QHY plugged into solo USB 3.0 port on left side of Acer laptop.  All other equipment plugged into USB hub on USB 2.0 ports on right side of laptop.

[Andy Galasso]

Matthew,

Great, thanks for the update.

Andy

[SiriusOmegaBeta]

Ran my QHY 5L-II with the qhytest5 release and it worked beautifully. No drop-outs or disconnects after a couple hours testing.   The binning support makes such nice difference to sensitivity, too.

Testing the IMG0H shortly, will let you know how that goes.

[Andy Galasso]

Brett, thanks for the feedback.

Andy

[Paul Peacock]

Hi Andy
I'm posting here because I'm using the v2.50dev7qhytest5 version.
Lately I've been experiencing frequent camera disconnects with my QHY5L-II. If I see it I can just click the 'connect' button and it re-connects no problem. What doesn't happen is an auto-reconnect. I have tried 2.50dev8 and also updated the qhy driver but still have the same problem. I've changed the USB cable twice with no change. I've been running the USB through a powered hub for over a year and this is the first time I've had a problem, but that seems like the most likely culprit so I'll eliminate that next. I am puzzled why the auto-reconnect implementation isn't working though? Here is the debug and guide logs from last night. I left it connected for about 5 hours while i took some darks (I was out), and then started guiding around 2300hrs. The disconnect happened at about 0005hrs.
https://www.dropbox.com/s/1e5zc68xdrmbdw1/PHD2_DebugLog_2015-11-28_164932.txt?dl=0
https://www.dropbox.com/s/0tub1jkxskt3uce/PHD2_GuideLog_2015-11-28_164932.txt?dl=0
Thanks
Paul

[Andy Galasso]

Paul,

Thanks for posting the log. The reconnect code in PHD2 currently only attempts to reconnect after a camera timeout, but not when the camera driver reports a "hard" error like it did in your case. Based on your observation that the camera continues to work fine after the error it sounds like it would make sense for PHD2 to try reconnecting automatically in this specific error case as well.

Here is a new build of phd2 that includes the change to reconnect automatically when this error is encountered.

http://openphdguiding.org/phd2-2.5.0dev8qhytest6-installer.exe

Andy

[Paul Peacock]

Hi Andy
Thanks for the updated version. Had a good run last night where it re-connected a couple of times even before I went to bed, but it kept reconnecting and finished the sequence.

I've posted the debug and guide logs for your reference. Once again, darks until about 2230hrs then imaging after that. The debug log is huge - about 8Mb!
https://drive.google.com/open?id=0B54Axc56orbZNlFSYnJ6SE9CX00
https://drive.google.com/open?id=0B54Axc56orbZemh2cE9wZ2VYdW8

Now I only have to figure out why the camera keeps disconnecting...

Thanks!
Paul

[Sergio Caballero]

I posted this over at CN and was directed here.

I've been using my QHY5L-IIM for OAG for about a year now and have been very happy with it and what it has let me achieve (guiding 1-hour subs). After experiencing time out disconnection issues with the original QHY native driver,  I switched to the Hi-Compatibility driver and connected via ASCOM Camera chooser. But in the last several days I've started having camera timeout and disconnection issues that have pretty much shut down my ability to acquire anything.

 

Imaging computer is a Core i7 64-bit Win7 Home Premium SP1. The timeouts first cropped up after I upgraded SGP from v2.4.2.11 to the latest v2.4.3.22, and at the same time updating PHD2 from v2.5.0 to v2.5.0dev7 as required by that version of SGP (have since updated to dev9 with the same result). There's no regularity to when the timeouts occur; sometimes one will happen within the first few seconds after connecting the camera, other times the camera will go along capturing happily for an hour or more before a timeout occurs. When this happens, I can try to connect again and PHD2 will report a connection, but pressing capture does nothing (no refresh of the capture frame displayed before the timeout). If I disconnect the camera and exit PHD2, the existing PHD2 process persists in the process list and won't force terminate, preventing a new PHD2 instance from loading. I have to do a restart of the computer before PHD2 will load again. Sometimes (but not always) when the QHY5 times out, SGP will lock up. Other times I'll get an ASCOM error, usually for the GPUSB device controlling my focus motor, but on occasion I've also lost connection to my imaging camera (QHY8), and filter wheel.

 

These are the things I've tried so far without resolution. 

 

1. Increasing timeout limit in PHD2 to 60 seconds

2. Swap out the USB cable.

3. Plug the QHY5 into its own port on the computer; first I used the USB3 port it normally went thru via the powered hub, then I also tried a USB2 port.

4. Only the QHY5 plugged in to either USB3 or USB2 and running only PHD2.

5. Same as above, but connecting PHD2 via the QHY5 driver instead of through the ASCOM Camera Chooser (the latter way I'd always done it successfully).

6. Uninstalling the QHY5 drivers (v1.4.12.12,  v1.4.04.23 Hi-Compatibility, and ASCOM v11) and updating to v1.5.10.28 and re-installing ASCOM v11.

7. Connecting via either the updated QHY5 driver or the ASCOM camera chooser.

8. Downgrading by uninstalling all QHY5 drivers, uninstalling SGP, uninstalling PHD2, cleaning the registry with CrapCleaner, installing my original QHY5 drivers, installing SGP v2.4.2.11, and installing PHD v.2.5.0

 

At that point I pretty much concluded it was a hardware issue with the camera itself. But then I installed the original camera drivers and PHD2 v2.5.0 on another laptop I have (Core i5 recently upgraded to 64-bit Win10 from Win7), connected via the ASCOM camera chooser, and ran a 2sec capture while I slept overnight. After 9 straight hours of running 2sec caps there were no timeouts. So now I'm not sure it's a camera hardware issue. 

The fact that I didn't see any timeouts on the Win10 laptop with a clean install of the original working configuration makes me think there may be some persistent registry setting of common code that doesn't get uninstalled from the most recent diver and PHD2 dev build, and persists over a reinstall of older versions.

I'll install and try out this test build and report back with logs.

On Wednesday, October 14, 2015 at 6:19:49 PM UTC-4, Andy Galasso wrote:

We have been working for several months with the developers at QHY to integrate a new version of the QHY camera libraries into PHD2. Before adding the new libraries into an official build of PHD2 we need help testing out the new code.

The new libraries from QHY have a number of improvements including:

  - support of most (if not all) QHY cameras,

  - subframe support,

  - binning support

We currently only have a Windows build as we are waiting for QHY to deliver OSX and Linux versions of the latest camera libraries.

If you have a QHY camera, it would be great if you could help us out by installing this build of PHD2: http://openphdguiding.org/phd2-2.5.0dev5qhytest1.exe

After installing the test version, select "QHY 5-II" for the camera even if your camera is not a QHY5-II.

We would appreciate hearing if the new code works for you. If you see any problems, please let us know and post a link to your PHD2 debug log.

Andy

[bw_msgboard]

Sorry you’re having these problems.  These really sound like low-level USB problems, nothing to do with the higher-level apps like PHD2 or SGP.  The big difference between the system that works and the system that doesn’t – different systems. J  As far as PHD2 goes, the only thing that’s in the registry is your app settings, primarily the parameters in the brain dialog – nothing to do with the actual device interface.  Is it possible that the powered hub has failed?  I know you tried a direct connection to a USB port, but that might have led you into problems with power being supplied to the camera.  The QHY cameras seem to be very demanding of USB resources, including both power and bandwidth, so it apparently doesn’t take much to tip things into failure mode.  

 

By all means, try the latest test build and let us know what happens.

 

Good luck,

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Sergio Caballero
Sent: Sunday, December 13, 2015 10:49 AM
To: Open PHD Guiding
Subject: Re: QHY Camera owners: testers needed for updated QHY camera support in PHD2

 

I posted this over at CN and was directed here.

--

[Sergio Caballero]

Thanks Bruce. I uninstalled QHY5 drivers as well as PHD2 v2.5.0, then installed the QHY5 v151028 driver followed by dev7qhytest5. Camera was detected upon plugin and 2 drivers installed. Upon launch PHD went through the profile wizard. I connected via the ASCOM Camera Chooser, built a dark library, and set a 2sec capture loop that ran for 3 hours without a hitch. I won't bother posting that log unless asked since it worked fine.

I then disconnected the camera and closed PHD, launched it again, and used the profile wizard to create a connection via the native QHY5II driver. It took a while to query the camera and return the pixel size, but then it finally connected. It went into dark library creation where it hung and became unresponsive, without having transferred a single frame according to the progress bar. After 25 minutes of no response I  tried closing, got the no response message in the window title bar, and had to kill the process with task manager under the applications tab. Both windows (main program and dark library creation wizard) closed. I then checked under the Processes tab and phd2.exe was still in the process list. Trying to kill that did nothing (persisted in process list), and trying to launch a new instance of PHD failed. 

After rebooting the computer I was able to launch PHD again, successfully connected via ASCOM, and was able to keep a 5sec exposure loop running (only did so for a couple of minutes).

Debug log for the native driver test is here: https://drive.google.com/file/d/0B5wo30sNzTssVUlkbkp6NXNXMGM/view?usp=sharing

Thanks

Serge

[Sergio Caballero]

Crud, I posted the link to the wrong debug file, sorry. Here's the right one: https://drive.google.com/file/d/0B5wo30sNzTssNDBiTFA1UnhhNlk/view?usp=sharing

[bw_msgboard]

Thanks, Serge.  Andy has been the one interacting with QHY in this area, so I’m sure he’ll follow up with them on your problem when he gets back in town.  Although I can’t help you with the problem, I would make one suggestion: instead of wrestling with the Task Manager and re-booting the PC, have you tried just unplugging the USB cable to the camera?   When an application is blocked trying to complete an I/O operation to a USB device, it’s often not possible to terminate the app through software.  But unplugging the physical connection will often do the trick.  That’s little consolation to you, I’m sure, but it might save you some time.

 

Bruce

 

---

From: Sergio Caballero [mailto:serge.c...@gmail.com]

Sent: Sunday, December 13, 2015 4:33 PM
To: Open PHD Guiding

Cc: serge.c...@gmail.com; bw_m...@earthlink.net
Subject: Re: QHY Camera owners: testers needed for updated QHY camera support in PHD2

 

Thanks Bruce. I uninstalled QHY5 drivers as well as PHD2 v2.5.0, then installed the QHY5 v151028 driver followed by dev7qhytest5. Camera was detected upon plugin and 2 drivers installed. Upon launch PHD went through the profile wizard. I connected via the ASCOM Camera Chooser, built a dark library, and set a 2sec capture loop that ran for 3 hours without a hitch. I won't bother posting that log unless asked since it worked fine.

[Bruce Waddington]

I had one other thought when you're seeing these timeout-type problems - perhaps I'm just grasping at straws.  But it might be worthwhile to check the background processes that are running on your system when you're trying to test - (Task Manager/ Show Processes from all users).  I have seen situations in the last week on two separate Win7 systems where a background Windows process was running 100% utilization on one of the CPU cores for a long time.  The overall system performance was noticeably slower, and I wonder if this could cause problems with very timing-sensitive device operations.  In my case, the problems were resolved by just letting Windows Update apply the latest boatload of updates.  Just a thought.

Bruce

[Sergio Caballero]

Finally got a clear night last night and was able to do a real world test using devQHYTest5. I was unable again to connect via the native QHY driver, but could successfully connect via ASCOM Camera Chooser. I used SGP v2.4.2.11 and captured for 8 hours without intervention on 3 targets including a meridian flip. At no time did the QHY5 time out.

Other than my inability to connect via the native QHY5II driver, my issue seems to be resolved  Today I am updating (again) to SGP v2.3.21, which seems to have tighter integration with PHD2, and after which my timeout issues first appeared. I should be able to real world test tonight.

Thanks

Serge

[Ray Leeson]

Im currently running 2.5.0dev5qhy est.1.exe.....running very well with my QHY5L-ii but qhy5-ii selected....no drop outs good snr see attached link....first time guiding for several weeks due to poor weather.

https://www.dropbox.com/s/pq5xsq3t9ivxrfr/Screenshot%202015-12-21%2000.19.58.png?dl=0

Ray

[Brett]

Hi there Andy and team,

Just wanted to drop some more feedback on the latest QHYTest build.  At this stage it appears that the QHY IMG0H camera is not supported.  It only works if you select it as a WDM device or by selecting the standard ASCOM IMG0H driver, the "QHY Camera" component doesn't it see it.  Would be great if QHY could include support for it, for binning etc.

Cheers

Brett

[Andy Galasso]

Hi Brett,

Thanks for the testing and the feedback.  You may want to send a note to QHY to request support for the IMG0H in their SDK.  We can't so anything in PHD2 unless the QHY SDK has support for the camera.

Andy

[Brett]

Hi Andy, 

QHY have responded...support is coming.

Has anyone tried any other QHY cameras besides the 5L series?

"Hi,

Thanks for you feedback.
Actually the QHY SDK already supported IMG0H, but it needed the new camera driver which was CYUSB driver. And the IMG0H in our website was a WINUSB driver at present.  
And the new driver for IMG0H was still in beta. We will publish it in the furture, then the PHD will supported it.

best regards."

[Magnus Larsson]

Hi!

I've installed this versions with new QHY support on a Win 7 laptop, but it does not find my QHY 5 guidecam, when I choose QHYII-camera. It says "No QHY compatible camera found". The camera seems to work with ASCOM drivers though (although the WDM-drivers seems to work, they only produce a white image). So the camera drivers from QHY seems to work, I believe.

Best,


Magnus

[Enrico Benatti]

And what about Mac. Have you got a beta for Mac and QHY?

[Andy Galasso]

On Sat, Jan 2, 2016 at 12:33 PM, Enrico Benatti <enrico...@hotmail.com> wrote:

And what about Mac. Have you got a beta for Mac and QHY?

Last I heard from QHY was that they were working on it.  I have not heard back from them in quite some time. I guess it';s time to ping them again.

Andy

[jbatesin3d]

I understand this is a corporation we are dealing with but you figure they would be a little quicker in serving their customers. We are using or some of us attempting top use their products for what they were designed to do no? Not the specific program but the task itself.

[Andy Galasso]

jbatesin3d,

You may want to sent a note to QHY expressing that sentiment.  I'm pretty sure they do not monitor messages in this forum.

Andy

[jbatesin3d]

That's a definite. I was actually thinking about calling them and give them the information again so they know there is a reasonable amount of people that need and want this done.

[Andy Galasso]

I just uploaded a new build of the QHY test version of PHD2 based on the latest official PHD2 release, v2.6.1.   This new build still uses the same Nov 12, 2015 SDK from QHY since we have not received any updates from them since that time.  The only difference from the earlier test builds is that this build is based off of PHD2 v2.6.1.

http://openphdguiding.org/phd2-2.6.1qhytest6-installer.exe

There are still no OSX or Linux versions since that is one of the things we are waiting for from QHY.

Andy

[Paul Peacock]

Hi Andy
Thanks for the updated version. I had a good week-long run of clear skies over the New Year and the phd2-2.5.0dev8qhytest6-installer.exe version worked solidly with my QHY5L-II binning 2x2 and subframes. (I *seem* to have solved my disconnecting problem with a heater on the USB hub).
Thanks again
Paul

[Vince]

Hi Andy, recently I started using PHD2 with my QHY5L-II.  As far as I can tell, the only driver in PHD 2.6.1 for this camera that allows binning is the ASCOM driver, but when I set PHD2 to 7.50 pixel size to correspond to the 2x2 binning set in the driver, PHD2 will always default back to 3.75 whenever I disconnect and reconnect the camera.  So binning support would be really nice and I am willing to help.

I have installed this test version but the only QHY drivers I see in the dropdown are simply "QHY Camera" and the QHY8L. I do not see the QHY5 or any of the other QHY5L-II drivers that are in 2.6.1.  If I then choose the QHY Driver, connect, and begin looping, I get a frame but it freezes and does not loop.  I have attached a debug log.

Thanks,

Vince 

[Andy Galasso]

Hi Vince,

If you use the ASCOM driver, then you can set the binning on the camera tab in the brain and PHD2 will make appropriate adjustments to use the effective binned pixel size as necessary. The hardware pixel size will always be fixed at 3.75 um.

If you want to use the test version with native camera support (no ASCOM), then choose QHY Camera.  The new SDK from QHY supports most if not all of the latest QHY cameras, so there is no longer a need in PHD2 for us to have options for specific QHY camera models.

The debug log shows the camera being connected through ASCOM ("CMOS QHY5LII Camera (ASCOM)"), and in that regard this would be essentially the same as using version 2.6.1. Perhaps that was not the right debug log?

Andy

[Vince]

Oops, sorry Andy, attached is a log using the QHY Camera.  Thanks for the info, I will continue testing with the ASCOM camera driver in the meantime.

Vince

[Andy Galasso]

Vince,

That is also a log from 2.6.1 using the ASCOM camera connection.  Nothing wrong with that, it is just not the same as testing the new QHY SDK and the new QHY native camera support in the QHY test build phd2-2.6.1qhytest6.

Andy

[Vince]

Sorry Andy, here goes, third time a charm I hope.

Vince

[Andy Galasso]

Hi Vince,

That log shows the new qhy camera selection being made in the gear menu, but I don't see the camera being connected or looping started before PHD2 is closed.   I would have expected to have seen messages about the camera being connected before you are able to start looping exposures.

Let's go back to square one...  your original post mentioned starting looping exposures and the camera freezing, so let's try to reproduce that and get a debug log.  Here's what I would try:

1. connect your QHY5L-II directly to the PC (no usb hubs or USB extender cables)

2. open PHD2 2.6.1qhytest6 

3. open the connect equipment window.  select "QHY Camera", click Connect to connect the camera. Close the Connect Equipment window.

4. set the exposure duration to 1 -2 seconds.

5. click the Loop button.

6. wait for it to loop a few exposures (or see if it freezes).

7. click stop

8. exit phd2

9. post the most recent debug log in the PHD2 folder.

Andy

[Vince]

Thanks Andy, will do.  I am away for a few days so it will be some time next week before I can try it again.

Re binning via the camera tab in the brain, are you referring to Noise Reduction?  Is that the same as binning?  Because I do not otherwise see a binning option there and have been using the binning option in the driver itself.

Thanks,

Vince

[Andy Galasso]

Vince,

Binning is on the Camera tab in the brain.

You won't see it there for the native driver in 2.6.1 since the old native driver does not support binning.  You will see it there with the qhytest versions.

When using the ASCOM driver, the binning option will be there if the ASCOM driver reports that binning is supported.

Andy

[Sergio Caballero]

Hi Andy - I had been successful with the 2.5.0dev8qhytest6 and had done 3 full nights of multiple target unattended captures with no issues. I tried out the 2.6.1qhytest6 fork last night and had a camera disconnect and sequence acquisition failure as a result after 3 20min subs. In all cases, I connect via the ASCOM camera chooser as I get frequent and rapid disconnects with the the native QHY driver.

debug file: https://drive.google.com/file/d/0B5wo30sNzTssRmFkQmd2VUdVVzA/view?usp=sharing (error occurs at 23:01:37.168 00.000 4392)

guiding log: https://drive.google.com/file/d/0B5wo30sNzTssNExyYnhqYWxlU1U/view?usp=sharing

Serge

[Andy Galasso]

Sergio,

Thanks for the report, but I'm not sure what to make of it.    When you connect via the ASCOM driver (as your attached debug log shows you are doing) then you are bypassing the native QHY camera code in PHD2.   In other words, when you connect with the ASCOM chooser you are not using the native driver at all.  By native driver we are referring the this:

Any other method of connecting to the camera, including the ASCOM Chosser will not be using the new QHY SDK.

Issues with the ASCOM driver are certainly relevant for QHY camera owners, but I was hoping for purposes of this discussion thread to evaluate the reliability and performance of the new SDK that QHY gave us.

I hope that makes sense... and sorry if I misunderstood your report.

Thanks,

Andy

[Vince]

Ok Andy, I have followed your instructions and tested it again and it seems to be working fine now.  Initially I thought it had frozen again but when I retried it with the camera cover on I could then see changing exposures, so having the camera cover off may have been the problem the first time.  Binning also seems to be working, as the appearance of the exposures darkens with binning off.  I have only tested it indoors and will update you when I can try it live. 

Thanks,

Vince

[Andy Galasso]

Vince, thanks for the update and glad to hear it seems to be working.

Andy

[jbatesin3d]

After I mentioning contacting QHY last month I received one letter back from them telling me to check out a page that was of no help with outdated information. Then I never heard back from them despite my several messages. I was about to just put the camera up for sale until I saw this new information on the new build here. I am happy to see that there is a new build and am eager to try it in the next few days. Out of curiosity, did they resume/increase contact with PHD around the middle of last month?

[Andy Galasso]

On Wed, Feb 3, 2016 at 2:31 PM, jbatesin3d <jbate...@hotmail.com> wrote:

I am happy to see that there is a new build and am eager to try it in the next few days. Out of curiosity, did they resume/increase contact with PHD around the middle of last month?

Don't get your hopes up too much.  The new test build only updates the code base to PHD2 version 2.6.1.  The QHY SDK has not changed and is still the November 2015 version as that is the last we have from QHY.

We did not hear from them last month.

Andy

[Vince]

Hi Andy, I tried this beta live last night using the QHY5L-II and QHY Camera driver, and it works just fine (other than poor guiding which is normal for me :)). The guide log does not identify the camera however, so for example the log in PHD2 Log Viewer says "Camera =  , gain = 40..." etc.  This is not a problem for me but just wanted to let you know.  A guide log is attached (note that later in the log I switched to the ASCOM driver but previous camera references in the log will show you what I mean).

Thanks for your continuing improvement of this great software,

Vince 

[Andy Galasso]

Hi Vince,

Thanks for the tip on the missing camera name. We'l gat that fixed in the next build.

Andy

[Terry Fishlock]

Any chance of support for the QHY polemaster camera? I tried mine but came up as unsupported camera. It's basically a QHY5L11 in a different case. The driver is on the qhy site.

Thanks

Terry

[Pascal Mora]

Hello Andy,
I tested the last QHYtest version of PHD, and .... I have always camera timeout, the last imaging session was even a true nightmare, impossible to get the camera connected more than few minutes.
In general I use one second exposure and when looking at the camera windows some frame were frozen for several seconds without any period of normal work. After having completely disconnected and reconnected all my imaging devices the situation become better and the timeout more rare. So for me no real difference between the QHY and the classic version of PHD, sorry. On my setup the problem seems to be related to the usb quality connection, for the next imaging session, I plan to use WDM mode (through ezplanetary) that seem so be more stable (no visible lag in the camera windows), I will let you informed. Thank you for your work.
Regards.
Pascal
 

[Brendan Kinch]

I have been using that test build for some time now - without any issues to report. I have not had many nights when guiding was going on for a prolonged period - but certainly it was running just fine for several hours at a time. My problems just now are all related to a layer of cloud or a bright moon just hanging over the area where I want to do some imaging :-(

Slán,

Brendan.

www.KinchAstro.com

[Sergio Caballero]

Pascal, even with the test builds I am unable to stay connected with the native QHY driver, but have no problems connecting via the ASCOM driver. Give that a try.

Sergio

--
You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/VC9zliAbe4w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-phd-guidi...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Facebook: Serge Caballero
Acoustic Guitar Community: http://www.acousticguitarcommunity.com/profile/g8r

[Pascal Mora]

Hello,
thank you for your replies, whatever driver I use (ascom or qhy ) when the camera do not want to stay connected I have camera timeout, sometime very rare sometime be go crazy ... I have the last drivers in all my devices so I think the problem is not totally solved.
Regards and 

[Brendan Kinch]

Pascal you said earlier... " On my setup the problem seems to be related to the usb quality connection". I wonder if you have done anything positive about that. These cameras are very demanding on USB and if you have any reason to suspect that you have a data flow problem (on that particular USB route) then you will need to play around with different cable connection configurations. I have said it before (here or elsewhere, I am not sure) but as well as checking cables and using powered hubs  - where a hub is required - it is worthwhile looking at how the USB ports are configured within the computer. I find USBView is a simple little program,that gives a good overall picture.

 

I try to keep heavy data flows on separate USB routes. (See my connection layout: http://www.kinchastro.com/connection-diagram---electrical.html)

Brendan. 

[Bruce Morrell]

Gentlemen,

It is my experience, that a major contributor to cameras disconnecting are ground loops beyond the timeout issue.  This is where a current flows through the ground of the USB connection.  It is very easy to check, unplug all of your USB connections, and read the voltage from the ground side of the USB connection to the others as well as to the ground on your laptop USB.  There should be no voltage.  It is a whole other discussion on how to eliminate the ground loop.  Just adding my two cents.... Bruce Morrell

[Vince]

I have used this build several times live with the QHY5L-II, using both ASCOM and QHY Camera driver, and have had no connection problems, but I exclusively use on-mount guiding (not ST4).  I also use the 14-12-12 high performance driver installation package, not the 15-10-28 high compatibility driver package.  Aside from that I would venture to agree that USB connections could be the cause of disconnects.  I used to have all kinds of problems with this camera and other connections until I started using a Belkin powered hub and Belkin cables exclusively.

On another note, Andy, the QHY Camera driver is working great for me, and it is nice to have binning and gain options in PHD2 itself rather than having to set those in the driver, as was the case with the ASCOM driver.

I was confused however with minimum move pixel size, but it seems to me from looking at my logs in PHD Log Viewer and applying the "Limits" graph, that it refers to the binned pixel size, so that for the QHY5L-II binned 2x2, the pixel size used is actually 7.50 um.  Perhaps a note in the minimum move mouse-over info explaining this in a future version would be helpful to others.

Thanks,

Vince

[Anat Ruangrassamee]

I wonder if the polemaster camera can be used with Phd2. It is basically the same as QHY5Lii with a vender ID = 940 instead of 920. 

http://www.cloudynights.com/topic/523154-qhy-polemaster-any-feedback/?p=7053280

Please advise.

Best regards,

Anat

On Thursday, October 15, 2015 at 5:19:49 AM UTC+7, Andy Galasso wrote:

We have been working for several months with the developers at QHY to integrate a new version of the QHY camera libraries into PHD2. Before adding the new libraries into an official build of PHD2 we need help testing out the new code.

The new libraries from QHY have a number of improvements including:

  - support of most (if not all) QHY cameras,

  - subframe support,

  - binning support

We currently only have a Windows build as we are waiting for QHY to deliver OSX and Linux versions of the latest camera libraries.

If you have a QHY camera, it would be great if you could help us out by installing this build of PHD2: http://openphdguiding.org/phd2-2.5.0dev5qhytest1.exe

After installing the test version, select "QHY 5-II" for the camera even if your camera is not a QHY5-II.

We would appreciate hearing if the new code works for you. If you see any problems, please let us know and post a link to your PHD2 debug log.

Andy

[Andy Galasso]

Vince,

Thanks for the feedback.  I added an entry to the issue tracker for your suggestion to clarify the meaning of pixel size (binned vs unbinned) #509.

Andy

[Andy Galasso]

Thanks to all who have provided feedback so far on the QHY test version.  This thread seems to be going in a lot of directions unrelated to the original post now.

I'm going to lock the topic from new replies since we are not really looking for any new feedback on the test build. When we have a new SDK from QHY, we'll need more feedback at that time.

Feel free to create new discussion topics for any phd2 issues you might have, related to the QHY test build or otherwise.

Andy