Tips for QHY CMOS Cameras...

[rockw...@bell.net]

Hello Peter ,

This is my third attempt at sending "anything" on this Forum today . It just doesn't like my content . Anyway , I follow this E-Magazine and have all the Issues saved as Links and this one had an Article on QHY CMOS Cameras . Since you have the QHY2694C , I thought this might be of interest to you .

https://issuu.com/amateurastophotography/docs/issue79_smll

The Article starts on pages 10-11 .

Enjoy ,

Scott..........

P.S. I cannot "cut and paste" photos into my Post or Add an Attachment of a Photo anymore. I was going to share my recent Saturn and Jupiter Images but they won't be accepted . Something has changed .

[peter wolsley]

Scott,

I have seen this article on the QHY forum.  The graphics are much better on your version.  This year has been a real learning experience for my and my QHY294C.  I also chose to write an application to control the camera.  There are some challenging quirks with these cameras...especially when shooting narrowband.  I use the LeNhance Duo Narrowband filter and 600 second exposures.  It really tests my equipment but I like the challenge.  Generating FLATs for the LeNhance filter configuration is a struggle.  You can't expose the FLAT any more than 50% when using the HGC mode at GAIN=1600 because the fullwell is so low that it clips the pixel values at about 70%.  Even after taking FLATs and DARKFLATs it's difficult to get the FLATs to work correctly.  I end up using the FLATCOMP feature with a gain of roughly 50% which I never had to do when using my Nikon DSLR.

But the results are encouraging.

Peter

[rockw...@bell.net]

Hi Peter ,

Well , it sounds like your Steep Learning curve got a little steeper . LOL . Interesting stuff . I'll check with my Buddy John and see if he's seen this reply as he is looking at a QHY Camera now

It would be good to be armed with lots of good info going forward .

Also , that is a fantastic Image of the Tulip Nebula . So , 600s with the L-eNhance Filter...how many Light Frames and how long was the Post Processing ?

Since you were able to attach that Image in the Post I'm going to try again as I could not do it yesterday .

OK , that worked . Had to resize them to a smaller Kb and then use the "insert photo attachment" button . Things are different now .

Still waiting on a night where I can get the Great Red Spot on Jupiter . There's only nine opportunities between now and the end of September .

Cheers ,

Scott...........

[peter wolsley]

Scott,

I used 22 exposures @ 600s/exposure =3hr 40m total integration

8"EdgeHD @F10 + LeNhance + QHY294C

Celestron CGEM + QHY5II-M guider (FL=177mm) + PHD2

CaLIGHTs + DSS + Startools + Lightroom

July 8th, 2020

Peter

P.S. Great planetary images...still on my bucket list  My dark site does not have a view to the south

[rockw...@bell.net]

Hi Peter ,

Thanks for those Details , they are always very useful in understanding how Great Images are captured .

Have you had a chance yet to play with SiriL ? I'm curious what your take is on that Software .

Thanks for the comments on my Saturn and Jupiter Pics . It's been a while since I did any Planetary stuff too . I need a large Evergreen in my front yard to block a Streetlight so I can get those images .

These were from 2min Videos , 3750 Frames , into PIPP to convert the Canon MP4 to AVI , then AutoStakkert to use the best 50% for Stacking , then Registax for Wavelet sharpening and some Colour Balancing .

I quite like them but I know I can squeeze a little more from some better Lucky Imaging . 

Scott................

[peter wolsley]

Scott,

I haven't tried any new software yet. My goal for this year is to use every night available for acquiring data...typically a different DSO every night with a goal of more than 3 hours minimum total integration time.  Because I write Astronomy related software I am also focused on debugging lots of code for my system and potentially for others.  Over the years I have developed a very sophisticated Periodic Error correction system for my CGEM.  Most CGEM owners don't have much luck using Periodic Error Correction (PEC) logic because the CGEM, and several other Celestron mounts, have non-integer gearing.  I have developed a scheme that has no problem dealing with this issue.  I typically achieve 0.5" total rms guiding error.  My algorithm tracked multiply (3) wormgear rotations with real-time adaption that continuously updates the PEC waveform and also dynamically focuses on discrete frequencies associated with the RA axis gearbox using discrete Fourier Transforms to provide a real-time tracking rate adjustments.  A whole lot of work went into that code but it is very stable and high performance.  I also developed a DEC backlash compensation scheme that works, in tandem, with PHD2 to make it almost impossible to determine when a DEC backlash event is occurring.  PHD2 thinks it is correcting a mount that has a DEC backlash of roughly 5 arc-seconds while my tandem code is moving the DEC axis close to 50 arc-seconds to correct the entire DEC backlash. The DEC guiding error rarely exceeds +/-1 arc-second.  I offered the scheme to the PHD2 folks but they weren't interested. All of the DEC adjustments are achieve using pulse guiding with my code and PHD2 co-operating to decide when to issue the pulse guide commands.

