Hi
Please find attached a narrowband version of an astrograph design spreadsheet (as foreshadowed in http://www.iceinspace.com.au/forum/s...d.php?t=151000). The layout is the same as in the earlier post, but the underlying maths tries to take into account the specifics of narrowband imaging. You do not need to be bothered with any maths to use it though - just plug in data and play.

the spreadsheet essentially puts most of the theory in one place - you can enter your sky conditions, target brightness, telescope, mount guiding, filter, camera characteristics and desired imaging time. It will tell you:
your sampling/resolution,
the expected FWHM at the focal plane,
the field of view,
the overall SNR performance with different sub lengths,
the optimum sub length,
the effective well depth after stacking and
the ADU value that you should see in the sky background of a sub.

It is a protected excel spreadsheet, but it also runs under openoffice. Best to unzip and scan it first. Excel will try to protect you and query if you really want to use a web sourced spreadsheet. In openoffice, you will probably need to enable editing to get it to work. It has no macros and has been zipped for attachment through IIS. I use a fully up-to-date win10 system with the Microsoft security suite.

this version has only been validated on my system and should be suitable for available filters with optics of f4 and above - if anyone uses it, would be grateful for feedback - I will incorporate any changes needed to improve it. It allows different systems to be compared or any "what if" changes to an existing system to be assessed - before spending any money. It may be of real value to anyone considering one of the low read noise CMOS cameras or 3nm vs 7nm filters - do they really make a difference with narrowband? I have tried to put in instructions and explanatory notes - are they sufficient?

Thanks, Ray. I was hoping to have a close look at the broadband version but haven't quite got there yet. Now I have two models to check out I have a long plane flight coming up soon...

the main difference between the two models is in how the sky and target photon signals are derived. The resolution is also spectral in the narrowband model, but otherwise they are basically the same.

If anyone is interested in this or the broadband calculator, but doesn't wish to risk running a downloaded spreadsheet, I will gladly do a run for your system - just post the following:
- your sky (dark, bright, SQM etc)
- the target brightness if you have any info
- your scope type/size
- your mount type
- your camera
- your filter type

I will do a run and post a screen image of the results. If you want to compare systems, provide data for both.

Thanks for your interesting spreadsheet! I'm trying to reproduce part of your results, especially the calculation of the item "FWHM in the chosen atm."
As I understood,

FWHM in the chosen atm = SQRT(seeingFWHM^2 + scopeFWHM^2 + (2.35*guidingRMS)^2)

I'm using Airy's formula
scopeFWHM = 1.028 * Lambda / ObjectiveDiameter.

My results are a bit far from the result of the spreadsheet. Where am I doing it wrong? Many thanks in advance!

the spreadsheet includes Airy's formula for the optics, but converted to arcseconds and added in quadrature in the complete FWHM calculation. hope this helps.

the complete FWHM formula is: FWHM in the chosen atm = SQRT(seeingFWHM^2 + scopeFWHM^2 + (2.35*guidingRMS)^2). It combines seeing effects, scope resolution and guiding blur.

yes, that formula is used to get the scope fwhm in radians. That is then converted to arc seconds.

The scope fwhm in arcseconds is then added in quadrature to the seeing fwhm and the guiding fwhm to yield the total fwhm (in arcseconds) using the first equation in post #5. This is in effect like a convolution of the three blur terms - the total blur is not just the optics blur.

For most conditions, the total system fwhm will be much larger that that calculated using the Airy formula alone.

1) Target Brightness; Stupid question, but what does the p in p/m2/s/arcsec2 stand for? I see that it requires in-the-field measurements - does that mean the intended use is not as a preparatory tool, but more as an on-site drilling down into what the histogram is showing?

2) Gain - I'm confused about the difference between the gain setting on the camera and its actual value in ADU's. Is unity gain (139) where all 20,000 electrons in a well are distributed among the 4096 possible values in 12 bit ADC? That would make it 4.88 e/ADU. at unity gain. Is that correct? I have no idea how to work out the gain for other levels though. Or do I just put in '139'?

3) In band QE; The peak QE of the 1600 is 60%. Reading the relative graph which is scaled to 100% (one assumes 1 = 60%QE because it's *relative QE). So for Ha at 656nm the *relative QE is about .78, which is to say, 0.78 of 60% = 46.8% actual QE in Ha, right?

4) Total exposure time. Why whole hours only? Surely there are some who would like to do less? Maybe not for NB, but the RGB sheet is the same? Seems an odd restriction but what do I know?

5) Reading the results; so I guess I'm looking for the point of diminishing returns here? The point where the graph flattens out?

great work! I'm just planning my first narrowband observation and therefore find your spreadsheet particularly helpful.

Thanks for sharing,
Erwin

Good luck - hope the spreadsheet helps

Quote:

Originally Posted by Stonius

Thanks for putting that up!

I have questions as to its use;

1) Target Brightness; Stupid question, but what does the p in p/m2/s/arcsec2 stand for? I see that it requires in-the-field measurements - does that mean the intended use is not as a preparatory tool, but more as an on-site drilling down into what the histogram is showing? p is photons. It is useful as a preparatory tool if you specify a low value here as suggested. I don't know of any measurements of nebula surface brightness, or would have used real data. If you find any, please use.

