New 16mp ZWO camera

[glend]

I am far from technical on this topic, but they maybe waiting for sCMOS (Scientific CMOS) development to commericalise. There is one example of a commerical sCMOS chip already available: http://www.scmos.com/

A summary of sCMOS development and goals:

http://www.photonicsonline.com/doc/scientific-cmos-scmos-technology-an-overview-0001

The ASI 1600 has low noise and sensitivity improvements, and the high USB3 and frame speeds, but sCMOS should be a bigger leap I would imagine. I don't know where the cross over point lies.

Bert, I think there are some 2x2bin examples in the Cloudy Nights Beta Test thread.

[Shiraz]

Sounds like an excellent idea, with one minor issue.

I recall reading (somewhere) some ZWO advice that the chip falls back to lower bit depth on binning. Haven't tried it, but even if it is so, you could still use it effectively, because the read noise is low enough for software binning.

Depending on where you set the gain, in software binx3, you could have effective pixels with 11.4 microns pitch, read noise ~ 9e and well depth of ~180,000e. The minor issue would be that you would have to store and process 9x as many subs as you would with on-chip binning.

[Slawomir]

Has anyone tried running say a 10-minute dark to check for distribution of ADU values in such dark across the chip? It would be nice to see what happens during longer exposures for those planning to use this camera for narrowband imaging :)

[Shiraz]

I haven't yet Suavi, but 5minute darks dropboxed from a CN post show total underlying noise, (including read and dark) of less than 3 electrons RMS across the whole field. Startling really - it is weird to view a frame with almost zero noise.

[glend]

There have been long darks run by the Beta Testers on Cloudy Nights. ZWO offers a 5 minute dark link on the product page for the 1600. I have run 5 minute darks myself to check on the rumoured long dark Amp Glow, which i could barely detect at that duration. Amp glow was explored on CN. Since i don't plan on running longer subs it didn't really concern me, and Sam's (ZWO) attitude when asked on the forum seemed to be that it was not significant to be a concern and was easily calibrated out. I believe ZWO released a driver update that reduced the amp glow further.
The narrowband subs i have been running are 60" subs, and i don't know that i would be too concerned about 10 minute performance with this camera.

[Shiraz]

further to that, people have been looking at "amp glow" by stretching darks and noticing some variation in the bias/dark current, probably due to variations in Peltier temperature. What people seem to be neglecting is that the ADU values represent the 12 bit signal from the chip, multiplied by 16 to give the 16 bit ADU values in the subs. The glow that everyone keep quoting is actually on the order of maybe one or two electron or so in 300 seconds - it is the sort of fluctuation that could well be present in all cooled cameras, but this is the first one that has low enough read noise that you can actually see it. Rather than being a fault, it is an indication of just how low the noise is in this camera.

[Slawomir]

Agreed.

Such low read noise will easily show the slightest gradients across the chip.

I measured the 300s dark from ZWO website, and the difference in mean ADU value between the darkest and brightest regions in this 300s dark is 26 ADUs, so indeed very low in electrons.

For reference, I attached a result of an extreme stretch of the 300s dark from ZWO website.

[Shiraz]

A far better way to analyse the darks is to use the local SD (excluding outliers). This will provide an idea of the shot noise due to the dark current and you won't pull in any fixed bias structure (which will be subtracted in calibration).

The dark on the ZWO website was taken at an inverse gain of 5, so the difference that you measured in mean values is 26*5/16 or 8 electrons. This is more than that in the CN darks and it could mean an excess noise of nearly 3 electrons RMS if it is dark current and not just bias shift - that is significant, but it would still not be measurable in almost any other camera. To get some idea of the significance of this sort of signal, how much background sky signal (electrons) do you measure with your 3nm filters?

[Slawomir]

No doubt the supplied dark has extremely low noise, but 8 electrons variation will in some cases (imaging faint nebulae) need to be corrected with darks when using the camera for 5-minute or longer subs in narrowband imaging. Also, since noise goes up with signal, even after applying darks there will probably be somehow higher noise left in those brighter areas?

I am sorry if I am too particular and also too inquisitive, but I like doing my homework before buying. Also, I am specifically interested in this camera's performance in purely narrowband imaging because of intense light pollution in my area plus I simply like narrowband imaging :)

EDIT: Will need to measure background signal in my subs.

[Shiraz]

Crikey, there is no need to apologise for digging into the detail - too much stuff gets glossed over and then comes home to bite after a purchase is made. The narrowband potential of this camera could be very interesting and it would be great to know how significant the possible "glow" is compared with your sky signal.

edit: just scaled the darks that I do have. Most of the image has negligible dark current at -15, but two fairly small areas have some "glow", that would amount to about 20 dark electrons at the brightest point over 10 minutes (~0.03 electrons/s). That will give excess noise of up to 4.5 electrons RMS in one corner (for comparison though, that much excess noise is a bit less than the read noise from my 694). The rest of the dark has effectively no dark current. I don't anticipate that this will impact significantly on my images, but agree that about 3% of the camera is not quite as good as the rest of it for narrowband. Must measure at 10 minutes rather than scale and also try it at a lower temperature to see if that helps.

[Slawomir]

Thank you Ray for helping me to get a better understanding of functioning/parameters of the new ASI camera :thumbsup:

Actually I have never measured background signal before, so it was interesting to notice that in my 10-minute subs captured with 3nm Ha there is 102 ADU of background signal give/take a few ADUs. Gain is 0.26. That's a lot of unwanted signal! :lol:

Also, while I had my camera powered up, I wanted to see how a 300s dark from my current camera compares with the one from ZWO's website, so I just took a 300s one and did a bit of measuring on both using stats tool in PI. By no means I want to judge which one is better, I simply want to know how things are shaping up with the newcomer from ZWO. I can see that AVD, MAD and mean ADU values differ for both cameras, but I am not sure whether these should be somehow scaled to be able to truly compare the data?

Anyway, here are the results I've got:

AVD = Average Absolute Deviation
MAD = Median Absolute Deviation


ASI1600
entire 300s dark at -25C (from ZWO website)
Mean 154.3
AVD 14.9
MAD 23.7
Min 17.0
Max 23937.0

QSI690 (gain 0.26)
entire 300s dark at -25C
Mean 502.9
AVD 13.2
MAD 11.9
Min 419.0
Max 25952.0

ASI1600
a small central area of a 300s dark
Mean 152.7
AVD 14.1
MAD 23.7

QSI690 (gain 0.26)
a small central area (the same size) of a 300s dark
Mean 503.2
AVD 13.2
MAD 11.9

[Shiraz]

Thanks very much for the info Suavi.

if you wish to do a direct comparison, I think that you need to get all of the data into electrons and account for the different read noise (the 1600 at the gain used for the ZWO dark has >3.5 electrons read noise). Actually, thinking about it, an apples-to-apples direct comparison is likely to be quite difficult/impossible - there are just too many variables with the 1600. eg, setting the gain on the 1600 to give similar characteristics to the 690 may not be optimum for the 1600. Nonetheless, your results at least show that the two cameras are not different by orders of magnitude, so there is nothing drastically wrong with the 1600.

If your NB background is 100ADU at 0.26, you have 26 electrons sky background. That is more than the brightest dark current region in my 1600, so, for reasonable QE in the 1600, sky noise in your system would overwhelm much of the extra noise from the "glow" in a 1600 - should you ever decide to try one - but why would you with your nice camera.

edit: I am surprised that the MAD values do not change with region selection - not sure what that means.

[glend]

Ray are you using SGP to run the ASI1600? I am using SGP with absolutely no issues, but apparently the CN guys are having problems with it failing. I am still using just the supplied usb3 cable but those guys have powered hubs and active cable extensions etc. I have found SGP is fine doing multi-layered sequences, with filter swaps ahead of shooting lights, swap again, etc all unattended. Framing and focus is causing crashes so they say, yet i have no such issues. Strange.

[Shiraz]

Glen, I haven't been able to get SGP running smoothly with the 1600 yet - it all seems to be USB related (slow downloads, inability to use USB2 etc) and I hope the latest setup using just the supplied USB3 cable will do the job (testing tomorrow night). I initially set it all up with Nebulosity and am glad I did - that has worked OK, with the exception of the focusing routine.

I had hoped to just plug the new camera into the existing USB2 hub and accept slower downloads than the maximum that the camera is capable of - but that didn't work at all. I guess that my current H694 generates about 1mpix of data per second, whereas the 1600 can generate up to about 400mpix per second, so it is not all that surprising that there are some teething problems on changing over. Hopefully ZWO will put in a bit of time making the camera play nicely with USB hubs and extension cables, but at least there are some mixes of hardware and software that work reliably in the meantime.

[Shiraz]

for info, tried using the 1600 with cooling off (eg as you might use for planetary). Nebulosity objected to the data generated at high gain with the standard 21 offset and I had to increase offset to 50 to keep the noise from driving the ADU values into negative territory.

[Slawomir]

Thank you Ray, that makes sense. As for MAD values, I read somewhere that MAD is a more robust indication of noise than AVD or in particular SD, so perhaps that's why there is no change up to one decimal point and perhaps both darks are very even in terms of their ADU values across the chip:question:

[lazjen]

Is there some inherent reason I'm not aware of for planetary imaging that using cooling would not be advantage? That is, why not use the cooling if you've got it on the camera?

[Atmos]

What Ray may be getting at is that there is both and cooled and uncooled version of the camera, many planetary imagers end up using uncooled cameras.

[Shiraz]

Dark current is of no consequence with bright objects, so cooling is not necessary. Turning off the fan will remove any possibility of fan vibration messing up high res images.

[glend]

Ray i had some problems with Frame and Focus in SGP. Found that if using the loop mode it seemed to over-run the SGP buffer and freeze, but if you use Take One it worked fine. With short framing shots it seemed the next one was trying to download before the previous one had been processed and displayed by SGP. I went to 5" Take One and it works fine. And of course you just push Take One again to get the next one, that delay seems to be all that is needed. No other problems.

[Shiraz]

most of SGP has been running OK tonight, except for the focuser, which worked once and then refused to function again - I had the 1600 on its own USB3 socket, but it still managed to interfere with the stuff running off USB2 (or that is what appeared to happen). I wish I knew enough to understand what is going on.

[glend]

Ray there is a thread on CN about SGP and the 1600. Sam from ZWO jumped in and gave an explaination on how the 1600 uses and manages usb3, worth reading.
Also Rista seemed to traced his SGP hang problems to his habit of paging through collected images while a sequence was running, something i do not do. I suppose having lots of memory and storage encourages turning everything on. Coming from a programming background when memory and storage were very limited, i tend to do one thing at a time using as little resource as i can.

