Issue with QHY5III178M and longer exposures

[Lord Beowulf]

Hi all,

I've posted this on CN and QHY's website, but haven't seen a response.  Given that I'm specifically using PHD2 with this camera, I'm hoping someone here can help.  I just upgraded from a QHY15L-II to a QHY5III178M and while I accomplished what I was hoping in terms of sensitivity and FOV improvement, I'm having a problem as I move to longer exposures.  At four seconds you can see some background noise appearing.  Occasionally it comes back with bad frames, which was not uncommon from the QHY15L-II either.

At five seconds, the image is swamped with noise.  

Does anyone here have any idea what's going on?  Anyone with this camera have any experience with it?  I haven't had any chance for debugging.yet, so it may be something simple, but if the camera needs to go back, I need to know now.  I ran a dark library first, so this should be with darks applied.  I'm not sure what the darks look like.  I have a ZWO ASI178MC that I'm using for an all-sky camera and it's working fine with 60s exposures, so I know the sensor should handle the longer exposures.  Of course I never attempted to run that through OpenPHD.  At any rate, thought I'd post here to see if there were any ideas.  I'm not sure when I'll next have clear skies and an opportunity to test, but I'd like to actually USE it when I get there.

Thanks for any input or suggestions anyone has.

Thanks,

Beo

[Brian Valente]

Hi Beo

 

It could be one or more of three things:

 

First, it could be the viewing of your guide image – I noticed your slider for brightness is cranked all the way to the right. try dialing that back to maybe halfway. If this is the case, the exposure won’t make any difference in actual guide performance because it’s just a display thing

 

Or

 

Second, it could be your camera is too light sensitive for 5 second exposures. Try lower shorter exposures.

 

Or

 

Third, if your stars get out of focus, sometimes it will white out like that because it’s attempting to gain up the display

 

 

 

 

Thanks

 

Brian

 

 

Brian Valente

Brianvalentephotography.com

--
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.

[oliv deso]

Hello Beo

I have been using this camera with PHD2 since last sumer

- I usually use 3s exposures. I may have used 5s exposure also last summer, but not sure. I can't remember having faced such issue...

But I may have a try if needed...tell me.

- since I upgraded from PHD2.6.3 to PHD2.6.4, the stabilty degraded.

I observed the same with the ZWO224.

(The CCD do not seem to be impacted, at least the lodestar nativz, and the Moravian G1 ascom)

What I found:

-> the camera connexion became very sensitive to the USB3 cable model and the USB3 hub if any.

And more complicated : a cable which work well on a PC may not work on another PC. And the contrary is possible also.

I suspect this is linked to the impedance which is not balanced well between the cable and the PC connector...

Whatever, when I upgraded from 2.6.3 to 2.6.4, I found: 

- the native driver become blicked from time to time without

- the ascom drivers also fails from time to time (timeout it seems) so PHD2 indicates it has disconnected the camera following this lack of answer from the camera, but in fact PHD2 recovers at the end, so the impact on the guiding is almost null.

-> So I only use the ascom driver since the 2.6.4

-> try the 2.6.3 an see whether there is a difference or not.

Olivier

[oliv deso]

also, at first sight, it sounds like a dark issue...

[mj.w...@gmail.com]

Hi Beo

Is that an auto selected star? Looks like there are better stars in your images?

Is there a camera gain setting in the brain menu? You could turn that down a little?

Michael
Wiltshire UK

[Lord Beowulf]

Hi All:

Thanks for the responses.  First off, let me direct you over to the full thread on CN, where I was evaluating the QHY5III178M as a replacement for my QHY5L-II M.  These images are just the last two frames where I encountered the problem, but the goal here was to see how many more stars I could find to guide in the same FOV on the 178 vs. the 5L-II.  So turning down the gain, etc. kind of defeats the purpose of the experiment.  However, if the camera has trouble beyond a certain exposure, or with an over-exposed star in the image, then that's a big problem.  One of my goals for getting this camera was to be able to do some monochrome imaging as well, where either of those issues would be a disaster.  Not to mention that if I have a 5X more sensitive sensor, but can only use it at 1/5 of the exposure time (yes, I know it's not QUITE that bad!), that kind of defeats the purpose of getting a new camera!

