Skip to main content

QHY600 tests

13 posts / 0 new
Last post
HQA
HQA's picture
QHY600 tests

Since there seems to be considerable interest in CMOS sensors, I thought I'd give you a blow-by-blow account as I test a new QHY600 camera over the next week or so.  The OC61 (Optical Craftsman 61-cm) telescope node of AAVSOnet is located at Mt. John, New Zealand.  This telescope is a true Cassegrain, with a final focal ratio of f/14.6.  When we upgraded this system to robotic operation about a decade ago, Robert Ayers contributed his FLI PL09000 camera with filter wheel.  It has been a workhorse for us, but suffers greatly from Residual Bulk Image (RBI) effects.  These latent images require an LED preflash before every exposure to "wipe" the array of the RBI from prior images.  The preflash dramatically increases the noise level in the images, such that we are probably losing a magnitude on the faint end for photometry.  We needed this big sensor in order to get a reasonable field of view.  Even with this 52mm diagonal sensor, we only have a 14x14 arcmin FOV, and have to bin 2x2 to yield 0.55arcsec pixels.  I've seriously considered adding a focal reducer, but haven't found the right product yet.

Dick Post has generously funded the upgrade of the camera system to the QHY600.  We've also purchased the 7-slot 50mm square filter wheel to go with this, so that we can re-use the existing BVgri filters.  We now have 2 empty slots that need filters!  Over the next week or so, I'll test this camera in my lab, so that I know its characteristics before shipping.  Hands-on control works much better than remote testing!

While the QHY600 (IMX455 sensor) has 9576x6388 effective pixels, each is only 3.76 microns in size.  That means to yield the same 0.55arcsec/pixel scale, you would need to bin about 6x6!  The QHY600 only supports 2x2 binning in its ASCOM driver.  We will probably bin 2x2 to reduce the stored image size to 15 megapixels, and then transfer these images back to HQ for calibrating (dark subtract/flat field) using our pipeline.  Somewhere along the line, we'll probably do a further stage of binning.  The site can have 1-2 arcsec images, though most are 2-3 arcseconds.  How to handle this best in software will be a challenge.

Note that, while the pixel size is small, each pixel has a pretty decent full well depth.  QHY says you can get up to 80Ke-, but that depends on a lot of factors.  You have three different imaging modes, and can set the gain and offset for each mode.  You can also include or exclude overscan pixels, and change the USB transfer rate to lessen interference.  Lots of knobs to twiddle, and each affects the full well depth and read noise!  The mode we're choosing gets about 50Ke-, which is still pretty good, along with 3.5 electrons of read noise.  However, this means if you keep a 16bit FITS file output, something has to give when you bin.  If you do the binning entirely in software, say in MaximDL, you can store the output image in 32-bit floating point and not lose any precision.  This adds another layer of complexity.  For the time being, let's assume 2x2 binning and 16-bit FITS storage to keep things simple.

This sensor is only 42mm diagonal, so 50mm round filters could be used with it, but we're sticking with our original filter set.  However, the field of view is even smaller - about 14x9arcmin.  A focal reducer/field flattener/coma corrector would be really nice.  One big advantage with the IMX455 sensor is that it is back-illuminated and has greater than 87% peak QE according to QHY, compared with the 64% QE of the KAF09000.  Combined with the lack of RBI mitigation, we're expecting to obtain about 2 magnitudes of improvement with this camera, along with lots of other nice features, such as very short exposures and very fast readout time.

This is a USB3.0 camera that can take around 2 frames per second, so very high transfer rate.  Not all computers can handle this, and extending USB3.0 cables is tricky.  The Kepler KL400 camera from FLI is an example of a camera that doesn't work with all USB cables.  I've asked Nigel Frost, the Observatory Superintendent, to give me the needed cable length, and then I'll configure the system here and confirm that it works before shipping camera/filterwheel/USB3cables/etc. down south.

So at minimum, here are the upcoming tests:

- unpack the camera and filter wheel