Some of their (CN's), testing seems to drifting towards exploring the limitations of the camera in areas like 3nm narrowband subs of 900s+ duration at zero gain. I guess if you suffer under extreme light pollution that might seem to be a good idea but no relevance for me. I like to be able to shoot reasonable narrowband with 60" subs. Certainly points out the flexibility of the camera i suppose, but their maybe others better suited to that operation mode.

[codemonkey]

I think it's the opposite, actually. I image in fairly dark skies with a reasonably low read noise Sony sensor, and I would have to be doing insanely long exposures with 3nm filters to not be read noise limited. There's no point in high light pollution scenarios because you swiftly get past the "read noise limited" point, and once you have, it's just about total integration time.

In other news, looks like the Trius is now sold, so I'll hopefully have a 1600 on the way soon.

[glend]

Yeah, i admit i don't understand the reason behind it, i assumed it was because of his light pollution situation. And we all know about assuming......

Glad to hear about the camera news. A novice like me needs all the experienced help he can get. I am sure you will enjoy it.

[Atmos]

Just did some quick calculations, the difference between the 1600 and the 694 (674 as well as it is just a smaller version) with 3nm narrowband filters is negligible. The 1600 has lower read noise at gain 0 (3.6e- vs the 4.8e- I get) but also has smaller pixels (3.8 vs 4.54 microns) and a lower QE. Both cameras will require the same amount of time to reach read noise limited under the same situations, with the 1600 at gain 0.

[Camelopardalis]

But...but...but...why would anyone want to image at gain 0 :confused2:

[gregbradley]

To prevent highlights from blowing out in a long exposure perhaps?
From what little I have seen of this camera it seems to be its Achilles heel.

Greg.

[Atmos]

As you increase the gain it does drop the read noise but the overall dynamic range drops with it. i.e. the read noise falls slower than the decrease in well depth.

Yes you can image at gain 300 with 1s exposures in Lum (gregbradley noted that it clipped the core of M51 even at 1s). Using a 3nm Ha filter, if you can drop the read noise to 0.6e- you need ~50s exposures (at F/5) to be RN limited but your well depth is so shallow that even at that exposure time you're clipping.

To give a bit of a comparison, at gain 0 (where the 1600 has its highest dynamic range) compared to a KAF-16803 on the same telescope, they need about the same exposure time to become RN limited. This is given that the KAF has a RN of 8e- (I believe that RickS mentioned a while back that this is what his PL16803 gets at SRO), this is within a margin of 10% (the 16803 reaches RN limited a fraction quicker without taking dark current into consideration but the 1600 is likely to be lower in that regard) . The 16803 has 5x the well depth however so while the 1600 will clip stars and bright cores (thinking of lagoon, M31, M42 ect) the 16803 will barely notice the difference.

[glend]

Main Sequence Software has a fix for the SGP crash issue and will release a patch in a few days:
http://www.cloudynights.com/topic/539390-scg-crashasi-1600-flats-cannot-save-file/page-5#entry7260667

[codemonkey]

Might just be so they can compare its performance using more traditional sub lengths? I dunno.

Cheers mate, I sure hope I do enjoy it.



Not sure if it's me just misinterpreting your wording or if there's a misunderstanding, but you start off read noise limited and increase sub length to try and overcome that, rather than "reaching" it.

It's also a bit hard to compare the performance of those cameras based off numbers alone because we still don't know the absolute QE.



That's good news!

[Atmos]

You're right Lee, I did mean sky limited not RN limited. I had the same idea in my head, just the wrong wording :P
Looking up the sensor that goes into this camera, used in a bunch of Olympus models, it appears to have an peak QE of 57%. This puts it on par with most of the front illuminated KAF sensors.

[codemonkey]

No probs :-)

Only thing about that absolute QE is that it's a OSC version of the sensor, which will obviously impact the QE. I'm not sure how consistent the difference in QE between mono and bayered variants is, maybe it's sufficiently consistent to get a good idea, but without further information I wouldn't like to guess.

[glend]

Were those mono sensors? As far as i can determine Olympus did not make a dslr with the mono version of this Panasonic sensor. Sensorgen has figures, as do other sources like DPReview but they are all for the colour sensor. The Relative QE charts i have seen do place the 8300 and 1600 very close but the 1600 is ahead on lower noise and slight better QE in the middle of the spectrum. Still even if they were equal on all aspects of performance, the 1600 is over $1000 cheaper than the lowest cost 8300 camera. I have to wonder how long Atik and others with 8300 cameras can maintain a big ptice premium.

[Atmos]

I don't believe that the absolute QE really changes between OSC and mono but it is correct that these are the first mono series of this particular sensor.

Comparing the 1600 against its closest rival, the 8300, the 1600 at this stage appears to be better in virtually every respect. It has shallower wells but much lower read noise rendering it with a much higher dynamic range. As you point out Glen, it is also FAR cheaper than any 8300 on the market.

The 8300 is more expensive because the CCD technology is more expensive to manufacture but I am with you, I don't know how much longer this particular one will last into the future. Probably until the 1600 proves itself to be a reliable replacement

What I was getting at with comparing the new 1600 against a 16803 is that it isn't a replacement of noisy KAF sensors :)

[Cimitar]

:eyepop: I go away for a few days and there's an extra 4 pages in the thread! Time to get comfy and start reading! :P

In all seriousness though I am thoroughly enjoying reading this post. Really appreciate the effort Glen, Ray and others are going to with sharing their first experiences with the ZWO and other relevant cameras.
Thanks guys! :thumbsup: .

Now... I wonder where I put my piggybank :question: ;)

Cheers, Evan

[Camelopardalis]

Isn't blowing out the highlights always going to be a problem with chips with increasing sensitivity? I'd never thought of sensitivity as being a weakness before :lol:



So is the clipping stars a problem a result of the dynamic range/well depth or the sensitivity?

It seems that we all want the perfect chip but this isn't it, but then nothing ever will be. The 1600 sounds pretty impressive, my perspective being to use it as an alternative to an uncooled DSLR and more expensive astro CCD.

Have we figured out a way to get more than 12-bit data from the camera?

My angle is how we may need to adapt the way we image to the CMOS generation.

[Shiraz]

get as much bit depth as you want by stacking:
1 sub = 12 bits
2 subs = 13 bits
4 subs = 14 bits
8 subs = 15 bits
16 subs = 16 bits
etc...
since you can do hundreds of short subs, the sky is the limit. 12 bits is not an issue at all

just stacked 19x 30 second subs and 10x 60 second subs of m83 to see how much of an SNR hit there was going to the shorter subs. I was using gain 100 and calculated that 1 minute should be about right. Images below show a linear mapping of the bottom 1000 ADU for the 30sec and 2000 ADU for the 60 seconds - no attempt was made to non-linear stretch, so everything bright is saturated.

Looks like the calculations were about right - the 60 second data looks good, but the 30 second data is down a bit on detail (seeing was worse as well, but contrast is down a bit). I had thought that 20 second subs would be OK and it still looks that way, provided that the gain is pushed up to maybe 200 to get the read noise right down.
By the way, there was no calibration or processing of these images - the camera is as smooth as.

[glend]

I have just finished an unattended narrowband run on M16, SGP ran it all, including managing the cooling of the sensor to -25C at the start and warming it back to ambient at the finish. I checked on it once in a while, half expecting it to stop but no issues at all.
Captured 25 x 60" Ha, 25 x 60" Oiii, & 25 x 60" Sii, all shot at Unity setting (Gain 139, offset 21). Watched a few of the files come up on the display and the histogram did not seem to show any clipping, but i probably need to process the stacks to get a idea about that. I will stack and colour process tomorrow morning, should have the image up on Astrobin later. Beautiful clear dark night here, wish i had some RGB filters as the Helix is now in a great position, soon i will get to that.

[glend]

Finished a quick process on the M16 narrowband from last night. A number of problems (probably mostly due to me) with the resulting image. First, despite 25 x 60" subs of SII there just doesn't seem to be much of it there at all, could be this target but maybe it just needs more time. I can see it in the stacked SII image but bringing it out is almost impossible without destroying the image; so I have left the SII out for now. What I have posted to Astrobin is a Bi-Colour version (with Ha - Red, and OIII - Green). I tried a Hubble pallet and was not happy with it and it needs more work.

I know there is more there but am having trouble bring it out without making a mess of it.
These were shot at Unity (Gain 139, Offset 31 (I think or was it 21)). Looking at it now on Astrobin I am thinking the stars look too green and I need to turn the saturation down a hair but not now. The Astrobin histogram looks pretty pathetic. Generally I think it is too dark as well.

I will stick a small one on the bottom here but have a look at the big one and give me your opinions on how I could do it better:

http://www.astrobin.com/full/251644/0/

AStrobin detail page is here:
http://www.astrobin.com/251644/

[Atmos]

Should be enough SII there at 25 minutes. As a comparison, I have an even shorter integration, single 900s SHO (45 min total).
http://www.astrobin.com/full/245969/B/

[glend]

Yeah Colin, but you know what your doing! I will have another go at the Sii. It would be nice to see what you could do with these files. Maybe i should outsource my processing.

[rmuhlack]

Glen, the CN guys have been talking about this camera having a lower Red response than expected. If the QE is lower at the red end of the visible spectrum it could explain the poor response in SII

[Atmos]

If your SII actually looks okay without being combined then it is just a question of colour calibration. The SII when stretched can look pretty good but it is quite weak compared to the OIII and especially Ha. For instance, you may have an area with a pixel value of 3200 in red, 18000 green and 11000 in blue. It will appear a greenish colour, this is why a SHO when just combined looks largely green. The Ha signal is overwhelming.

The idea is that the SII (red) needs to be stretched far more to get the correct Hubble Palette. This is the reason for magenta stars, the red and blue get stretched more than the green for colour balance.

[glend]

Richard, in regard to the spectrum response, Ha is down there are well and I have plenty of Ha, Sii is not much further along. However, when I look at the spectrum chart on the ZWO website I can see that it is less responsive in that part. https://astronomy-imaging-camera.com/products/asi-cooled-cameras/asi1600mm-cool/

But since Ha is so good, unless the cover glass is a cut filter that is affecting Sii spectrum, then I am sure it is just something stupid I have done along the way. I have just been playing around stretching a single Sii sub and it has more signal than my stack of Sii appeared to have. Even on the SGP display I could see signal on individual Sii frames. I need to go back through what I did in DSS with that stack.

Uodate: looking back at my Trifud SII data it was pretty skinny as well when shot on equivalent integration times to Ha and Oiii. I will test tonight on M16 again running just Sii to build up more signal. Is there a 'standard ratio'?

[Shiraz]

FYI, the attached table shows predicted optimum settings for my 250f4 system for a 3hour broadband galaxy imaging session under fairly dark sky. Early testing shows that this may be slightly optimistic - 1 minute subs gave better results than 30 seconds at gain 100 in the real world.

The most interesting outcome is that the dynamic range holds up well up to gain 100.

[rustigsmed]