Now, to Brian's suggestion on the brightness (gamma) slider, it's my understanding that all the way to the right is the least stretched condition and that moving to the left is the equivalent of moving the midpoint on a linear stretch slider.  Thus, as the background comes up, that would just make the background brighter.  The one thing I do note in that screen shot is that the star image does actually show the blown out star with a dark background, so that supports the thought that the problem may just be a screen stretch problem in PHD2 and not a problem with the actual image.  If so, that begs the question of how to resolve it.  I don't believe sliding the slider to the left will help.  It would be nice if there was a bit more control over the (auto?) stretch functionality and even the ability to see a histogram would be nice.  I've always thought the visual representation didn't necessarily reflect reality.    

BTW, anyone know how to extract the dark library into individual files (assuming it's not just one merged image).  I can load the FITS in SGP, where I can see the headers for each imaging time, but I only get one image.  I'd like to look at the longer darks and see if there's something happening to them.

Thanks,

Beo

[Brian Valente]

Beo

 

Couple things, and I apologize in advance if I’m repeating myself or saying things you already know:

 

1.       What exactly are you concerned about? That the star is not properly exposed for visual review? I typically don’t spend any time on that, I look at the star profile and HFD and we’re off.

2.       How is the actual guiding once a star is chosen? The actual screen display makes no difference to that, I’m sure you know

3.       You might also consider using subframes which speeds up guiding – visually they are totally useless but all the data and charts are still effective

4.       Imho I’d still go for shorter guide times, which in a roundabout way may solve whatever issue you are having

 

Thanks

 

Brian

 

 

Brian Valente

Brianvalentephotography.com

 

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Lord Beowulf

Sent: Wednesday, May 2, 2018 9:02 AM
To: Open PHD Guiding <open-phd...@googlegroups.com>

--

[Lord Beowulf]

Hi Brian:

If you read through the CN thread you'll see that the goal was to replace one guide camera with another one with a wider FOV and hopefully higher sensitivity.  That was done and these images are screen shots of the initial tests to compare both FOV and sensitivity.  The results did illustrate the improvements in both FOV and sensitivity, but the issue is that at 5 second exposures the results were no longer usable to visually find a guide star, although obviously they were there.  At face value if these were representative of what I would expect to get under other conditions (e.g. when there were no bright stars) then this would indicate that I had not really gained the full improvement in sensitivity since I could never push the exposure beyond a few seconds if I needed to try to do so in order to find a guide star.

From there, the first and foremost question is if this is a limitation of or defect in the camera.  If what I'm seeing on the screen represents the actual full-scale/full-well camera data, then I'd say there's a problem with the camera (at least for this application).  If I could see raw data (e.g. the darks) I could probably determine that.  If the camera is bad or just won't work then I need to return it ASAP.

I'm now suspecting that it is in fact something odd happening with PHD2's AGC on just the visual display when the star is oversaturated.  Actually, that would make a lot of sense if the AGC somehow ignores saturated pixels and attempts to adjust the visual stretch range solely to some range of unsaturated pixels, as then it would boost the signal to just cover the noise and ignore all the full-well data.  The result would be a frame that looks similar to what you get when there are no stars detectable above the noise.  That implies that in the case where I'm just trying to find one guide star I won't have a problem, but I don't yet know that, and won't be able to test for at least the next week due to weather conditions.  

It's only in this latter case that then the question would arise as to if there are settings (for the view, not the camera gain, etc.) in PHD2 that would resolve the visual issue.  If not, that would be something to add to a wish list.  

So, in answer to all your other questions, this has nothing to do with guiding.  This is all about whether or not this camera can obtain images suitable for PHD2 to use to guide, or if the camera needs to be returned.  But just to satisfy your curiosity, at the fractional second capture times the system guides fine, as I would have expected.    

Thanks,

Beo

[Andy Galasso]

Beo,

PHD2 can save the raw non-histogram-stretched images.  Menu: File > Save Image, or, use the diagnostic image logging feature.   You can then base your analysis on the raw images, not the histogram-stretched screen-shots.

Re: extracting frames from dark libs: you'll need to use a FITS  viewer that can handle multiple-image fits files.  For example: PixInsight, Fits Liberator, many others ...

Andy

[Brian Valente]

Beo

 

I think I better understand, and I did read through the CN thread.

 

>> This is all about whether or not this camera can obtain images suitable for PHD2 to use to guide, or if the camera needs to be returned. 

 

Imho visual inspection is probably not the best way to determine this, particularly if you’re gaining the display way past where it needs to be. Obtaining a solid guidestar is what it’s about, right?

 

You might try PHD auto-selecting the guidestar. When I’m guiding via OAG with my zwo asi1290 mini, PHD2 picks guidestars I can’t even see on the screen, and does a great job with guiding.

 

It sounds like you’ve determined it’s more sensitive, which is what you (and we all) want. I’ve never heard of a camera being too sensitive, since you can just dial down the exposure time.

 

 

I guess I’m just a little confused on why the visual representation (which adds other non-important details for guiding) is what you are basing this on? maybe you have a requirement for 5 second exposures?

[Lord Beowulf]

Yeah, I saw the save option later when I was looking through PHD2 and was hoping it would save the raw image, but I can't use it until I get some good weather!  =)  

Thanks for the suggestion for PixInsight as I didn't even think of trying it, but I have it.  I'd thought of Fits Liberator, but I've never been able to get anything useful out of it (probably since I usually want to deBayer...)

Thanks,

Beo

[Lord Beowulf]

So after getting PI running again on my observatory PC (I'd apparently never installed the purchased license!), I was able to open the darks library.  The 15 second dark looks reasonable on the histogram, so I'm HOPING that the problem is simply in the user interface in PHD2 and not something odd that happens to the camera when a large number of pixels are saturated.

Thanks,

Beo

[Lord Beowulf]

Hi Brian,

I'm using the visual data because that's all I have.  As mentioned a few times, I can't test any further at the moment.  I received the camera last Thursday, stayed up until 1:30 AM getting it installed and tested to that point, and the observatory has been under clouds since then.  In the process of testing, I repeated the same process on two cameras and had a problem with the new camera that I did not have on the old one.  Normally, assuming that the software and the source data (the stars) are essentially the same, and having the display go from a black background to a noisy white one with the change of exposure would point to a problem with the one thing that was changed (the camera and driver) and not the software or stars!  So while I suspect at this point that it actually is a problem with the software (or rather the way it reacts to the camera data) and not actually the camera, I need to be assured of that in a relatively short order.  Certainly if the camera is bad, I want to send it back now and not wait around for the weather to clear up.  Beyond that, in the event that I don't get any opportunity to test before the return deadline, then I really have a problem.  Thus the desire to find someone else who has experience with this camera and could say, "Oh, I've seen that and here's how to fix it." or "Oh, no, that doesn't look right at all."    

Note too that I posted here as something of a last resort since I had received no comments to the update on CN and no response from QHYCCD (until this morning saying they'll look into it) or the vendor.  Thus I greatly appreciate the responses here as I suspected I'd get better information here anyway.  Figuring out a way to look at the dark library helped a lot.  Now I'm going to have to see if I can find a way to replicate the issue remotely with the observatory closed. I can try turning on my flats light but that will likely saturate the entire image.  I doubt I can find an LED to point to, and even I managed to line up on one, it probably wouldn't come through as enough of a point source or have a similar brightness.  Anyway, I'll still see what I can try.

Thanks,

Beo

[Brian Valente]

Okay great.

 

Let us know how it goes, hopefully it ends up being an improvement for you

[Lord Beowulf]

Thanks Brian:

Ok, I have a few more data points, doing some tests with the saved image feature in PHD2.  Unfortunately the slider DOES affect the saved image, so I can't tell what's happening to the raw data, but it does give some interesting insight to the screen function.  My flat light panel is just too bright to take a shot at even the shortest exposure at this gain, but the IR LEDs from my observatory cameras give enough light to be able to do some interesting tests, although without much contrast across the image.  

With the brightness slider to the right, a two second exposure of the IR background gives this result.

 

Moving the slider left shifts the histogram to the right, indicating the slider acts like a typical midpoint adjustment.

 

Thus, when the background is getting swamped as in the original 5s exposure, the slider has to be to the right to pull the background down as far as it will go.

With the slider to the right (first picture) and no dark library applied, we get this noisier histogram that's even further to the left:

 

Now, here's where things get interesting.  Turning off the IR cameras so that I just have whatever minor background is in the observatory due to a stray LED or two, I get the following with the dark library disabled.  I think this was a 5 second exposure, but can't be positive as PHD2 doesn't appear to put that into the FITS header.

However, applying the dark library, gives a really odd behavior. 

The histogram narrows, which is to be expected when subtracting a dark from dark, but the screen function shifts the entire histogram to the right so it's full white instead of black.  I don't believe the slider impacted this, but I'd have to repeat the test again tonight to be sure.  It appears that this is taking the max pixel and putting it at the right of the histogram, but not stretching the histogram.  In other words, it just adds a constant offset to all pixels.  That seems an odd approach.

Unfortunately this still doesn't answer what's happening at the original 5s exposure where I have multiple saturated stars (right of the histogram) and a white background as well.  Is that real or some oddity of the screen stretch algorithm like the dark above?  The only thing I can think of that might be a real effect is that since this started out as a quick test, I didn't bother turning off the observatory cameras.  Normally that only introduces a small amount of "sky glow" when the scope is pointing up, but given how sensitive this camera is, and that it appears to be pretty sensitive to IR, that may have contributed to the 5s exposure problem.  Unfortunately I won't be able to check that until we get clear skies.  However, looking back at the 5s image again, I may already have my answer.  There's a slight dark blotch above the main star that looks similar to the "bird" shaped shadow in the middle of my IR tests.  Assuming that's optical and not something in the sensor itself, then that would imply that there was enough background light to blow out the image at 5s.

Thanks,

Beo

 

[Brian Valente]

Hi Beo

 

Are these images still with the screen stretch all the way to the right?

[Lord Beowulf]

Hi Brian:

It depends on which one you're asking about.  The first two were demonstrating what the slider does to the image, so one's to the right, the other is to the left.  As I mentioned in the post, on the last two with the dark, I don't believe the slider had an impact, but I believe that was with the slider to the right as well in order to keep the most of the histogram on the image (moving it left obviously will clip as shown in the second figure).  Once I discovered that the saved image reflected the effect of the slider, I quit capturing screen shots, so I don't have something parallel to that to tell me and unfortunately the saved FITS has no settings information.  Again those are all features it would be nice to have PHD add, just for diagnostic purposes like this.

Thanks,

Beo 

[Lord Beowulf]

So I don't have time to post images (which don't look different than above anyway) but with the exception of variation from random noise that occasionally changes the brightness of a shot, the slider has no visible impact on the dark room images.  For the three left/center/right images that don't use dark library subtraction, the histogram stays on the left side, showing apparently the same raw noise floor.  If dark subtraction is used, the histogram switches to the narrow spike and stays on the right side (white) regardless of the left/center/right brightness adjustment.  

Given I'm not aware of any other image processing/screen transfer function that behaves this way, I'd say the function in PHD2 could use a bit of work.  I can see the value of setting the maximum pixel to 1 (white) on the histogram, but not in completely offsetting the histogram rather than stretching it.  I also don't know why it would apply one behavior if darks are used and another if not.

Beo

[oliv deso]

Hi Beo

I am curently imaging in the field. (at 60km away from Paris/France SQM 20.5)

I just installed PHD 2.6.5.

I am using the QHY5III178  @ 5s exposures with not any issue.

I did not build yet the dark librayry

Find attached an screen shot of what I have now, which is very similar to what I always had with this camera.

Setup AP130 GTX with its x0/75 reducer -> FL 585mm @F/4.5

QHY5III178m on the QHY OAG

Mount Mach 1. A little bit windy and so so seeing FWHM about 3".

Olivier

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guiding+unsubscribe@googlegroups.com.

[Lord Beowulf]

Thanks Olivier,

I didn't spend a lot of time this weekend experimenting with the guider since I was also working on some other projects, including testing SGP with my new ASCOM driver for my home made focuser.  However, I believe my assumption that the camera IR was limiting my initial tests is accurate.  On the other hand, I still see a problem of randomly getting noise limited frames at longer exposures even though that shouldn't be an issue.  I've always seen this behavior in PHD/PHD2 and just lived with it.  However, now that I'm delving into this I really want to know what causes it, as I suspect it's not really coming from the camera.  When I get the time I'll test against SharpCap or something else to see if there's any evidence of this variability in another package.  I'm also planning to delve into the image processing code to better understand what PHD2 is doing.  Given how much impact the use of darks has, and the fact that you aren't using them at all, it may be that the darks are actually detrimental in this case.  If and when I learn more I'll post what I find.

Thanks,

Beo

[oliv deso]

Hello Beo,

I fact I usually use darks frames (19 stacked dark frames) and 3s exposure with PHD2.

Here I just ran a quick&dirty test for you, at 5s.

But tonight, the whether is fine here, so I could test more, with darks @5s.

let me know if you need any specific test.

Olivier