- test basic operation with the computer and cable that will be used in New Zealand

- test gain and readnoise of desired operating mode

- test linearity and full well

- test dark current, hot pixels, and cosmetic defects at several different operating temperatures

- look for bias stability and whether to use overscan

- on-sky tests for RBI, squareness of sensor to optical path, etc.

- anything else that comes to mind

The next post will describe the unpacking and basic operations of the QHY600.  If anyone has any questions/comments/suggestions, please feel free to post.  I do not profess to know everything about the camera, nor assume that I will do every important test!

Arne

 

Richard Berry
Richard Berry's picture
Excellent. 

Excellent. 

I am planning to create a "Best Practices Guide" for CMOS those interested in acquiring a CMOS camera, but I think this merits a separate guide on "receiving and testing any new camera." Please take some good photos of your testing setup.

Meaning, noting that the Forum has hosted repetitive and redundant thread on photometric filters, I assembled a "Best Practices Guide" for photometric filters, and am looking for commnets and corrections before posting it on the Section page:

https://www.dropbox.com/s/4vfv1vpad763awi/AAVSO_Instr%26Equip_Photometri...

These compilatations are intended to be short and sweet. In this compilation, you will note your own words coming back to haunt you. 

--Richard

 

msheald
QHY600 Tests

Thank you for you work! I look forward to your results. Best regareds.

Mike