hi glen - I'd be keen to have a crack - mostly to check out the 1600 files and because the weather has been so bleak :sadeyes: I'm getting rusty.

[glend]

Thanks Russell, the three narrowband files are over 30meg each before i register them against each other. My Sii issue is probably just a lack of signal and i will attrack that tonight. I will see about putting a file in the file sharing box at Astrobin, so you can have a go.

[glend]

Ray perhaps i should drop my gain setting from unity ( g= 139) to g=100. I am shooting 60" subs on my test targets (nebs and such).

[rustigsmed]

cheers mate, yep s2 is always a pain.
just for info, I am considering the 1600 to match it with my goto dob (12" f5). the plan would be to still use the EQ8 (12" f4) and 694. but use the eq8 for Luminance (694) and colour gathering (1600) on the dob.
I am unsure on how narrowband would work on the 1600 with 20-25 second subs. so it may only be a rgb solution.

[Shiraz]

if you are shooting narrowband, maybe try much longer subs Glen. I haven't tried, but was thinking of using 5-10 minutes at about gain100, although 139 should be pretty much as good.

[Atmos]

Below is an example of signal strength of SII. The first shows them at their relative strengths to one another. The SII is a LOT dimmer than the Ha. The second shows SII under a normal stretch just to give a bit of an idea of how much it does get stretched.

The main thing to note that is of importance to you Glen is that more data does not change the relative signal strength. If you were to put another 10 hours into SII it would not make it brighter against the Ha, only make it smoother and less noisy.

[glend]

Thanks Colin, that's pretty much what i see, in the first pics. I was going to run some more tonight, based on Ray's comments. I already have 25 minutes of Sii, but could easily double it and see how it improves. The Signal is already pretty low noise and smooth so maybe it won't improve much but i will build it up abit.

[Shiraz]

just ran the model - guessing what gear you have, 5 minutes of narrowband should get you to the vicinity of sky-limited in average dark conditions. You will not have to stretch the data so much, but watch out for star saturation maybe.

[Atmos]

At unity a quick calculation put it at ~400s, this is equated against my skies with a 3nm Ha filter.

[gregbradley]

There absolutely is a QE difference between mono and colour. A large one.

The Bayer matrix is RGGB so every pixel has a coloured filter over it. The coloured filters between manufacturers have different transmission rates and the trend has been to increase the transmission rates to improve high ISO performance in digital cameras.

But using a KAF or KAI chip as an example (as they have published figures) say the KAF8300, the mono has a QE of around 56-60% (60% is the no cover slip version) and the colour is probably more like 25-35%.

So yes typically double or more QE than the OSC. Having used both a mono 11002 sensor and the colour version of it I can attest to this large difference in QE in actual use.

Greg.

[codemonkey]

To add an example to Greg's post, the KAF-8300 (http://www.ccd.com/pdf/ccd_8300.pdf) reportedly has the following QE specs:

QE red: 33%
QE green: 40%
QE blue: 33%
QE mono (with AR glass): 56%

One source claims a QE of 48% (http://www.sensorgen.info/OlympusOM-D-E-M1.html) for a dSLR that contains the OSC version of the ASI1600 sensor.

My guess is that "everyone" is probably right and it's close to the 60% mark, but I don't know enough about the hardware to be confident about that.

In other news, my 1600 has been shipped and should arrive by Monday.

Glen, would you consider uploading the master fits files for your eagle somewhere (e.g. dropbox) so I could have a play with it?

[glend]

Lee i am reprocessing now to produce FITS output files ( I had used TIFF as it was going to Photoshop).
Astrobin has a file sharing space that i can use. I will have a look. I would prefer to share the files as they came out of DSS and before i've had a chance to bugger them up, that way you get the real camera output.

[codemonkey]

Ah, sorry Glen, TIFF would have been fine. I was basically wanting the stacked, calibrated but linear images for SII, Ha and OIII.

In other news, apparently my camera has arrived at the post locker today, in Brisbane. Unfortunately I'm working from home so I can't pick it up until tomorrow... still, that was fast.

[glend]

Glad to hear your camera has arrived Lee.

Re the files, I have uploaded FIT files to Astrobin in the shared folder area; however, it seems I can't just post a link here, you have to be an Astrobin user so I can 'invite' you to the location. Do you have an Astrobin user id?
BTW, Astrobin does not seem to acept TIFF anyway, as I found out after I tried to upload the TIFF reg files as well.

Lee, if you, or others here are Astrobin users, then try this location:
http://www.astrobin.com/rawdata/privatesharedfolders/94/

You will be prompted for your user id before allowed to it but it should work if it allows you through. Not sure it this applies to folks that are just using the free facilities of Astrobin.
Make sure you read the note attached to the folder when you open it, as the subs are registered to produce these stacked output files, but the output files are not registered against each other at this stage. You would need to register the three against each other before further processing.


I looked at Dropbox but I don't want to add another monthly cost to my budget.

[codemonkey]

Thanks for going to all this effort, Glen. I'm surprised Astrobin doesn't support TIFFs for that. My username is leemr on Astrobin.

[glend]

In trying to get a handle on Sii sensitivity of the ASI1600, I had a look at the spectrum response chart and it would seem that, given Ha is right next to Sii on the spectrum (like within about 20nm) it should be able to pick up Sii just as well as it does Ha (which it does very well). So I turned to trying to find out if the AR cover glass has some sort of IR Cut configuration, that might be blocking Sii.
I asked Sam on the ASi1600 Product Q&A page on their website for some idea of the spectrum bandpass of the AR window. He has replied there and posted a spectrum for the window.
Link to the Q&A page is here,
https://astronomy-imaging-camera.com/products/asi-cooled-cameras/asi1600mm-cool/

and his response to the AR window question is down at the bottom (8 June).

and the spectrum chart he referred me to is here:
https://astronomy-imaging-camera.com/wp-content/uploads/AR-clear-window-300x122.jpg

So it seems there is no reason that the camera cannot pick up Sii at levels like that of Ha - provide the Sii is there to be picked up, or that you expose for long enough to gather enough Sii to bring it up out of the noise. I would have thought that my 23 minutes of subs was allowing adequate time.

Anyone want to nominate a 'hot' Sii target that I can use for testing?

[glend]

I will investigate further Lee, it maybe due to the fact that the TIFF files had a .req tag on the end and thus it did not recognise it. Perhaps if I renamed it, I will see.

[glend]

I think, with Lee's help, we have found the problem with Sii data acquisition in the M16 image. I picked the 19 Sii subs with the highest score and stacked them in DSS WITHOUT any Master Dark or Master Bias, just Subs alone. When I look at the resulting stack file, there is the signal! Plenty of Sii data there, even in 19 x 60" subs. I stretched it abit in Photoshop and I think I could just plug it into the image now. I believe the DSS dark calibration is scrubbing out the Sii data because it is so close to the floor, or the expected noise. So DSS is definitely doing something I don't want it to do. I might rerun the processing for all my data on M16 without dark calibration and see what I get.

Any DSS experts out there have any idea why inclusion of master darks and master bias in the processing would scrub out my data?

I am posting here a small example of the 19 x 60" Sii sub data, and the larger version on Astrobin.

http://www.astrobin.com/full/251736/0/

[rustigsmed]

not sure Glen but I am intrigued as to why it has colour (blue), perhaps there could be an issue in your settings relating to that (rather than greyscale)?

[glend]

It is blue because I colorised it blue, which is what I would do with Sii data in layering for false natural colouring - its just there as an example. It was originally grey scale when I opened it.

I have added the Sii layer to the M16 image on Astrobin and removed the old bi-colour image. Apologies for the slight misalignment on the stars, which result in not quite round shapes, I forgot to reregister the main files. Might fix that up in time but I suspect it would require going back to DSS and reprocessing.

[codemonkey]

I realised I'm probably going to need to use the flattener for my Esprit now that I'll be imaging with such a big chip. Looks like I'll need a couple of adapters from precise parts to hook it all up... about $432 to land them here :eyepop: Didn't factor that in.

[Camelopardalis]

Puzzled...your Esprit flattener will output M48 male...you should just need M48 female to M42 or whatever your filter wheel uses, and any appropriate spacers. Can't imagine it's any different for any other CCD :confused2:

[codemonkey]

I believe the flattener is M66 on the scope side and M62 on the camera side. I need it to sit between a Celestron OAG, and an Orion Nautilus EFW, and I understand spacing of flatteners to be critical (never needed one before, so I don't know how critical).

[Atmos]

Its all about getting the correct spacing between the flattener and CCD chip. A real PITA sometimes as everything has tolerances that add up!

[Atmos]

Some are not too critical, I believe that straight flatteners are more forgiving than a flattener & reducer. My last setup was maybe 1.5mm off and it was noticeable.

[codemonkey]

Cheers Colin. Was your last setup a flattener or flattener + reducer?

[Camelopardalis]

Ah OK, OAG, that makes sense. With my Esprit small deviations from the stated back focus are noticeable.

[Atmos]

I had a 0.8x Flattener, it worked really well but was quite sensitive to back focus.

[glend]

Guys, surely for testing you can live without a flattener?

[glend]

Lee one of the CN guys has probably been down that path, there has been alot of posts about Precise Parts, and the Esprit is popular over there. Might be worth some searching. Isn't there a local adaptor maker?

[glend]

Got through an amazing amount of subs last night despite the gusty wind conditions. The short subs enabled by this camera really makes marginal imaging conditions ( like wind) possible (imaging in the lulls). I ran over 150 narrowband guided 60" subs on NGC 6188 before midnight, while the door on the observatory was rattling in the wind. Not surprisingly the guide graph was not the best but it was saying on the chart for the most part. I was prepared to drop back to 300 x 30 second subs if conditions demanded shorter subs. . I was watching the subs on the SGP display, expecting to have to go shorter or shutdown but while some appeared wind affected most were fine. Of course under the old model of plus 300 second subs they would all be rubbish. The obs walls are fairly high and that helps but the top of the scope and light shield sticks up into the wind. I suppose the large trees up wind help as well. I expect i will have to page through all of these subs tomorrow (today) and get rid of any outliers, but even if only half are useable i will be happy.

[glend]

Main Sequence has released the promised SGPro update v2.5.1.15 to resolve the memory allocation issue that has affected some people using SGP to control the ASI1600. Release note here:



Fixing issue with large memory allocation
Implemented per-filter AF filter override. (for instance focus with RGB filters but then use override for narrowband)
Smart copy/paste for RA and Dec in the Mosaic and Framing Wizard and also the image plate solve hint dialog.

Link is here:
http://www.mainsequencesoftware.com/Releases

I have installed it and it was seamless.

[Camelopardalis]

Glen, fast refractors can have quite horrible field curvature, all the more obvious when testing a camera with fairly small pixels :D

[rustigsmed]

glen do you think short narrowband (20-30 seconds) will be achievable with the camera?
if you've got some wind affected subs try out average combine in DSS.

[Atmos]

At Gain 300ish 30-60s exposures are theoretically workable.

[glend]

Russell i think yes short narrowband is achievable with the 1600. I have started going through all the files, basically running DSS to get scores and then checking samples. I have deleted about 50%, and processed them for the three layers. Whether 30 seconds is ideal , i don't know where the floor is, as the shorter the sub the lower the data threshold. I need to stretch to get the data to show, and 60" seems workable so far. Thankfully i did not have to shoot 30" narrowband last night, but i may test it in the future.
One thing i am finding is that Dark Calibration in DSS seems to be costing me narrow band signal data in myb6p" subs. I have compared output files of Ha and Oiii stacks with and without darks and the resulting image is much better without darks. It maybe just DSS, i fon't know how other stackers would handle it. Unfortunately i can't find a way to control DSS dark calibration thresholds. I have played around with the available dark options but so far i can't solve the problem.
However, this camera iscso low noise and smooth, that i think that imaging without darks at thise low sub times is feasible. Just have a look at Ray's M83 image, which has no dark calibration.
I will post up my NGC 6188 with out dark calibration, later today.

I should add that 30-60" LRGB subs would deliver a higher signal level than narrowband obviously, and so those sub times are easily achievable imho.

Colin i am using Unity Gain settings ( Gain = 139, Offset = 21) on my 60" narrowband subs and they seem to be ok.

[rustigsmed]

thanks Colin



thanks Glen, I'm interest in shorter subs as I'm thinking of using on a goto dob. I guess even binning 2x2 is an option considering the megapixels.

I wouldn't worry too much about using darks. I haven't used them for ages and if they are causing grief for now give it a shot without them :thumbsup:

[Shiraz]

Glen
I have no experience with DSS, but if it seems to be stuffing up things when you use darks, try without. You may need to use bias though for your flats. Also suggest about 5 minute subs for NB if possible - that will give you SNR limited by shot noise and not camera noise. Shorter subs will work, but will require longer overall integration to get to the same result. Isn't it nice to be able to get lots of usable subs in bad wind though?

As a general comment, the dark noise is low and dark calibration may not add much benefit for brighter targets. It is probably still worthwhile for maximum depth on dim NB targets, but that will depend on how variable the bias is - it is likely that bias is reset with each power-on and full calibration will be a bit more complicated for this camera (ie we could possibly need new bias data for each power on or change of gain). I guess that we will all get a feel for how best to use this camera after we have more experience with it, but for now, I think that no-cal is a perfectly viable option - particularly for broadband.

this is more fun that a barrel of monkeys - the new camera really is a very interesting beast :thumbsup:.

[codemonkey]

Cheers mate. The OAG has adapters for various threads and since the spacing between the reducer and the OAG isn't critical, I could use something off the shelf for that, but I've been unable to find anything.



Cheers Colin.



Sure, to start getting a feel for the camera, I can use it without the flattener. It remains to be seen how bad the curvature is as well, but I assume I will need to use it. Still, to begin using it properly I'll need said adapters.



I'm not sure if there's a local adapter maker. I'd prefer to go local if anyone knows of someone.

Camera has now arrived, so I'll get to try and plug it all up tonight when I get home.

[glend]

Thanks Ray. Now I have just completed the first pass processing on NGC 6188 from last night (in the wind). From the 150+ subs I culled down to the 90 best scores (30 Ha, 30 OIII, and 30 SII). So total integration time is 30 minutes for each filter, no way I could have run 5 minute subs last night. Pretty happy with the resulting star shape in those conditions. As usual my senior moment with this image was forgetting to register the layers against one another, and I will need to go back and redo it to sharpen up the final image. This is my first attempt at the Hubble Pallet. Note no darks or bias frames or flats were used.

If you'd like to have a look, it is up on Astrobin here:

http://www.astrobin.com/full/251802/0/

Small low quality thumbnail below here.

[Atmos]

Glen, while you're running at Unity gain I believe that gives you ~1.75e- read noise. At 60sbuourd getting to the depth (fainter) stuff that I would at 225s. As Ray suggests, you'd be better off close to 300s. At 3nm filters that'll push out close to 480s.

That shot is looking pretty good for a relatively short overall time. Just need more subs to reduce noise but that is to be expected at a total of 1.5 hours :)

[Shiraz]

yep, that is an excellent result for the time taken.

looks like we will need to use darks for NB - your image shows some marks that I take to be wafer polishing marks - upper right. I get similar marks in my darks and assume that the silicon characteristics vary slightly and the dark current is different where these marks appear. I don't think there is anything similar in my bias results (haven't checked at long exposure yet). On that basis, maybe try subtracting bias from your darks and then subtract the remaining dark signal from your lights - that will leave enough of bias pedestal to protect your data and the bias noise seems to be pretty low, so will stack out with dither. Ultimately a full bias/dark calibration will be best, but if DSS won't do it properly, this may be a viable approach for now.

