In the latest version of EKOS, there is a new Optimal Sub-Exposure Calculator
Can someone please point me to how I calculate the sky quality measurement (SQM) and the filter bandwidth, which are needed in this calculator?
I would like to add that for all the SharpCap users we've already made Sensor Analysis and we have those data, could that be helpful?
For example, there are no data for ASI 533m.
In addition to that, please help me with this. So the output is that for a 533mono sensor (let's take this one), with a 3nm filter, under city lights, the best option is the 63,79s exposure ? Am I getting it right?
With regard to using SharpCap sensor analysis data:
I had a brief email exchange with Dr Glover. In the future we may be able to utilize his data files directly, but the ShaprCap files are in a binary format, and are potentially subject to revision which could cause maintenance difficulties in KStars code.
For this initial release of the calculator we are only providing a sample set camera data that we transcribed using documentation from camera manufacturers.
Guys, thank you for this functionality. I have played with the excel table, on which is most probably this calculations done, last week
1) Can I or other forum members provide you with datasets for other cameras? For example I have ASI294MC Pro, SV605MC and SW305M Pro
2) Can the SQM be calculated directly from one subexposure? I own an SQM, but many don't.
(I just attempted to upload a rough draft of documentation for the exposure calculator to this forum, but the pdf may be too large to be posted.)
The short answer to your question is yes. The calculator is recommending an exposure of just over a 1 minute, most likely due to the combination of relatively high noise from light-pollution and your relatively fast optic.
Now the long answer: Dr Glover's calculations attempt to provide an exposure time which results in reduced noise from just two sources, sensor read noise, and noise from light pollution). Essentially his calculations find a midpoint; an exposure which is sufficiently long so that sensor read noise is overwhelmed by the desired signal, but not so long that light pollution will over-whelm the desired signal.
In your example, with a Sky Quality of 18.55 there is considerable light pollution, and this will influence the calculation to produce shorter exposure times. But keep in mind that the calculator will adjust exposure times based on the gain selection. So, if you were to choose a lower gain, the calculated exposure time will increase because more signal is needed to overwhelm the higher read-noise at that lower gain.
Also Dr Glover's calculations include a factor which governs the balance of read-noise to light pollution noise. That factor can be adjusted in this calculator with changes to the "noise increase %". In his presentation, Dr Glover recommended the 5% value we set as the default. Lowering the "noise increase %" will change cause the calculation to allow more light-pollution, and the result would be a longer a exposure.
However, the values from this map tend to be "best-case"; no clouds that might reflect light-pollution and no moonlight. So, lowering the SQM value that is provided from lightpollutionmap.info may be needed. I have not studied how sever the effects of cloud reflection will change SQM. But I did make some tests for the effects of moonlight. This an excerpt from documentation that I'm preparing for the calculator:
At a location where a light pollution map showed an SQM value of 19.63. An SQM reading was made on a night with a waxing crescent, shortly before half-moon, (moon age 5.4, and KStars moon magnitude = -10). The reading at zenith showed a measured SQM value of 18.48.
A reading taken on a night with a waxing gibbous, shortly before a full moon, (moon age 12.4, and KStars moon magnitude = -12). The reading at zenith showed a measured SQM value of 15.95.
Potentially creating additional "custom" camera files on your local systems:
The camera data files used by the calculator are in an XML file format. So a user might be able to create new read-noise data files for cameras that we did not include in this initial release.
But please be aware: Dr Glover had asked that we do not publish data from his SharpCap application or from his sensor analysis tool. So if you plan to use data from SharpCap, please do not share this data with anyone. Dr Glover would appreciate it if folks wishing to use data from SharpCap register for a SharpCap account. Using the SharpCap sensor analysis tool would likely provide more precise camera read-noise data than what is published by camera manufacturers. Running the analysis on your own camera would provide you with custom data specific to that camera.
The camera data files included with this release should be in a application data folder that is not writable by users. On Linux that should be "/usr/share/kstars/cameradata/". (I do not know what path would be uses on Mac or Windows OS). However, I believe that the calculator will also look for camera files in an appropriately named folder under the KStars user local folder. In Linux that would be "~/.local/share/kstars/cameradata".
So, if you would like to try create additional (local) camera files, you might be able to do the following:
Create a folder named "cameradata" under the user local kstars path.
Find an existing camera data file in the application camera data folder; pick a similar camera type, if you are creating a file for a monochrome camera then choose a monochrome source file, if a DSLR, pick one of the DSLR files.
Copy the chosen camera xml file to the user local share kstars cameradata folder.
Rename the XML file in the user local share folder so that it is unique: If you want the calculator to select a camera based on the imaging camera selected in EKOS, the the name should be similar to the camera id show in EKOS, but spaces should be replaced with underscore. (Example: EKOS camera "ZWO CCD ASI071MC Pro" would use a file name "ZWO_CCD_ASI071MC_Pro.xml".
Edit this new XML file with a text editor:
Change the value of CameraId to match what appears in EKOS for the camera.
Alter the gain selections data in the <CameraGainSelections> tag. (Dedicated astronomy cameras just need two values max and min gain, but DSLR cameras need the discrete ISO values supported by the camera).
Alter, delete or add gain read-noise values in the <CameraGainReadNoise> tag as needed to match your camera.
Please be cautious in making these edits; if the file format has an error, the calculator may crash or loop.
If you run into issues, reach out to me. (But my response may be a bit slow).
Using LightPollution maps I found my sky brightness for my home (21.54) and my portable observing site an hour away (21.98). I live at 7,000'.
It would seem that humidity makes a difference to. At my home, humidity ranges from 0 to 60% with an average of 25%.
I can visually notice the sky brightness difference when the humidity is in the single digits - vs when it is over 50%.
I guess having an SQM meter may be best vs using a static measurement from the maps.
Regarding the filter bandwidth.. I understand the narrowband filters easy enough - but for LRGB do I use the total width? For example, the LUM is 420 – 685 nm. Does that mean I use 265nm?