han59

Measurement of the SQM is accessible via the command line so SGP could read it. In principle you could also get a good indication via the image background value if you keep the exposure the same, so I don't think it is essential to monitor it all the time. It is more to get an absolute reference value for a site. It will work even with H-alpha filter as long the image background is increased b y the sky background. So at my site, SQM=20.4 best and 200 seconds exposure it works. The value differ slightly compared with broad band subs. 30 minutes sub, could work but the image should be solvable and stars of magnitude 18 are not saturated. Saturated stars will be ignored. Han

Nina is testing for the G databases. They removed that in the latest nightly build. There was no need for since this will be done by ASTAP. The new H databases are faster. So in the long term it is better to switch to the H version and remove the G versions. Han

For the record: Today I looked more in detail to atmospheric extinction. The likely reason that the Unihedron and ASTAP reported values are very simular is the fact that the Unihedron calibration is about 0.35 magnitudes corrected. This is equal to the extinction in the zenith: http://www.lightpollution.it/download/sqmreport.pdf

The reference are the stars. Like the Sun they are fainter near the horizon due to extinction. So the ASTAP SQM value will be lower at lower altitude/elevation because the stars are fainter as at zenith and therefore the sky background will be seen as brighter. The difference between zenith and 45 degrees altitude/elevation is maybe 0.12 magnitude but at zenith there there is still an extinction of typical 0.28 magnitude (depending in humidity and observer altitude) . I didn't measure that difference for unknown reasons, but it will be interesting to see if the values from the Unihedron meter and ASTAP start to differ at lower altitude/elevation. So I'm very interested in other test reports. I also know that some Unihedron meter show a different value

Just realizing that altitude and transparency plays a role. Measurements where done at zenith. At lower altitudes the stars are fainter so probably it is better to talk about relative SQM value. So maybe it is a coincidence that the values are so close.

The ASTAP measurment doesn't require an external calibration. After solving you can measure the "star flux/(2.51^magnitude)" ratio using the star database and this value will be constant. Outliers and saturated stars will be ignored. With the "star flux/(2.51^magnitude)" ratio you can precisely express the background signal in magnitude per square arc second. So this measurement doesn't need calibration. It is calibrated each time against a star database. Dirty optics or aging has no influence as with the Unihedron meter. As long the CCD or CMOS sensor is linear it will work. Maybe the biggest problem is the signal reduction at the corners of the image but that can be compensated by applying a flat. But probably not required due to averaging. Above measurement was done without applying a flat. Han

The free ASTAP program version ß0.9.480 has a new experimental option to measure the sky background accurately in magnitudes per square arc second . This is the same value as reported by portable Unihedron SQM meters. As soon an image is solved, the program can calculate the link between measured star flux and the star magnitude from the database. This flux/magnitude relation can also be used to measure the sky background value. The achieve the highest accuracy a pedestal values can be entered which is the same as the mean value of a dark/bias image. Below the first result of a field test this evening. Unfortunately the Moon was shining so it doesn't go further then SQM 18.4 and I had to avoid some passing by clouds but the result is good and accurate. See the graph below. Camera used was the ASI1600MM in bin 2x2. Exposure time adapted from 0.5 second to 30 seconds. No filter. Operation is simple. Load an image, hit the solve button, then select the fully automatic SQM measuring tool. This is a new feature. Feedback is appreciated. Han Menu: Comparison between a Unihedron SQM-L meter and ASTAP

A new version (0.9.74) of the free CCDCiel program has been released. With this program the imaging of deep sky objects can be fully automated. But it is also possible to manually operate the different steps. There are Windows, Linux, Linux RPi en Mac versions available. In this version the sequence routine has been optimised and improved. Editing the sequence while running is possible. For me this is a great version and the preliminary versions where a pleasure to work with. Han Webpage: https://www.ap-i.net/ccdciel//en/start Announcement of the new version: https://groups.io/g/ccdciel/message/977

I suspect you downloaded the new database H17 and the program on the day the ASTAP program was upgraded from G17 to H17 databases. So a transition period. For the H version of the database you will need version 0.469 or higher. I would suggest to install the latest ASTAP program and try again. Databases are simply installed in the same path as the program and normally never have any location or path problem. The only time access problem occur is in very rare cases where a second ASTAP is still in memory searching and they try to access the same database. Task manager will show that. For any solve problem just ask me for more assistance. Either here, personal message or on the ASTAP forum. Han

Even with uneven spaced holes, you still should be able to center the secondary.