I also wrote Polar alignment code which only needs access to Polaris and can be performed as soon as 15 minutes after sunset. It uses my QHY5II-M guiding camera.  I use a 30M powered USB cable to connect my system to my Laptop computer which is located indoors.  Except for manually adjusting the AZM and ALT axis during polar alignment, I do everything inside the house. I wrote an app for my tablet that communicates with my Laptop.  As I make manual adjustments to the AZM and ALT I have the tablet beside me displaying the real-time polar alignment error.  I just adjust these two axis until the polar alignment error is minimized. While my code will allow me to achieve zero polar alignment error, I strive for roughly 100" error because this yields a slow DEC drift that does not cause field rotation in my images but does help to prevent DEC backlash events.

I also wrote calibration assistance code that allows me to easily perform 2+4 star calibration well before the skies are dark enough to begin imaging.  It also uses the QHY5II-M camera.  This code displays a real-time video of what the guider camera sees.  Once the CGEM has moved the mount to each star, the field of view is large enough to have the star visible.  If I click on the star, position regulator code is enabled that will move the star to the center of the field of view.  Calibrating the pointing model becomes very simple.  I basically calibrate the mount to the centre of view of the guiding camera video.  I also ensure that the guider camera view and the imager view are concentric.

Last year I wrote code that compensates for differential flexure in my imaging rig.  The 8"EdgeHD scope has lots of flexure.  My 80mm refractor has virtually zero flexure.  My flexure code analyses each photo from my imaging camera (DSLR or QHY294C).  It identifies all of the stars and builds a database of the star locations.  Comparisons of star locations are then used to determine a rate adjustment that needs to be sent to PHD2.  I use the PHD2 server and it's comet tracking feature to slowly ramp the guiding set-point which reduces the flexure to less than one pixel per image.  This codes gives me round stars at 2032mm focal length imaging in 600 second exposures without using an off-axis guider set-up.

This year has been focused on writing code to support the QHY294C.  I have written cooler control (slow cool and slow warm-up) and a simple sequencer to save the images as FITS.  In the past weeks I have added Plate Solving code using Plate Solver 2.  I just finished imaging the North American Nebula where I used the plate solver code to reposition the mount after a Meridian flip.  These are all features of lots of astronomy programs currently available but I like to write my own because it's my hobby and I want to understand what needs to happen for these features to get the job done.

So right now I am focused on debugging my software and taking lots of photos.  Once the snow flies I will switch gears and focus on post processing.

Peter

[rockw...@bell.net]

Hi Peter ,

Wow , I did not intend to force you to devulge what you've been up to , which is extensive to say the least , but simply to ask if you had tried SiriL . Good Lord you've been busy . I imagine Retirement is giving you the time now to do these Projects .

I have to admit I did not know what Differential Flexure was but I have since looked into it . It's not just the OTA by itself but the combination between the OTA and an External Guidescope and Camera , correct ?

I guess this is the reason some people opt for an Off-Axis Guider . Luckily for me I don't have to worry about such things with an Alt/Az Mount .

That's a shame that the PHD2 Folks were not interested in your Work . What could be their reasoning for such an oversight ? You need a Promoter for your Products (not me) , maybe a good Lawyer or Accountant .

Well , I look forward to hearing more of your Progress with your "Hobbies" .

Cheers ,

Scott..................

[peter wolsley]

Scott,

I guess I was just warning you that when winter comes around I might be asking you lots of questions regarding post processing.  Your concept of differential flexure is very good...basically it entails everything that could cause a slight misalignment between the imaging camera and the guiding camera. A lot of people struggle with differential flexure so I might offer my software solution someday.  An Off-axis guider is the standard solution for flexure but I am resisting switching to an Off-axis guider because it makes guiding more complicated and it also dramatically reduces the FOV of the guide camera image. 

The PHD2 folks need to deal with all of the available mounts and cameras which can't be easy.  I think what would have improved the odds for me would have been if I could have written the C+ code for them so that their involvement would have been easier.  I could only provide the algorithm because I program in a language called LabVIEW which is very powerful but looks completely different than C+ or any other text based language.  LabVIEW is a completely graphical language.  I have no interest in learning C+ or any text based language.  LabVIEW is tough enough and I have been using it since 1996.  