broadband signal is high enough that none of these effects are visible.

[gregbradley]

Pretty good there Glen. 30 minutes each filter would look similar I think with other cameras?

Greg.

[codemonkey]

Looks like there's still more issues with SGP and this camera. Using the latest versions (ASCOM driver v1.0.2.7 and SGP 2.5.1.15) I can consistently get frame & focus to deliver a seemingly unlimited number of frames of whatever length, but the sequence will only capture one frame >= 1second. Subsequent downloads fail. I've been unable to get the sequencer to download any frames at all using sub-second exposure times, whilst again, frame and focus has no problems.

Camera is connected via a USB 3 port direct to the laptop (no hub in the mix) using the supplied cable. I've tried adjusting the USB limit (45 & 90 were used) to no effect.

[glend]

Hm, i am still using Ascom driver V 1.0.2.5 , i did not realise ZWO had a new one. Do you know what prompted that Lee? 2.5 is only a couple of weeks old.

Anyway it probably does not impact SGP frame and focus. Here is what i have found and how i use frame and focus.
I only use 'Take One', and this works just fine, based on advice from CN beta testers, as i am usually moving the scope slightly between takes anyway, i also use it to focus with my mask. I stay away from the continuous take mode because thst's all it does, take continuiously and not download. I suspect, given the amount of time it takes for one take to download and be displayed, that the downloads are over-run by the next frame and the necessary handshake can not take place.
I like to be able to alter the frame duration as i find say a 20 sec frame is good for small framing changes on nebulas, take one is good for this sort of thing. Make sure you are not saving those frames, there is a box to tick to save, i don't think its a good idea, these files are big and the less disc space used the better.
Check your camera setting box, you maybe surprised to see that even if your running usb3 it defaults to usb2 operation. I see this all the time, it doesn't interfere with my imaging but it does lengthen downloads from the camera slightly. This may also be the reason for the Continuous frame and focus not working.
So in a nutshell: Use Take One, it works and what's the hurry anyway. I woukd still do it that way even if continuous worked. Your alternative might be to frame and focus using Sharpcap as it can be a video stream if you want, however it coukd be messy switching apps for that, especially if your checking focus on filter swaps. The beauty of parafocal filter sets, focus once - this has worked really well on my Baader filters which are parafocal.

Hope that is of some use. Ray is using SGP, lets see what he says.

[codemonkey]

Here's a couple of dodgy flats (pointed at my ceiling with no OTA connected) demonstrating the vignetting with 1.25" filters with the camera connected directly to the Orion Nautlius 7x1.25" EFW.

The vignetting itself isn't so bad. The filters are clearly not centered, but the main issue is that it's inconsistent. Between the two frames I rotated the filter wheel to another filter, then back to the original. This will make taking flats annoying.

Previously with the 674 and 1.25" filters I was able to take flats maybe every two weeks or so and then use them across all the filters. Now, for proper correction, I'd need to take them every time I change filters, even if I change it back to the one the flats were taken with.

[codemonkey]

Cheers Glen. I'm not sure what prompted the new driver version, I just grabbed the newest ones of everything in the hope it would work.

I've actually got the opposite problem. Continuous download on frame & focus works fine, I can do it all day with the shortest exposures the camera can do. It's the main sequencing part that doesn't work.

I've checked the camera settings thing and it's using USB3, and was by default.

[glend]

Lee give me a call to discuss, this is probably better sorted out on the phone. I will pm my mobile #.

[Shiraz]

Good point, but it might not be as bad if you test in a converging beam. I have an ancient Atik FW (probably worse than yours) and just did a few flats with my f4 system (which is really on the edge when it comes to filter alignment sensitivity). I moved off-filter and back on between the subs. At the same point in the darkest corner, the levels were:
26426
26318
26440
26063
25925
26504
26222
26758
26598
The levels in the centre of the field were much more consistent. Clearly not perfect, but I think that I can live with minor positioning errors causing a few percent error in brightness in the far corners of my images and will be sticking with the 1.25 filters for now. Not sure how much of a problem that will cause with colour, but will see.

Edit, just took the two widest apart flats and flat calibrated one with the other. The result was very flat, so should be OK.

[codemonkey]

Cheers Ray. What sort of light source did you use when testing that? My dodgy flat panel will have a divergent beam and I'm not sure of the impact of that on the vignetting.

I did a spot check on those two frames I posted, one in the top right corner, one in the top left. The top right varied 12.9% between the two frames, and the top left varied by 7.4%. I think the difference between the two most divergent of yours is about 3.5%

I could take multiple sets and then average them, I suppose.

In other news, SGP are looking into the issue that I described above. SharpCap has been working fine so I've been able to start capturing calibration frames. Hopefully SGP can sort it out quickly, although the forecast for the foreseeable future is cloudy anyway.

[Shiraz]

Used a diffuser in front of the scope - same as your panel will give. Testing in the open under the diffuse light in a room will allow light from a very wide range of angles to affect the result - the scope will limit the range of angles that the light can come from. Suspect that will make a significance difference (of course it might not as well)

I am still using Nebulosity - I am getting only occasional bursts of clear sky and cannot bear the thought that the software will let me down.

[glend]

Jon Rista, writing in the CN beta test thread, has put up some graphic data on stacking effectiveness (SNR) with this camera.:thumbsup:

Link here:
http://www.cloudynights.com/topic/535506-asi1600mmc-beta-test/page-69#entry7269131

And he has also suggested a Gain 75 "Sweet Spot" giving almost exactly 12 stops of dynamic range, with 2.05e-/ADU gain and 2.05e- RN, with a 8402e- FWC.

Link here, with data:

http://www.cloudynights.com/topic/535506-asi1600mmc-beta-test/page-70#entry7269537

[codemonkey]

Cheers Ray, that's a good point. I'll see how I go when it's actually on the scope (which is allllll the way "up there" in the paddock). I was briefly trying to confirm e-/adu for a given gain and noticed that it appears to vignette even with nothing on the camera than the black adapter that is screwed on by default (male to female M48 maybe?) and it was then that your comment fully made sense to me.