Thanks for the image. I have analysed it in (my) ASTAP using the same image orientation. The values are difficult to compare. The average HFD is 6.6 or 10.8"which is comparable with the CCD inspector value. In ASTAP the tilt and curvature are expressed in delta HFD and not in %. The tilt is delta HFD 0.23 equals 0.12*1.63"=0.19". The curvature so the difference between center and outer areas is 0.7 HFD equals 1.12". The strange thing is that all stars are oval as also indicated by the PI image. Must be optical imperfections. The star ovality will skew the measurement. Maybe it is possible to partly correct by adjustment. The center is better then the out regions as indicated in the second plot but that is for any telescope. Han Later, I made a mod (not released yet) excluding the saturated stars. Saturated stars give a higher value then normal. The second plot indicates the worst corner is right top followed by left bottom, right bottom. Let top is the best. HFD values for each star: HFD HFD plot. Darkest areas are the lowest HFD values. For each detected star one grayed area.

It is pretty sharp image and full of stars. I'm interested to try it in the ASTAP inspector to compare. Can you share the full resolution in FITS format? Han

@bokser01, your last two images look fake.

Star labels or abbreviation is fine for the brightest stars. For the fainter stars it becomes a catalog number or in the latest catalog just the position (IAU_designation) as in the new Gaia star database. Gaia is the latest and most accurate star database. You could use a solved image as a background in a planetarium program and by that identify the (variable) stars and their catalog number in several star catalogs. Simbad can also give information based on the position. Using the online Simbad is implemented in CDC and HNSKY planetarium programs and probably in other planetarium programs or you can request it directly online in Simbad. ASTAP can give the Gaia star database magnitude & colour and also the measured magnitude. It can also annotate variable stars. PS2 or Astronomy.net can not. Han

Provides us with a test image for further investigation. E.g. upload it to nova.astrometry.net and give the link. - You should see 30 or more stars on the image. Longer exposure time helps. With a F/5 system a few seconds is enough but for long focal lengths maybe up to 30 seconds is required. - Don't bin too much. Keep dimensions equal or above 1280x960 pixels. Han

Today I had finally the possibility to test the auto focus routine of CCDCiel on some new Sun spots. This is option "planets" of the autofocus routine and it works on the Sun, Moon and planets. The Sun altitude was only 20 degrees but it worked as desired. For those who are interested, I have uploaded the result on YouTube: Han

FYI, below a screenshot of the latest Sky Simulator for ASCOM version 0.1.18 in combination with PHD2. It introduces a cyclic RA error of 20"over 5 minutes and seeing error of 3". Han

Rotation of RAW files is also prevented for DCRAW by adding -t 0 in the DCRAW command-line. ASTAP version 0.9.427 Han

I just noted the ASTAP convertor option Libraw ignores the rotation for .ORF files. Default it is set at Dcraw. You can the setting "Raw conversion" to Libraw in ASTAP, tab Stack method. It is bottom left of this tab.

IC1318a and surroundings are in H-alpha the brightest part of the northern Milky-way and currently near the zenith. My first idea was to create two different images but the area is so large that I decided to make a mosaic. Making the mosaic was possible with ICE from Microsoft but the resolution of the output was less the expected. For that reason I overhauled the image stitching routine of the ASTAP program to cope with these two difficult images. There is no empty space only clouds. The lights where first stacked into two different images and then combined using the ASTAP image stitching routine. The result is very good. The stitch is not visible. Han Telescope 100 mm APO astrograph APO100Q, F5,8 ASI1600MM-Cool Camera Filter H-alpha 7 nm 9 uur exposure in three nights in late september2020 CCDciel en ASTAP stack program

The flat and dark should have the same pixels dimensions as the light. So the same height and width in pixels . This is the only reason why the programt would not accept them. The image dimensions width and height are indicated at each tab after pressing the button analyse. In some case conversion from RAW to FITS could cause the problem, especially with Libraw which in some cases converts to portrait mode instead of landscape. In tab Stack Method you can select DCRaw or Libraw. DCRaw works the best but doesn´t support the latest formats. Assuming rotation is the cause you could rotate the images 90 degrees batch wise in the tools menu of the viewer but I have no idea if they should turn clockwise or counter clockwise. If rotation is the problem you probably best start over again with the RAWs and select DCRaw for conversion. Han

Just uncheck the options inside the red marked area as shown in the screenshot. These options are intended to allow automatic selection of a dark or flat based on light exposure time and/or temperature. If you have only one (master)dark and master flat or they don't have the info in the header (DSLR) you don't need this option . Han

Note in ASTAP there is a minimum star size setting which default is set at 1.5 arc second to ignore hot pixels. Secondly it will ignore stars of one pixel (HFD<0.8) since they are most likely hot pixels. For ASTAP it could help if you force the binning to 1 instead of auto=0 keeping the stars in the image larger. The ASTAP CCD inspector will tell you the average HFD and star size in arc seconds. Han author of ASTAP

Since it is less then 5% off, an update is strictly not required, but why not?

Good to know. For the record version 0.1.16 "Sky Simulator for Ascom" has been released fixing a bug. Reading a subsection of the camera image didn't work (typical used for focusing) but has been fixed. Han