One of my winter tasks will be converting all of my software from 32b to 64b.  I expect programs will respond better.  I also expect that will be when I migrate to the latest version of LibRAW.  The guys who support DSS are still dealing with issues from their conversion.

Peter

[rockw...@bell.net]

Hi Peter ,

No worries , ask away . I will be happy to help where I can . I did receive a reply to an inquiry from the gentleman that did the original SiriL Video and he said he will do a more in-depth version once the California Wildfires stop trying to burn his House down ! Oh my !

When I looked into Differential Flexure this Site came up and the Owner here found solutions that were Mechanical in nature and readily solvable...

http://astronomy.mdodd.com/flexure.html

Maybe something in there will be an item you haven't already tried . Fingers crossed  .

Cheers ,

Scott.............

[rockw...@bell.net]

Hi Peter ,

Quick question...what are you currently using for Focusing the EdgeHD OTA ? I'm going to add the Celestron Focuser to my Mount so I can get reliable focusing and a numeric value for the different Accessories .

This will allow an easy Interface with the SkyPortal or SkySafari Apps that I have . No chance of bumping the Focus position during the night or having a mechanical change due to Temperature .

Scott..................

[peter wolsley]

Scott,

I remember viewing this site a few years ago.  He did a lot of modifications.  The ironic aspect of his problems were that his SCT didn't have anything close to the flexure he was experiencing with his refractor.  I suspect this is because he has his guidescope connected to the saddle on the mount and not piggy back on his refractor.  I have my guidescope mounted on the back of my refractor and it shows no flexure. Basically, if my refractor start to flex due to the orientation of the scope, my guide scope goes along for the ride.  The net result is that the two cameras stay collimated.

My SCT shows the worst flexure and I also have the guidescope mounted piggy back on the SCT.  In this case I believe it is caused by primary mirror flop in the SCT which is well documented amongst SCT users.  There are mirror clutches on the SCT that are suppose to minimize the flop but I have not seen this ability yet. 

His original comparison implied that the 9.25 SCT demonstrates far less flexure that the 130mm refractor but he never shows how his SCT is configured...he may be using an off-axis guider for his SCT.

Given all of the time and money he spent trying to fix his flexure I would expect that people would pay $$ or maybe $$$ for a software program that will do the same or better.  My differential flexure program enables me to take 10 minute exposures at 2032mm focal length using a guidescope is exceptional.  As a side benefit, my program also informs the user what the differential flexure is in units of Arc-Seconds/Hour.

Peter

[peter wolsley]

Scott,

By now you know whatever I use...it won't be conventional.  My Engineering background colours everything I do.  I attached two photos that explain my scope set-up and how I focus.

The first photo shows my refractor and SCT.  I added a Moonlite High Resolution focuser to my BK80ED refractor.  The refractor has it's 0.85 focal reducer/flatener, fliter drawer and the QHY294C attached.  The SCT has my own version of a stepper motor controlled focuser.

The second photo shows some of the details of my homebrew stepper motor focuser.  The 12V stepper motor has an internal 64:1 gearbox and is connected to the focuser knob using a gear and timing belt arrangement that I purchased from China when that was still possible.  The 12V stepper motor is wired so that it can be controlled by the same controller as the Moonlite Focuser.  The Moonlite Focuser is designed to interface to their own equipment or to the RoboFocus device.  This wiring diagram is public domain so that was straight forward.

So that's the hardware...now for the custom software that I wrote...you were expecting something different?

I have written a program that will capture a piece of the computer screen video and lets me do calculations with it.  For my Nikon DSLR I use DIGICAMCONTROL to display a liveview from the DSLR.  The mount is pointed at a bright star.  I then use my program to "click" on the liveview screen where the star is located and now my program performs a real-time pseudo-FWHM calculation.  The calculation is not exactly a FWHM calculation so I call it a "Starsize" calculation.  It basically tells me how many pixels are brighter than 50% of the star's peak brightness.

I then have an algorithm that moves the focuser position thru a small range of motion stopping at small increments just long enough for the starsize calculation to stabilize.  I graph the focuser position vs the starsize value and it draws a perfect parabola.  The starsize starts off large and then shrinks as the focuser approaches perfect focus.  The focuser continues to move which causes the starsize value to rise up again.  Once this algorithm completes I then fit a quadratic equation to the data and solve for the minimum value.  This value gives me the focuser position needed for perfect focus.  I then reposition the focuser to that value using an anti-backlash technique.