Seems reasonable and maps pretty well to the graphs ZWO have provided.

I've captured bias (200) & darks (100 ea @ 300s and 120s) for a gain of 99 and offset 40. I'm now doing the same for gain of 74 & offset 35, although I'll probably only bother grabbing 50 darks this time, after seeing the diminishing returns from the previous set.

How annoying are those sliders in the ASCOM driver interface? I can never get gain to be exactly what I want.

[glend]

You can just type in the number you want in the box - can't you?

[codemonkey]

There's no box in the ASCOM driver interface that I have...?

[Shiraz]

I think that Jon's analysis applies to the individual subs and will do fine for stacks as well. However, I don't think that there is actually a single sweet spot. sorry for reposting, but the attached table shows that, by choosing appropriate sub length you can get almost identical broadband stacked SNR and stacked well depth for any gain up to at least 100. It is only at the highest gains that the stacked well depth begins to drop off, but even then, a choice could be made on the basis that a bit of performance could be given up in return for the advantages of very short subs. ie, choose whatever subs length you think appropriate (for resolution, tracking, data processing load or whatever) and then select right gain to get the best possible performance - it really is a very flexible camera.

[glend]

Sam has released an ASCOM driver update, V 1.0.2.8.

He posted a notice on the CN Beta Test thread. The link is now available on the ZWO ASCOM page.

[glend]

The CN Beta Test thread has now been locked, it was getting too big (with 1800 posts), and finding things was becoming difficult. There will likely be some Beta Test Summary results put together by the major inputers to the testing.
It is likely that should be considered for this IIS thread as well at some point, but this one is only 353 posts long, big by our standards, but we still have cameras just getting into the hands of early buyers so it might have further to run here. Shiraz has the right idea in putting images into separate threads and i will be doing the same from now on. My thanks to Russell for starting this thread, which brought the camera to my attention.

[Camelopardalis]

I'm not a great herd follower, so this is just MO and not those of the management, but I don't see the point in locking a thread in a "discussion" board when folk are still getting useful information from it :shrug: Personally I've found it very interesting watching this develop and still seems a bit early days from my point of view, if only 3 IISers have put their hand up to blaze the trail :thumbsup:

[glend]

I don't think i was suggesting locking the IIS thread now, or in the near term. This is a much smaller pond but in some ways were ahead of what they are actually accomplishing over there because we can actually get cameras ex-stock and our weather and skies are better.

Clearing here now, so i am heading back to NGC6188 tonight, running 300" subs over the last few clear nights, and the histogram looks much better, no need to scrape data off the floor.

[glend]

After over three weeks running SGP to control the ASi1600, it has now stopped working. I have just wasted two hours trying everything I can think of and it will not work properly. I had down loaded the latest version of SGP V2.5.1.15 after my last imaging session,and the new ASCOM driver V1.0.2.8, and now my system is stuffed.
Basically, frame and focus does not work anymore, just downloads and never stops. I tried using short subs in a sequence and that doesn't work either. I am out of business. My cables are exactly as they were, I have changed nothing but this software. I have rebooted the laptop, tried difference connection secquences for the various devices, checked the device manager, reinstalled stuff, and nothing worked. Well the guide camera and Metaguide worked but that's not getting me anywhere.
Anyone using these software versions successfully? Any ideas?

[glend]

I am hearing (on other forums) that there is a problem with the ZWO ASCOM .8 driver and going back to .5 works fine with the latest release of SGP (15). I will try to go back to the ASCOM .5 driver, but testing will now have to wait. What a mess.

[Shiraz]

yes, it is turning into a bit of a mess. However, the two outfits seem to be doing their level best to get the two softwares to play together.
Although nothing like as functional as SGpro, SharpCap does the job OK, so maybe go back to manual imaging until the problems are sorted?

[glend]

Thanks Ray. I have a thread running on CN now about it, and the SGP forum and emailed Sam. I am getting indications on CN that the new release of SGP is ok only if used with the ZWo .5 driver, people seem to be holding there. Had a message from Jared at SGP saying basically ' what problem?'; and an email from Sam saying pretty much the same thing. Very odd that i have had no issues until that combination of releases ,eh? I am taking the CN forum advice and going back to the ZWO .5 driver. I might have to get out before dawn and test.

[glend]

Yes i got out of bed and went back out there to test the rollback to the .5 ASCOM driver. I am satisfied that it works again, at least Frame and Focus is back to normal. I have taken a few test images which i will look at after i've had some sleep. No real conclusion yet on the SGP .15 but Sam has to sort out his driver, it is clearly a problem for some users. The random nature of the problem is very confusing, some people say the .8 driver works for them and others like me are out of action and have to roll back. Stability please.

[codemonkey]

Yeah, the .8 worked for me but the .7 release did not. If there's one thing I've learned with astro stuff: if it ain't broke, don't fix it. Unless you have a very good reason to upgrade either SGP or the ASCOM driver for the ASI1600, I'd highly recommend sticking with the versions that you know work, at least until things have stabilised a bit.

[glend]

I have reviewed my test images, shot is both Ha and Lum, these were simple star shots at various shot (30 & 60") sub lengths - they are completely black (with the exception of some noise). It would appear that I am getting nothing now from the camera, even though the download runs and the star analyser runs and it saves the file - there is nothing there apparently. And no the scope cap was not on, and the camera was powered and cooled and connected in SGP, and I was shooting Lights. Funny thing is that 10" Frame and Focus images worked but looked strange, very washed out.
Jared says stay with .15, Sam says 'what problem', anyone with any ideas?:help:

[Atmos]

Put in an eye piece and get sketching? ;) :lol:

On a more serious note, you should be able to do a bit of testing during the day :)

[glend]

I have uninstalled and reloaded both SGP .15 and the ASCOM .5 driver. I will do some infrastructure testing this afternoon, to see if i can get my powered USB3 extension cable to work, and try to sequence some darks. I might try some flats.

[Shiraz]

maybe check that your bias has not set itself to something weird and also check that the cooler is actually getting the chip temperature down to the target. Nebulosity threw a wobbly when I ran the camera at low bias without cooling - it recognised that it was being presented with negative results and refused to work.

also, does the camera work in SharpCap with the supplied USB3 cable? At least you could establish that the camera still functions.

[speach]

I've been following this thread, and it's starting to go over my head but would you fellows stay that this is a good camera to get as I jump up from a dslr? My thoughts are to get the mono one? Any advice would be appreciated.

[glend]

Its a great camera Simon, don't be put off by the dramas with SGP. Its a logical step up from a dslr, which is where i came from.

Now i can report that SGP .15 and ASCOM .5 are working. I uninstalled the lot and reinstalled with the .5 driver and i am back in business. Did some daytime testing this afternoon, including moon imaging. I was pushing SGP pretty hard with a sequence of moon subs of 1" and filter changes every ten subs. I thought that might trip it up but it ran through fine. It was running over my powered usb3 extension cable as well. So hopefully i can get back to my 300" narrowband imaging tonight.

[lazjen]

I just saw some messages over on the INDI forums about this camera, so it's getting tested/developed for other platforms too (e.g. Linux/Raspberry PI), which is very encouraging.

[glend]

I am giving up for awhile, I can't get SGP to work properly in the dark, and I don't know if I have a camera problem as well. While I could get images of the moon this afternoon, tonight I have no real gain despite cranking it up to 300 I can't get the stars bright enough to focus with a mask. I don't know it its SGP or the camera driver, but it certainly is not behaving the way it was before these supposed upgrades to SGP and the driver.
I am tempted to try APT, I tried Sharpcap tonight and could not even produce an image. Love the camera, when it was working but in the last week I have nothing to show for hours of effort. Frustration is the word.

[Atmos]

You could always download a trial version of MaximDL, that will give you can indication as to whether it is the driver (which I assume is ASCOM) or SGP talking to the driver.

[glend]

Yes that is a good idea Colin. Just saw a post on CN reporting the same dark frames i have been getting, it maybe another driver problem is the CN speculation. I am glad to know others are seeing the same problem, thought it was me. Apparently it happens in both the .5 and ,8 driver, but the .8 is much worse. I see ZWO has now withdrawn the .8 driver (quietly) and is showing .5 as the current ASCOM driver on their website. Of course no acknowledgement from Sam concerning a problem, no release or rollback notes. I still believe the .4 driver was the best as i ran for three weeks on it with no issues, then they went and changed it.

[Shiraz]

did you reload the basic driver as well as the ASCOM driver?

in Sharpcap, did you try to run it as a direct show camera? I have had no trouble with direct show, but I think it requires that the basic driver be in good condition. It might be a good idea to establish that the hardware is working properly by running Sharpcap/directshow, using the supplied USB3 cable, and without reference to ASCOM or SGP. If that works, try it as an ASCOM camera under Sharpcap (the direct show driver may set the chip up properly so that it works under ASCOM). If you can get it to run under ASCOM in Sharpcap, try SGP again and then move onto the extended USB hardware. That might give you some idea of where the problem(s) lie.

FWIW, I would guess that the various bits of software load registers in the chip to control the various functions, so unplugging and reconnecting the camera USB may also be worth doing if things play up - might possibly clear a register that is not in the right state

[ZeroID]

Same question here, it looks to be my next big purchase. The question is , what is working and what is not ? Are all the problems related to SGP which I don't use anyway or has the ASCOM driver update polluted other capture apps as well ?

[codemonkey]

Most of the issues are caused by the ASCOM driver. I don't see this as a reason to not buy the camera though. This is just teething issues. Software's easy to change, hardware not so much, so as long as the hardware's good, which it seems to be, then I wouldn't worry much.

[glend]

There are some problem with the ZWO ASCOM driver, and they have recommended rollback to version 1.0.2.5. Testing continues. SGP is where the problems mostly show up. It seems to relate to USB settings, with throttling back the speed helping reduce the problems. Sometimes it works, sometimes it doesn't, which is really frustrating. I tried out APT last night and it seems to work ok in traditional sub capture mode, using standard gain settings but seems extremely clunky after using SGP (then again it was free).
Remember this is a new camera, and there are no issues relating to hardware that i am aware of at this time. I would like to have Maxim DL which is what Sam (ZWO) used in dev testing, but i can't afford it. I am sure the driver issues will be sorted out as more people get cameras and test them and feedback info to ZWO.

[glend]

Ray i will try your suggestions tonight. I have just purged and reinstalled. Tonight looks to be my last chance for sky testing as the rain is coming back. Probably already affecting SA.

[glend]

Sam from ZWO emailed me today about my problems with SGP and the camera communications. He wanted access to my equipment via Teamview to debug and test. I thought about it but had to decline. I don't run Teamview, or even have a dedicated astro computer. At the moment, my laptop gets carried out to the observatory for imaging, but it is also my personal computer with all my stuff on it. I don't have a reliable wifi signal in the observatory, and no network of any kind cabled into it.