CrossoverManiac
CrossoverManiac's picture
The OC61 (Optical Craftsman

The OC61 (Optical Craftsman 61-cm) telescope node of AAVSOnet is located at Mt. John, New Zealand.  This telescope is a true Cassegrain, with a final focal ratio of f/14.6.

and

While the QHY600 (IMX455 sensor) has 9576x6388 effective pixels, each is only 3.76 microns in size.  That means to yield the same 0.55arcsec/pixel scale, you would need to bin about 6x6!

Sounds like they would be better off with camera with a KAF-1001 CCD sensor.  That would be a perfect match for the 0.55 arc-second/pixel scale though the FOV would be 9.26' × 9.26'.

bskiff
FIlters "best practices"

Thanks, Richard, for the link to your notes about detectors and filters. Trvially:  do note that Mike Bessell has two el's in his surname --- it is mis-spelled all over the literature and in observatory instrument manuals etc.  (The famous Bessel-with-one-l was the mathematician...)

     I wonder if the advice sought in re filters centers on what filters are appropriate for what objects.  Objects like asteroids are grey (have essentially no color variation), so running unfiltered is okay as long as you choose comparison stars that are similar in color to asteroids (roughly 0.6 < B-V < 0.95 or equivalent ranges in other systems).  Beyond just the rotation period, one does prefer to be able to use the data for matching with other data, determining the phase-function, etc, so one might want to use an Rc or Sloan r' filter (to maximize sensitivity), and adjust the data to the standard system.

     I also agree that for instances where you want merely a raw detection, or the on/off state of some transient target, running unfiltered is OK.  But even so one might want to adjust the zero-point at least approximately to (say) Sloan r' so that things can be compared with other results.

     For stars, I agree that just having a V filter is the best single filter.  In principle of course one needs to observe in two filters to get a proper V magnitude because of color terms.  Either B,V or V,I would be preferred.  For most stars, rather generally, the preference would be for B,V,I photometry to get color changes as the stars varies, either from pulsation (RR Lyraes, Cepheids, Miras) or to model component temperatures of eclipsing binaries.  Those three filters give you the leverage needed for those determinations.  I would argue that Sloan z', another 1000A longward of I, is even better if the detector is sensitive out at ~9000A.  (Going back to asteroids, it turns out you get a fair estimate of the mineralogy of an asteroid from Sloan g,i,z.  The g-i color-index gives you a color slope, and i-z measures the depth of the pyroxene band (in the z filter), which together are very diagnostic of the overall composition.)  Probably the hardware situation is such that if you have more than one filter available, then you can do three.  My argument would be to always take data in at least two filters if possible so that color information and consistency checks are available (whatever happens in one filter needs to show up in an expected way in data taken with another filter taken at nearly the same time).

\Brian

Richard Berry
Richard Berry's picture
I'll intergrate your comments

I'll intergrate your comments to some extrent. Bert sent me a document that will be the basis for a Best Practices Guide on what filters to use for what type of observation, and I'll integrate more or your noters there. Thanks!

Richard

 

HQA
HQA's picture
QHY600 out of the box

Sorry about the delay for the second post.  I wanted to test the camera as it will be installed in New Zealand.  The Observatory Superintendent there measured the distance from the telescope back end to the control room.  While we could put the computer physically mounted on the telescope, it is then subject to the ambient conditions, and things can get pretty dicy during the winter.  To make things easy, I wanted to extend the USB3 cable back to the control room.  Nigel says it is 11.5 meters, so I purchased the Tripp-Lite U330-15M 15m extender cable.  Afterwards, I realized that I probably could have used Tripp-Lite's U330-10M 10m cable, but this gives a little flexibility.  Anyway, that cable just arrived, and so now I can test the camera properly.

I'm including a bunch of photos and images as I go along, so that you can see what you get.  The QHY600 Early Bird camera comes in a very nice 30x24x17cm cardboard box, with everything nicely separated and cushioned.  The first 3 photos show the box and its contents.  Each of the small boxes contains things like the 12V 6A TEC power supply (other vendors make you buy this separately), a female dovetail and several spacers.  I can't think of anything else that you would need to run this camera.  You can either mount it with a dovetail (preferred), or M54 thread.  It comes with an M54 to 2" nosepiece.  A photo is included showing the back end of the camera.  They supply a short jumper cable that has a threaded 2.1mm plug to firmly attach to the camera.  The other end of the cable is a 2.1mm female connector to attach to the power supply cable.  A supplied 2m USB3 cable normally attaches to the computer, though in our configuration, I'm going to use a 1m USB3 cable to attach to the Tripp-Lite extender.  There are two fiber connectors for running the 10Gbps fibers, if you upgrade to the professional camera later (it gains you about 2x transfer speed, so that you can do 4fps instead of the nominal 2fps readout).  Note, however, that using the 10Gbps fibers, you will need a standard desktop computer with a PCI fiber board.  A 4-pin GPIO socket is available, but without any pinouts or documentation.  There is a connector for a QHY filter wheel; more about that in a subsequent post.

The Tripp-Lite U330 extender will provide up to 388ma of current.  They include a 1.35mm jack at the camera end for inserting 5V if that amount of current is insufficient.  In that case, you have to purchase a separate 5V 2A supply.  The maximum data transfer rate is 5Gbps.  Each IMX455 image is 120MB, so 2fps requires 2.4Gbps, below the maximum.  Note:  not all USB3 cables, and USB3 extenders, are equal.  Some cameras, like the KL400, are very picky as far as what kind of cable will work with them.  QHY and ZWO are far less sensitive, but be prepared to try two or three cables until things act right.

There is a software driver/ASCOM/EZCAP "System Pack" that is the best way to download the necessary drivers.  Look around for this on the QHY web site; it is not always obvious.  EZCAP is their image acquisition package and is useful if you don't have MaximDL or want some specific features not available in MDL.

After installing the drivers, I connected to the camera over the 15m extender - yay!  I downloaded a quick bias frame, and the image transferred in less than a second, and looked normal.  Sorta like first light with your telescope!

Turning on the TEC cooler, it looks like you can get about 30C of cooling.  The lab was at 22C, and at -10C, the system was using 83% of power.  According to Maxim, the temperature was stable at the 0.1C level with a reasonable time constant for corrections.

I first did a couple of test darks.  Using a 300-second exposure time and the included camera-lens cover, I obtained the image dark300a.  This is shown in inverted gray scale, so that dark means brighter.  It is easier to see defects this way.  Note that there is a low-level vertical streak in this image.  I then additionally covered the front of the camera with black cloth, and took dark300b.  Note that the streak goes away.  It is hard to prevent light from getting into a camera, so be aware that you may find streaks on long darks unless you take precautions.  I always do my darks at night in the closed telescope enclosure, and usually also cover the telescope tube or use a blank filter.  This is one "defect" of CMOS cameras - they usually do not include a mechanical shutter, relying on the readout method to give an electronic shutter.  This works for most exposures, but definitely not darks.  You need some mechanism to keep light away from the sensor.

Looking at dark300b, there are a couple of things to notice.  First, there is no amplifier glow.  Earlier CMOS generations have amplifier glow, and even the FLI KL400 sCMOS camera that Gary Walker has suffers from this effect.  In general, if you have amplifier glow, you can subtract off a dark frame and the glow will disappear.  However, the NOISE from that glow remains, and so there will be areas of increased dark current noise near the sensor edges if it suffers from amplifier glow.  For the QHY600, this issue does not exist.  I see a lot of hot pixels that I haven't quantified yet.  The hot pixel pattern stays the same and so is inherent to the sensor and not related to the readout method.

Because there are hot pixels, I'll do more dark frame testing than I do with other sensors.  How many hot pixels exist?  How many saturate at 300seconds, typically the longest subexposure that I do?  Is the pattern truly fixed from frame to frame?  Does the flux in each hot pixel scale with temperature?  How does the bias level change with TEC temperature and ambient temperature?  You may not need to know this level of detail for your specific camera and use, but I like to know everything I can about a new camera.

The next post will describe setting the gain/offset/read mode, as well as the dark current tests.

Arne

Eric Dose
Eric Dose's picture
Arne: this is stupendously

Arne: this is stupendously helpful. The dark images are good news; let's hope the hot pixels get better over time with their manufacturing experience. I'll be very, very interested to learn how linearity depends on settings.

Question to all you CMOS filter wheel vendors: for dark images, why in the world don't you just include a cheap black filter? That is, one that is guaranteed to fit perfectly that very wheel, won't leak light, won't warp, etc in cold or heat. It wouldn't cost you $0.25 US, and every single CMOS is going to need one.

 

CrossoverManiac
CrossoverManiac's picture
I have a black filter and

I have a black filter and light still gets in it.  It's only good for additional protection while taking dark or bias frames.  So, test your black filter before assuming that it will block all incoming light going into your sensor.

Eric Dose
Eric Dose's picture
That's why CMOS user will

That's why CMOS users will have to take darks at night.

But if your black filter leaks light enough to matter, then you have a bad black filter or a bad filter wheel design.

HQA
HQA's picture
blank filter

There are several blank/dark filters on the market.  I've purchased a sampling and am testing them.  They are helpful, but not perfect, which is another reason for doing darks at night.  The main reason why you might not want one is that they take up a filter slot.   I always seem to need one more filter. :)  The E-180 astrographs we are using on the BSM systems have a nice tight tube cover, and the older refractors tubes were easy to cover - if the telescope was in your back yard.

There are some good reasons for using a blank filter.  As an example, say that the bias level changes with ambient temperature, then you may want to take bias/dark frames before/after science frames.

I'll discuss filter wheels after the camera tests.

Arne

lmk
lmk's picture
That F/14.6 is extremely slow

That F/14.6 is extremely slow for imaging! So, its too bad the telescope itself is the issue down there. If its a classic Cass with parabolic primary, maybe eliminate the secondary and place the camera at the prime focus, with a Paracorr?

Mike

msheald
QHY600 Darks

Hello! I'll be curious to read about your Darks analysis.

    If I remember correctly, there had been concerns raised with CMOS that a Darks library prepared ahead of time might not march the actual images taken on later nights as well as CCD imagers. Best regards.

Mike

Log in to post comments
AAVSO 49 Bay State Rd. Cambridge, MA 02138 aavso@aavso.org 617-354-0484