For the QHY294C I wrote a program to display live video from the camera to support this focusing technique.

I was able to get the gentleman who wrote DIGICAMCONTROL to incorporate the "starsize" calculation into the ASTRO module in his program.

I suspect your approach will be to hold the controller for the focuser in your hand while you watch the liveview display on your camera.  You will need to zoom in to do this.  There is lots of information out their about needs to refocus several times during the evening.  So far I have never needed to do this.  My program analyses every photo I take and one of the parameters it spits out is FWHM.  I have a trend of FWHM running while I am imaging and it bounces around but never seems to trend upwards very much.  It's very difficult to assess FWHM because guiding issues and flexure will cause FWHM to increase...both of these have nothing to do with focus.

I'm sure you will enjoy having a motorized focuser...much easier to achieve accurate focus.

Peter

[rockw...@bell.net]

Hello Peter ,

Thank you again for the detail in your replies , this is always very much appreciated .

As to the Focuser , yes , Celestron has now Updated the initial hardware release and it appears more reliable than the original . Also , the SkyPortal App , and SkySafari , on the iPad  which I use , now has Focuser Control .

I had been following James Lamb's Videos in which he has put the Celestron Focuser through some testing and had also determined a very small change in position versus Temperature over time . Good news .

https://www.youtube.com/user/Aero19612/videos

He has also done some other work regarding the Focuser and "special" algorithms although I don't see the same depth of attention that you have been working to or providing .

At this point I would probably want to ask about Collimation and how you do it . Have you Installed "Bob's Knobs" in place of the Philips Screws ? Do you use an Artificial Star or a real one . How often do you Collimate ?

Maybe a Topic for a new Thread ?

Cheers ,

Scott.......

[Scott Kuchma]

Hello Peter ,

I've come back to this Thread as I had remembered your conversation regarding control of your Focus Motor and since I've been re-looking at the Celestron version , and all the possible controlling Software's , I'd like to ask a question , or two .

First , when I was still doing Spectroscopy Instrumentation Servicing , we had several scanning Spectrophotometers all of which seemed to be able to circumvent their need for backlash compensation simply by their approach to Peak finding .

When scanning for Emission Peaks , the hardware would always scan from highest wavelength to lowest . Once an Emission Peak was registered the mechanism would return to a position above the marked wavelength and scan down once again but at reduced speed . After identifying the Emission Peak position again , the mechanism would once again move to a higher wavelength and then finally microstep down to the identified wavelength position of the Emission Peak . This was done , apparently to minimize , or eliminate , backlash and reproducibility errors in tracking specific areas of the wavelength spectrum . It worked really well . Specs on the High-end units were +/- 0.005nm .

I've been trying to find out if any of the Focus Motor Control Software Programs do anything like this rather than the current method of peaking from either direction and having to determine a backlash compensation value for a particular Focuser .

Would it not make more sense to have a Focus Motor Controller perform a FWHM calculation after approaching a target focus from the same direction ? See the lowest FWHM value , back away and approach from the same direction but only slower , and then maybe make a final approach at the slowest or smallest step count available . Am I making myself clear on this ? I'm not sure .

Just some thinking out loud .

Scott...........

[wols...@gmail.com]

Scott,

My program steps the focuser thru a range in 10 to 20 increments.  The "starsize" or FWHM values are calculated at every increment.  Once the sweep completes my software does a curve fit of the data to mathematically determine the optimum focuser position that should yield the smallest starsize.  Then I return the focuser positioner to it's original starting point and finally advance the focuser to the optimum position which addresses any backlash.

I have noticed that if I leave the "starsize" calculation running continuously while the focuser sits at the optimum position the starsize values rise and fall over a significant range because of atmospheric seeing.  Because of this I believe that you can't slowly creep up on the optimum focuser position because the seeing is constantly changing.  Better to gather data over a wide range and then calculate the optimum position.

Peter

[Scott Kuchma]

Hello Peter ,

Excellent , I expected nothing less from your design and implementation . My challenge now is to try and find out how Programs like APT or NINA perform their Focus Routines and whether or not it can be manually overwritten and controlled .

I think I'm building a list of things to do during the Winter .

Did I mention my Telescope fell over , on me thankfully , and everything survived . The clamp on one of the Tripod legs gave way and it tipped over . Celestron is sending me a new leg gratis .

My plan is to take the leg apart , this Winter , and see if I can replace the broken plastic clamp with possibly a brass equivalent . I now have the legs minimised on the tripod as I can't trust the other two .

Never ends eh ?

Scott..............