I am delighted he is trying to find a solution but i can't see how i could make that request work.
I have offered Sam anything i can supply in the way of settings in both SGP and the camera, drivers, etc even photos of the cable setup.

[glend]

I have just conducted a comparison imaging run with the 1600 using SGP .15 and APT. The camera setup was identical for both, the original USB3 cable direct into my laptop. ASCOM driver was .5 as recommended by ZWO currently. Camera setting was Unity, with USB at 45 for both tests. Target was NGC 6188, which I have imaged before with SGP and the 1600 back when everything worked smoothly. I was shooting Ha subs of 300" in length. Focusing and Framign was done in SGP, and the Take One worked fine, and each of the short (10") sub focus and frame shots were clear and target visible.
The mount is an NEQ6Pro, the Scope is a Skywatcher MN190 Mak-Newt f5.3 . The same gear I used for previous successful runs. The mount was guided by a ZWO guidescope and an ASi130 as the guide camera as per the last couple of years of imaging.

The test run consisted of 8 x 300" Ha subs. Started first with SGP, and watched every single sub come up on the display and checked the histogram. The first two were fantastic, with clear definition of the object gas clouds, a good fat histrogram spread across the display, peak about 25-30% from the left side. The 3rd sub through the 7th sub were absolute garbage, the main stars were just visible and the rest of the image was just a patterned noise, all of these subs were identical. The histogram was way over to the left side - no significant signal data. Then suddenly the last sub in the sequence came good again and was the equal to the first two, in content and histogram.
So I had three random good subs out of eight.

I switched over to APT, same setup, 8 x 300" Ha subs, and I watched the subs as they came in. I did a short test sub and it looked fine with a good histrogram, then I started the sequence; the first one was good with the same fat histogram as SGP produced, then the second one was garbage, as was the third and fourth. I terminated the test at that point and went back and checked the output files for both runs. The good subs looked identical whether captured by SGP or APT, the bad subs also looked identical for SGP and APT - the same pattern noise and very low signal shoved way to the left on the histogram.

So my conclusion is that the problems with these ASI1600 images has nothing to do with the capture application, both SGP .15 and APT produced identical good subs and bad subs, but in different quantities and timing in the sequence.
The ASCOM driver .5 was set to the identical setting and USB level for both runs.

Where does this leave us? Well for me, its pointing to the camera and the camera driver/ASCOM driver. There is something very wrong in there. Why did this system (1600 and SGP) work flawlessly for three weeks of imaging and then suddenly stop? Is there a hardware fault that shows up after some hours are put on the camera? I can't say and it's not for me to solve. ZWO has some work to do here. I will cut this post and email it to Sam.

I am stopping any further use of this camera until I get some answers that make sense. I am sick of the frustation.

[mountainjoo]

Is the histogram you're referring to in SGP the image histogram or the stretched histogram underneath it?

[Camelopardalis]

Glen, having worked in support before myself, you have to accept that this is peoples jobs and they're not interested in the slightest about what else you may or may not have on your computer, they just want to fix the problem so you can get on and use the product as intended, whether it's hardware or software.

Declining hands-on help from the head guy sounds like cutting off your nose...sorry if that's a little too graphic, but you're complaining about an issue but don't want the manufacturers to help :screwy: No ill will on my part, just an outsiders view. If you want me to delete this I will ;)

[glend]

Dunk i admit i have a problem turning over my one and only computer to a guy from China, regardless of his position as a supplier. My whole life is tied up in that computer, from my banking activities, to my childrens photos. It is entirely my choice. I am happy to send the camera back to him if he wishes. I too have been involved in computer support, both as a programmer and as the manager of a major bank's infrastructure. I would not grant a local support guy direct access to my computer either. There is always a risk associated with remote access without adequate secutiry protocols. A virus can be planted without my knowledge, and he may not even be aware he is carrying it. I know nothing of any safe guards he may have, or not have, or what his system has been connected to. Again it is my choice, if it means i wait a bit longer for a fix so be it.

[luka]

If it is your only computer you could to make an image of the hard drive, wipe it and reinstall Windows + drivers and try again. If it is still not working you could let the remote support try to fix it as there is nothing sensitive on the computer. Make sure you watch what they are doing and take notes so you can do the same to your original system. When all is done you can restore the image back.

It is a complicated way around the problem...

[lazjen]

Although going off topic, I strongly suggest getting a dedicated machine for either astro or your sensitive activities (banking, etc) and don't mix the two. Given the amount of money we tend to throw around at this hobby, the cost of computer hardware is not that significant.

Back on topic: Glen, you had this working with an earlier driver? When you did your tests with SGP/APT did you revert any other changes you made? Have you updated anything else?

[glend]

Pensioners don't have much money to throw around. I had to sell astro equipment, including my older camera, to purchase the ASI camera. I had been using a cheap HP Stream to run BYEOS in the observatory but it was never going to cope with all the storage and USB3 requirements of the new camera.

My system was working fine with SGP .14 and the ASCOM .5 driver, but Jared (SGP) swears SGP .15 is clean and everyone should stay on that release. Besides, APT has exactly the same problem with the 1600 - so what remains common - the camera and its drivers.

I suppose i could try running APT on the HP Stream with the camera connected to USB2; not a long term solution. I could allow Teamview access by ZWO to the HP Stream. I will talk to Sam about it. Thanks for bring that up.

[lazjen]

That is true. Although you could use your powerful machine for astro, and use the HP Stream for the do banking/finance. Or get a cheap device for the banking stuff. Assuming some gear re-use (monitor, etc), you could probably setup a non-Windows system for less than $100 (e.g. a RPi) - 5% the cost of the ZWO camera.



Unless the issue is related to USB3 also...

[Camelopardalis]

Yeah I wondered what happened to your HP stream :lol:

That'd be a way for sure.

When it comes to storage...it depends on your usage case. If you're going to use the camera in the traditional astro image fashion, an image every couple of minutes doesn't tax USB 2.0. It's only if you get down to an image every second or faster that it becomes an issue. FWIW, I do my planetary imaging on a similarly low-spec USB 2.0-only machine at high frame rates and it gets results.

[glend]

The HP Stream has now been converted from a DSLR platform to an ASI1600/ASCOM , and the camera and drivers are installed. I also installed SGP and Teamviewer, so Sam can now have acess to it.
Interesting thing during the install, the HP could not see the camera when it was plugged into the USB3 port but when I moved the camera to a USB2 port it connected right away. I have always assumed that any USB3 port is backward compatible to USB2 if required.
I did some test Darks and its all working through SGP. Can't do Lights of course as it's on the kitchen bench, but access is available.

Sam has been notified that the camera and it's laptop and app and drivers are now available for Teamview access.

[glend]

OK the Teamview session with Sam is finished. From what I could observe here is what was involved.

- Upgrade of some WIN related items
- Upgrade of the USB3 Microsoft driver to an Intel USB3 driver.
- Extensive testing of frame stability (minimise drop frames) in Sharpcap 2.8. This was done by trying the various drivers to determine minimal (0) dropped frames while maintaining a good histrogram. A continuous stream of 2" frames were used
- Extensive testing of short Darks (or long Bias) frames in SGP. The method used was continuous Frame and Focus shots, 4 sec duration, and 4x4 bin, with the histrogram stretched. Interesting was the behaviour of the histogram with differing drivers loaded. The .8 Driver was noticably worse than the .5 Driver. What seemed to be the desired result was a good bell shaped histogram, without any shape change over long numbers of frames. Occassionally the frame would jump, and the histogram would change, some had long tails towards the white side. The .5 driver was the best at maintaining stable bell shaped histograms.
- Importantly SGP .15 exhibited no Frame and Focus freezing during the long stream of continuous frames.

During this testing, Sam tried various driver changes, including a camera driver and the ASCOM driver range. There maybe other things I missed.

Sam had this summary:

- He upgraded the FPGA code in my camera (Firmware upgrade), I have a version number off the file but do not know if this is just a test version or slated for production..What is a FPGA you ask? I had to do a search to find out, it is a field-programmable gate array (FPGA) which is an integrated circuit designed to be configured by a customer or a designer after manufacturing – hence "field-programmable".
- Verified that ASCOM .5 is the most stable for me.
- Asked me to do more imaging testing and provide feedback.

I am very grateful to Sam for taking the time to get inside my system and test. I don't know how much user platform testing has been carried out, and I acknowledge that they can't provide this service to everyone. So thank you Sam.

As is to be expected, the cloud has moved in now and the forecast says four days of rain, so imaging is going to have to wait. My take away from today was some knowledge of how ZWO test and I think I can use these techniques to keep an eye on camera and application performance.

[Camelopardalis]

Part of the problem is the complexity of Windows, driver loading, reproducibility on a range of hardware...it's impossible for any vendor to test every combination.

Great to hear it's working again :thumbsup:

[Shiraz]

FWIW, Mine is now also working normally under SGP with the latest ASCOM and SGP software (finally found 25 minutes of clear sky to test it).

It has always functioned under SharpCap and Nebulosity, but having SGP sorted is great. Thanks for your efforts Glen - it was good to see ZWO and SGP working so quickly to resolve issues as they arose.

[codemonkey]

I was out on Monday evening doing some quick tests to figure out spacing for the flattener, and gathering a couple of flats through the OTA to see if that would impact the repeatability of the vignetting... SGP .15 and ASI ASCOM .8 were still playing nice for me with multi-second and sub-second exposures.

I think .8 might have more amp glow than .5, but I'm hesitant to swap out versions given that it's working for now. Think I'll just let it stabilise a bit first, hopefully soon we'll have a stable driver with reduced amp glow.

Anyway, not sure how useful that info is since different combos seem to be working for different people, but perhaps it'll be of some use.

[glend]

Over on CNs there is a recent (short) thread on problems with USB3 on this new generation of ZWO cameras (and this is not just a 1600 issue), all of the ZWO USB3 cameras can suffer from comms defaulting to USB2, but the computer it is plugged into can be the cause of that fallback, not the camera. Sam from ZWO got onto the thread and has linked in a set of instructions from the ZWO forum, and this is worth reading for anyone with a 1600. Basically, Sam advises:

"this is usually because of host USB3.0 controller, a driver update would fix this problem". This refers to your laptop or PC USB3 controller driver.
In my recent Teamviewer session with Sam, he upgraded my laptop USB3 controller to the one recommended in his forum post. Which is the:

intel USB 3.0 eXtensible Host Controller

Here is the CN thread link:

http://www.cloudynights.com/topic/541269-usb2usb3-with-asi1600/

and here is the ZWO forum instruction post:

http://zwoug.org/viewtopic.php?f=21&t=1688

Sam lists many incompatible USB3 host controllers in that thread.

