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

Quote

The different zero point is likely due to the fact that the relation has been obtained with outside-the-atmosphere magnitudes V’ and B’. As an example, assuming an extinction of 0.35 mag in V and 0.15 mag in B and replacing V’=V-0.35 and B’=B-0.15, where V and B are the apparent magnitude below the atmosphere, we obtain SQM−V= 0.2(B−V)−0.31 in agreement with my previous results. The zero point of the current SQM calibration made by Unihedron gives SQM≈V’ for stars with B’=V’, above the atmosphere, and consequently the below-the-atmosphere SQM-V correction factor for the alpha Lyrae spectrum come out different from zero. Fig.18 shows that for alpha Lyr is SQM-V=-0.35 mag arcsec−2.

 

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.

Quote

Extinction becomes significant when altitudes are lower than about 45 degrees. At sea level, zenith extinction is 0.28 magnitudes, and at an altitude of 45degrees it’s 0.40 magnitudes

 

 

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

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

On 07/01/2021 at 01:09, Celestron4 said:

2) Astrometric Stacking Program (ASTAP) gives me the error (ASTAP error) attached below. I have the H17 database installed (twice) in the astap folder and it clearly can't find it. 

 

Any ideas how to solve these?

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

Quote

ANNOUNCEMENT:

ASTAP solver is moving from G17, G18 to the H17, H18 databases. The stars are split in 1476 files of about 5x5 degrees instead of the usual 10x10+ degrees for the 290 files. The blind solving speed increases if your  field-of-view is equal or smaller then about 1.5 degree. Blind solving speed doubles at a field-of-view of 0.5 degree compared with using the G18 star database.

There is no urgency to replace the existing G17, G18 databases. They will keep on working. In the long term I would recommend for field-of-view smaller then 1 degree to move to the H18. There is no penalty for using the H18 instead of H17, same speed only the size is larger and it goes deeper. A write-up to clarify some things in detail will follow later.

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

1 hour ago, Bob_the_Science_Guy said:

Not all three plate solving means even work, for blind solve, 

ASTAP never seems to work, either in point craft or locally stand alone

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

On 28/09/2020 at 18:12, almcl said:

To deal with the flat problem, can anyone tell me what the message:

"Warning, could not find a suitable flat for ""! De-classify flat filter or add correct flat."

means?  I've failed to find it in the documentation, and am not really sure what 'De-classify' might refer to in this context.

I am using flats that DSS was quite happy with and it has created a master flat but then steadfastly refuses to apply it.

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

14 hours ago, david_taurus83 said:

I find if my lens is slightly out of focus ASTAP will solve with bigger star profiles but with good focus and tiny stars at short focal length it struggles.

No issues with PS2 or ASPS, just slower.

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

11 hours ago, Rustang said:

If point craft detected a Focal length of 430.18 shall I continue to enter that instead of the actual 420mm which is what the scope FL is!?

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