2) Gain - I'm confused about the difference between the gain setting on the camera and its actual value in ADU's. Is unity gain (139) where all 20,000 electrons in a well are distributed among the 4096 possible values in 12 bit ADC? That would make it 4.88 e/ADU. at unity gain. Is that correct? I have no idea how to work out the gain for other levels though. Or do I just put in '139'? "gain" for the CMOS chips is a complete dogs breakfast. The gain term in the graphs on the ZWO1600 page is specified in "gain" in ADU/e for a given gain setting (eg 139) and refers to the 12 bit ADU. It is also related to the 16 bit values measured in the output files. The spreadsheet sorts it out if you use the manufacturer's 12 bit ADU/e value from the graph (eg at gain 139, the ADU/e is 1.0) - and set the padding bits to 4

3) In band QE; The peak QE of the 1600 is 60%. Reading the relative graph which is scaled to 100% (one assumes 1 = 60%QE because it's *relative QE). So for Ha at 656nm the *relative QE is about .78, which is to say, 0.78 of 60% = 46.8% actual QE in Ha, right? yes

4) Total exposure time. Why whole hours only? Surely there are some who would like to do less? Maybe not for NB, but the RGB sheet is the same? Seems an odd restriction but what do I know? you can use other than whole hours, but then the tabular results will be very slightly in error. Rather than rewrite that part of the spreadsheet or get into a post storm trying to explain/define what the problem is and why it doesn't really matter, I decided to just specify whole hours. If you are interested, the problem can be illustrated by considering that someone specifies a total time of 23 minutes of 5 minute subs - results in a total of 4.6 subs, which is nonsensical.

5) Reading the results; so I guess I'm looking for the point of diminishing returns here? The point where the graph flattens out? yes. The spreadsheet also provides a calculation of read noise effect. Choose a sub length that provides about 5% for this value and you should be on the edge of the flatter bit of the curve

1) p is photons. Duh! What is the name of those things we're trying to capture again? :-P

2) Gain.

Okay why can't I maths this out? It makes sense that unity gain is where 1 electron in = 1 ADU out (power in = power out). This results in 4096 levels for 12 bit, which corresponds to 4096 photons.
I can't figure out how the number 139 relates to that. Padding with 4 LSB bits just multiplies the total by 16, right? So 139 * 16 = 2224.
Which is still not 4096.
I understand that the spreadsheet works and this is just my mathematical shortcomings, but I wish I understood how they got that number. As far as I can tell unity should be at 4096/16 = 256 which is wrong, I know, but I don't quite know why...

139 means that the gain of the chip is set at 13.9 dB above its minimum gain - it doesn't mean anything more than that.

At gain 139, the well depth is ~4000 electrons (from the ASI data). I assume that the internal data transfer process at gain 139 can only accommodate the signal equivalent of 4000 electrons and in any case, after the padding bits are added, 4000ADUx16 is all that will fit into the 16 bit words in the file.

BTW, I don't think that unity gain has any particular significance. eg, my SX H694 camera has a gain of about 0.35 e/ADU, whereas the FLI Microline 16803 runs at 1.4 e/ADU and both appear to work fine

So each 30 'gain' is a stop, basically. Each 100 gain is ten times brighter (or dimmer).

The gains I've seen ppl using are 75, 139, 200 and 300.

As near as I can tell, gain 75 would correspond to an e/ADU of about 4.8, which means the entire 20,000 range of the wells are distributed across the 4096 possible ADU values.

139 is 1 e/ADU

If I got this right, then gain 200 corresponds to 1024 ADU levels, or essentially a 10 bit image, and gain 300 is somewhere between 6 and 7 bit with only around 100 ADU levels.

I don't suppose I'm going to break anything if I scale my gain settings in db from 139 for exact bits so there's no rounding weirdness in converting from e to ADU's eg; 139, 169, 199, 229, 259, 289, etc

The gains I've seen ppl using are 75, 139, 200 and 300.

As near as I can tell, gain 75 would correspond to an e/ADU of about 4.8, which means the entire 20,000 range of the wells are distributed across the 4096 possible ADU values.

Markus

I use gain 100 because dividing the DN by 10 gives ~the electron count - easy for pixel peeping .

Re the well depth at gain, not sure what the architecture is, but apparently there is (variable?) gain at the pixel level. The effective well depth varies with the gain, presumably because the post-pixel internal data transfer mechanism/(or maybe ADC?) remains at 12 bits equivalent capacity.
eg, at gain 75, the "gain" (12 bits) is about 2 e/ADU, so, if the maximum transfer capacity is 12 bits equivalent, the maximum possible signal before saturation is 8192 electrons. The ZWO site lists a well depth of ~8000e at gain 75, so that theory works. This would imply that the linearity should be excellent for reasonably high gains, since the data will be truncated before the wells get anywhere near their physical capacity - seems to be the case.

I got my numbers backwards and inside out. Did I mention that maths is not my strong suit? (sigh) Guess I'll just keep blindly following what others are doing and experimenting with the limited time available. :-)

Is there a simple mathematical correlation between FW(-e), Gain (e-/ADU) and DR in stops? I just want to be able to figure out which gains represent whole stops from unity and which ones will result in quantisation error-free results.

I can't make head or tail of the graphs; The x axis is supposedly in 0.1dB increments, so the difference between 0 and 300 should be one stop, (3dB = ~ 2x increase in power) but it's not. I guess I'm thinking of dB mostly from a sound background and obviously this is some new usage of the term I wasn't aware of :-P

the quantisation error is minor and well submerged under the read noise. I think that you can safely ignore it - like all camera makers do. Use any gain that makes sense - main considertion is probably the sub length.

the graphs go from 0 to 30dB - I think that it is the same usage as in sound. eg going from gain0 to gain139 (a change of 13.9dB at 0.1dB per gain unit) changes the (inverse) e/adu by a factor of 5, which is ~14dB - close enough.