It is easy to check your installed USB3 driver, just go into the Device Manager section and check which USB3 controller is loaded on your laptop or PC.

[glend]

It seems ZWO has released yet another ASCOM driver, V 1.0.2.9.
See the ZWO website for details, which include some release notes.
I will be staying on .5 until reports come in on this one. It has only been 7 days since Sam confirmed .5 was the current best option, but the release note suggest .9 corrects some problems in Nebulosity and APT operation; but does not clarify if it is an evolution improvement of .5 or running on from .8.
It is probably prudent to stay on what works for you, unless you want to Beta test each release.
Interestingly ZWO still provides the download link for .5 on the same page.

[codemonkey]

That's good news. Also good that they're now providing release notes.

[codemonkey]

Well, it's looking like it's going to stay clear tonight, and the wind back to windy but reasonable levels so I'll finally get a first light tonight.

The adapter from precise parts has shipped but won't be here for a few days which means I have a choice between using the flattener, or OAG. I'm going to use the flattener and shoot some very short (15s) unguided images and see how I go. Might be total junk, but it'll be interesting anyway. Planning on using unity gain.

[glend]

What the target Lee and are you shooting Luminance only?

[codemonkey]

IC 4601 and I'll be shooting LRGB. Expecting the worst, hoping for the best ;-)

[Camelopardalis]

The seeing isn't too bad down here in the big smoke, but the Moon will be up shortly. Looking forward to seeing how you get on Lee :thumbsup:

[glend]

Well lets see it.
I just finished a long sub (300") narrowband test shoot at Unity on NGC 6188, i have over 5 hours of subs now collected over several clear nights. Not one dropped frame, no SGP issues, it performed flawlessly.

[codemonkey]

Not that well, as one might expect from 15s LRGB subs :lol: Have only seen the L data so far -- it's a lot of data to process for such a short integration time.

I'll post it up and maybe do it properly with decent subs when I get the adapter. At the moment it's not good though ;-)



Likewise, let's see it Glen :) That's the usual experience with SGP, good to hear things are back to normal for you.

[codemonkey]

Well, here it is. About 1.5hrs worth of 15s subs, many of them not good. Crazy NR applied to the RGB, moderate to the L. Obviously needs way longer subs! Was actually capturing for 3hrs, but the overhead of downloading/analysing the subs ate into the overall time significantly, and I did discard some.

[Camelopardalis]

Looks pretty interesting for 15s subs :thumbsup:

The upside of longer subs is less downloading time.

[glend]

Ok here is my long sub narrowband version of NGC 6188. This was shot over a couple of weeks, just finished up last night. The last time on this target I used 60" subs and despite alot of them I was scraping data off the noise floor to build an image. While the camera is great at 60" for RGB, for narrowband it really does need around 300 seconds. I think this time it is a significant improvement and better reflects the camera's capability. There were over five hours of 300" subs that went into this image, Ha, OIII, and SII in Hubble Pallet scheme.
Shot with the ASi1600 at -25C, and captured with SGP. Stacked in DSS with Darks and Bias frames but no flats.
Processed in Photoshop CC, and I added a synthetic luminosity layer built of the combined Ha and Oiii greyscale data. It could probably use more adjustment but I will return to that another time. I might mention that the combined layers file when saved in Photoshop CC was 1GB! I am still learning Photoshop so I know it can be better.

I have attached a little down quality thumbnail teaser below, for the real deal you will need to follow the Astrobin links here below. The master file copy in Tiff looks better, but Astrobin only takes jpgs, sorry - too bad there is no where to publish it.

Astrobin large: http://www.astrobin.com/full/253314/0/

Details page with histogram: http://www.astrobin.com/full/253314/0/

Comments welcome, and if you look in my Astrobin Gallery you can see the previous 60" sub image right next to it, it's worth checking out the histograms and comparing.

[Atmos]

I prefer the orientation of the first but the newer one is certainly a lot cleaner, 300s subs do make a big difference so as to not drag off the noise floor :P

[glend]

There is probably a lot more there that i haven't pulled out. Re the orientation the camera was in exactly the same position on the scope, but in the first one i rotated it in processing and cropped to give the 'traditional' view. The orientation allows more detail above and below the 'cloud wall', that is lost in rotation so that the 'cloud wall' runs along the long side of the sensor, imho.

[Camelopardalis]

Looks pretty good Glen, as the IIS thumbnail hides your tracking error :P

Besides that, you've got to be pretty happy with the results :thumbsup:

[codemonkey]

Got my adapter! But I can't reach focus with the guide camera & the imaging camera at the same time (guide cam needs to be closer than the OAG can get it, can't increase distance between the OAG and camera because of flattener spacing). Marvellous. Would have worked if I hadn't tried to get cheeky and save myself an extra adapter... now I'll have to buy the original two I'd planned and have a > $200 paperweight.

[billdan]

That is real bad luck Lee, its a money pit this hobby.

Bill

[Atmos]

That does suck Lee, maybe someone on the IIS Classifieds will want your adapter?

[Shiraz]

is there any way to get a small positive lens inside the guide adapter to act as transfer lens. If you can do it, you could refocus the guider beam further out. I bluetacked in a positive correcting lens from an otherwise useless Barlow when I was messing around with an OAG, but I guess you could find something useful in any old eyepiece - you need a short focal length lens and will have to experiment with placement, but it does work.

the alternative would be to put a negative lens (essentially a Barlow) closer than the guider focal plane and throw the focal plane out further. The disadvantage of this is that the guide image will be larger and dimmer, which will make it more difficult to find a star - might be OK with binning though. Again, a suitable lens should be available in an old eyepiece or you could try an actual short 2x Barlow if you can get it down deep enough in the adapter

rough drawing attached

[Rex]

Wow that's gotta suck Lee! Hopefully you can sort something out. This hobby is expensive enough without these kind of dramas.

[glend]

Pointing out the obvious, with a separate guidescope you would not have this problem. At a focal length of just 840mm your not likely to have to worry about differential flex.

[codemonkey]

Thanks Bill, Colin and Rex. It's really my own fault for trying to cheap my way out of it in the first place. Changed my order at the last second and didn't put enough thought into it.



Ray, that's genius! The OAG has a helical focuser which leaves a bit of space, definitely enough for a small lens.

I dismantled the eyepiece (28mm) that came with the Esprit last night and tried to use the front element to do this.

I tried racking the focuser in and out but couldn't see any stars though I knew they were in the FOV. I didn't try very long as I just wanted to get some imaging done for once and decided to temporarily do away with the flattener.

I'll give this more of a trial though, might be that I just needed more distance between the lens and the guide cam.



Cheers Glen. It's more about your imaging resolution than the focal length. I started with an OAG, went briefly to a guidescope, and even when sampling at lower resolution (higher "/px) I could see flex issues. I'm back to an OAG now (obviously) and I don't see myself ever looking at a guidescope again.

[codemonkey]

Actually, having re-read your post, Ray, I'm guessing that 28mm eyepiece is too long. Any suggestions on what focal length might work? Would a 4mm plossl do the trick?

I'm considering buying a cheap, short focal length eyepiece, as if I can make that work, it'll save me hundreds.

I don't know anything about eyepieces, as I started out doing astrophotography and have never done visual.

[Shiraz]

I just pulled an old 9mm GSO Plossl to bits - got a nice doublet with a focal length of about 16mm. Guess a 4mm Plossl would yield similar with a fl of about 7-8mm and that would refocus your focal plane at roughly 32mm further out (or a bit more if you want).

Edit: been thinking about it and suggest that you use the whole eyepiece (eg GSO). Unscrew the chrome extension tube and then you would need to get someone to turn down the eyepiece main barrel so that it fitted in the 1.25 inch guider tube (also would probably need to cut off the threaded bit) - that would give you a way of securely mounting the transfer lens in the OAG. If you can find where the guider focal plane is (using a small scrap of baking paper with a daylight scene), you can work out roughly where the transfer lens has to be. For a 4mm eyepiece, the distance from the original focal plane to the eyepiece will need to be about 8mm and the new focal plane will be another 8mm or so out on the other side of the lens.

The measures that you will need in order to work out the appropriate eyepiece focal length is the distance of the CCD from the front of the camera, the location of the existing focal plane in the OAG tube and how far out along the OAG tube you can move the camera.

[codemonkey]

Thanks for taking the time Ray, really appreciate it! I've got some old measurements here for my focuser which tells me that it's about 2.7u per step and I think it needed to be about 7.5k steps further out, so that should mean I need about 20mm. I'll double check all of that before I order anything.

Edit: You corrected your post just as I was posting mine. So, based on those numbers, I should expect a change in focal plane ~4x the focal length of the doublet lens taken from a plossl. So if I need 20mm, and a plossl contains 2 doublets that are individually about twice their advertised length, I would need to divide the distance needed by about 8 and that should tell me (roughly) what eyepiece focal lengths I should look at... which gives me 2.5mm for 20mm, correct?

And by moving the lens element further away from the OAG prism, I would push the new focal plane out further, is that correct? I can only get it "so close" to the prism, maybe 20mm or so.

[Shiraz]

the distance from the old focal plane to the new one will be about 4x the fl of the lens, so if you use say a 5mm GSO plossl, you would move the focal plane out about 20mm. ie a cheap 5mm Plossl should do the job. However, there may be issues with getting spacing right (eg, can you get the lens close to the CCD), so you may need to go for a bit longer focal length - a 9mm Plossl would move the focal plane out by about 36mm and that may also be practical.

the key thing for getting the position right is to find out where the focal plane is now. If you get a small bit of baking paper and move it in and out of the OAG tube, you will be able to see by eye where the focal plane is if you image a daylight scene. You should then put the 5mm Plossl at about 10mm further out and you should get a transferred image another 10mm out (again you should be able to see the image using baking paper).

Can you get someone to turn down the barrel on an eyepiece? anyone with a small lathe could do it - you need not protect the thread.

What camera will you be using for guiding and how far back from the front of the camera/nosepiece is the ccd? If you use a long nosepiece, you might need to fit the Plossl within it.

it will involve a bit of messing around, but if it could possibly save you hundreds and a bit of time, it could be worth persevering

Edit, it may also be possible to swap your guide camera for one that fits down into the AOG tube, if that is the issue - what guide camera are you using?

[codemonkey]

Thanks Ray for all of your help, very much appreciate it. I decided in the end that buying an eyepiece and getting someone to machine it down probably wouldn't give me much change and might cause some annoying flex issues.

I went with another adapter, but realised I still only needed the one, so it's not as expensive as I'd feared, though still expensive enough.

On the bright side, your posts did lead me towards some simple little experiments with lenses and gave me a better understanding about them and how they work, so thanks again for that!

[Shiraz]

:thumbsup:

[glend]

I am hearing rumours that ZWO is about to ship a new version of the ASI1600 Cool camera, which will incorporate a USB hub socket in place of the old spot for the guide port. This is apparently to support/intergrate the ZWO filter wheel which is coming out as well.
There was a post on CN about it:

http://www.cloudynights.com/topic/544182-new-asi-1600mm-will-have-usb2-hub/#entry7334930

I am not a member of Yahoo Group so I can't see the link they are talking about but maybe others can.

I am abit concerned about having a superceded model already, and there are not that many out there. Wonder if ZWO is going to retrofit the USB hub and case changes to previously sold models? No word on that. I hope they have beta tested the integrated USB hub with their new filter wheel, and other wheels (might be a problem there), and potential impacts on the still unresolved USB3 issues in the present software. Might be moving too fast.

I also have had a message on CN from Sam (ZWO) asking me to test a new ASCOM camera driver version - copy is attached here:

"can you test our new ASCOM driver and feedback
just to make sure the old strange bias problem won't happen in this version"
http://astronomy-ima...p V1.0.2.12.exe (http://astronomy-imaging-camera.com/software/ASICamera%20ASCOM%20Setup%20V1.0.2. 12.exe)

I don't know exactly what the "old strange bias problem" is that he is referring to, anyone else know?
Its not likely I can test in the next week looking at the moon times and the weather forecast, but someone else might want to look at that driver release. I am happy enough with V1.0.2.5. which I am still running. Perhaps this new version also supports the USB hub port changes in the new version.

[Shiraz]

I am not too concerned Glen. We still have excellent cameras and got them at a very good price. Now that the software is working well, there is nowhere for the new camera to improve on what we have. There are other ways to get a USB connection to a filter wheel, although having it on the camera could be convenient.

let's see what price the new version comes in at.

[glend]

Ray I agree it is an excellent camera at that price point, and I am enjoying it. I am only trying to clarify what I was hearing re new developments.

I have now heard back from Sam (ZWO) via CN mail and here is his response:

"the new version just added 2 x usb2.0 port but removed the ST4 port
because we think USB2.0 port is more useful than the ST4 port
so you can connect the EFW or guider camera to the hub
this is a hardware change and no need for software driver change

So it looks like all the new deliveries coming into the supply chain will be in this 2 x USB2 port configuration, with the USB3 link remaining back to the computer . Effectively it will be a 2 port hub arrangement on the camera. How this will work in company with the camera downloads, focusing, etc will become clearer in time, but I assume they will have tested simultaneous comms with filter wheels and guide scope. The guide camera comms would be the more problematic I would think. No news on how, or if, this would affect pricing. Anyone about to buy should probably ask about V1 or V2.
I am happy enough to have my filter wheel and guide camera separate from the 1600, and running through my Mbeat powered hub. They work without issue. It's already a rare classic.:lol:

[glend]

Image of the new design is here, note the ZWO filter wheel is in the shot as well:

http://www.cloudynights.com/uploads/monthly_07_2016/post-54682-0-54481500-1468978246.jpg

[lazjen]

Looks good. The filter wheel - is it 5 x 1.25"?

[Camelopardalis]

I can imagine some might be interested in the USB hub, but I use an mbeat hub stuck to my mount that works well. I don't see any big advantage with having it on the end of the camera.

[lazjen]

Well, it is one less item needed, but it's not a massive advantage. More a nice to have.

[speach]

Well mine arrived yesterday. Be awhile till I use it as I've just moved and have to setup a pier ect

[glend]

Congrats on the new camera Simon. At least you can shoot Darks and Bias Frames and start getting that library together if your desperate to power it up.

[Camelopardalis]

Mine just arrived. It has the integrated USB hub :P

[glend]

Its all happening now. So Dunk will you be posting some images tomorrow, ha ha? Have fun.:thumbsup:

[Camelopardalis]

Not tonight unfortunately, but AstroFest is only a couple of days away :D

[SimmoW]

Got mine, but waiting for 2 crucial adapters for my new filter wheel setup. Cam seems to be working great with The SkyX software.

Just saw this very nice pic on AB, shows its good resolution

http://www.astrobin.com/258322/

[glend]

Anyone who feels that they need some tilt control for their camera should check out the new ZWO T2 Tilter that is now up on the website here:

https://astronomy-imaging-camera.com/products/accessories/t2-tilter/

Price is $38 USD.:thumbsup:

Looking at how the photos show it mounted, it would seem for most MM owners, they will need to place it on the scope side of the filter wheel and screw the normal T2 adaptor to the Tilter. The adjustments might be a bit fidely when the T2 adaptor base is placed right against a focuser.

[SimmoW]

Thanks Glen. Hope we don't need to use that often, it'll stuff up back focus setups for many ppl.

Just saw this gorgeous shot over at CN, 10 min subs.

The bloke mentions the firmware update, is that different to the ZWO driver download?

http://www.cloudynights.com/topic/547416-ngc6888-and-the-soap-bubble-with-skyvision-mt250-and-asi1600/

[glend]

Sam did a firmware upgrade on my camera during a Teamview session but i believe most, if not all, of that can be had via the latest driver download, but i could be wrong. Ask him.

Re 10 min narrowband subs, completely un-neccesary with this camera in my opinion. My standard narrowband sub is 5 min at Unity (Gain 139). You could i suppose shoot at a lower gain setting for longer to minimise the little noise there is but i find 5 min optimal for what i am doing.

[SimmoW]

Just saw this post at the ZWO forum, looks like amp glow is controlled by updated ASCOM drivers and options.

Nice to hear re sub lengths

[glend]

There is a very informative and detailed discussion on ASI1600MM-C Gain settings and performance impacts on Cloudy Nights currently running here:

http://www.cloudynights.com/topic/548199-meaning-of-unit-gain/#entry7403127

Jon Rista has expained it well and offers comparisons with the KAF-8300 chip cameras as well.

[glend]

For those interested, there is a write up (and images) on Cloudy Nights (by Jon Rista) on high gain narrowband imaging with the ASI1600, worth a read:

http://www.cloudynights.com/topic/549137-an-asi1600-high-gain-experiment-bubble-nebula/#entry7414496

[SimmoW]

Thanks for posting Glen, those results look very promising.

[Slawomir]

Interesting images taken with ASI1600MM and a range of telescopes: http://www.astrobin.com/groups/31/

[glend]

I had asked Sam (ZWO) about adding a heated cover glass (like the QHY163M has) to future model releases of the ASI1600 and I had this in an email reply from him today:

"you are corrent that we'd better add a heat board
but the back focus of current 1600 is too short and won't allow it to add one heat board
we will add one in our next APS-C camera".

So there you go, confirmation from the source, ZWO is developing an APS-C camera and it will have a heated sensor coverglass. Glad I bought the 36mm filters.

No details on the APS-C camera specs yet.

[SimmoW]

Good work Glen!

[Camelopardalis]

An APS-C sized chip isn't all that much bigger than the 1600, about 4mm wider and maybe 1.5mm taller :shrug: be interesting to see whose sensor they bag though :D

[gregbradley]

https://www.google.com.au/imgres?imgurl=http://photoseek.com/wp-content/uploads/Sensor-sizes_PhotoSeek.jpg&imgrefurl=http://photoseek.com/2013/compare-digital-camera-sensor-sizes-full-frame-35mm-aps-c-micro-four-thirds-1-inch-type/&h=590&w=720&tbnid=ar9AAXSUH1tAcM:&tbnh=160&tbnw=195&docid=OPd85ZSDMBDhgM&usg=__IAt6WUWGrRyAgKXl2ZbSwinM1Y8=&sa=X&ved=0ahUKEwiurJq4pNXPAhVnjlQKHZHfC_ QQ9QEIITAA

If its the 1.5 crop its significant. Micro 4/3rds cameras show more noise even at low ISO. A common complaint.

Sony Exmor 24mp APSc used in A6000 series, Fuji XT2, XPro 2 and others would be hot. Its got copper wiring and low read noise, under 1 electron at low ISO.

Greg.

[glend]

If you happen to scratch your ASI1600 sensor cover glass, as I did recently when trying to clean it, a replacement is readily available from ZWO.
It is not listed on the website yet but you can buy them for $28 (air shipping included). The cover glass product reference is: D32 AR window. Just email Vanessa at ZWO and she can fix you up via Paypal.

How did I scratch it? I was using a supposed clean camera sensor cleaning swab to wipe the cover glass surface and the swab or glass must have had some dirt on it, as afterwards I could see small surface marks in angled light. I guess the best approach would have been to blow it with a puffer first, or just leave it alone.:lol:

[Shiraz]

measured the absolute QE of the 1600 by comparison with the H694 using a white light LED source and Astronomik 2c filters.

B = 64%
G = 66%
R = 53%

method was a bit rough and the white light LED wasn't the ideal source, but it is good enough to suggest that the 1600 is pretty capable for a DSLR-type CMOS chip - confirms a gut feeling assessment from using the two cameras.

[Slawomir]

Would your results indicate max QE around 50%, possibly in green? BTW, looks like a fun activity measuring relative QE with a LED :)

[Shiraz]

those figures are the calculated absolute QE Suavi, not the performance relative to the H694 - so the maximum absolute QE has to be more than 66% - maybe just under 70% as a guess and yes, it will be in the green. The 1600 is not far off equivalent to the H694 in the blue, a bit less in the green and down to about 75% of the H694 in the red

[Atmos]

Excellent work Ray :thumbsup:

[Slawomir]

That is excellent then, good to see another confirmation of how good these new sensors really are. Thank you for clarifying that for me Ray.

[glend]

Thanks for working that out Ray.:thumbsup:

[glend]

The ASI1600 camera has a free copy of Sharpcap available via download from the ZWO product page. If you own any ZWO camera, that uses or can use Sharpcap, have a look at the new Polar Alignment function included in the new release:

http://www.sharpcap.co.uk/sharpcap/polar-alignment

In Version 2.9 you can polar align within Sharpcap, using plate solving - and it does not need an internet connection, something invaluable at a dark site.

Have a read of the briefing notes on the linked page. I have downloaded V2.9 but have not tested this new function yet, but it is an exciting development and addition.
Anyone using the Sharpcap polar alignment function, can you please give us some feedback?

[g__day]

Just bought a 1600MM-C + 7 *36mm filter wheel from Bintel yesterday - have it hooked up and all drivers loaded, with SharpCap and Firewire beta installed okay.

Utilities ran fine and TSX could control the camera and filter wheel okay - will see if I can put it through it's paces in about a weeks time.

[glend]

Well that explains the cloud. ;)
Are you loading ASCOM platform?

[g__day]

Loaded four drivers from memory and two application utilities. TSX connects to the camera and filter wheel using ASCOM interfaces - all worked correctly first go - but I haven't done any light frames yet nor reset focus for my OAG. Mostly it was about cabling and removing two Canon's and moving an custom cold box from one OTA's camera the other which had a slightly wider WO flattener attached.