han replied to the topic 'Using Astap solver' in the forum. 23 hours 37 minutes ago

Good it works for you. The Debian package installer should warn for the wrong architecture.

Read More...

han replied to the topic 'Using Astap solver' in the forum. yesterday

Okay, next thing to check if you can execute astap from the menu education or just type the command /opt/astap/astap. Then try to load and solve an image manually in astap.

Han

Read More...

han replied to the topic 'Using Astap solver' in the forum. yesterday

The correct location of the astap executable is at /opt/astap . That location will be created using the provided Debian package for installation.

Read More...

han replied to the topic 'Using Astap solver' in the forum. yesterday

Ron,

Both should work with the difference that Astrometry.net will solve even with the wrong FOV. But Astrometry.net is slower. With ASTAP it will solve within 5 or 10 seconds on the Raspberry Pi.

Can you provide a link to one of your images, so I can have a look to the header? Tell me also which binning setting you set in Ekos for solving.

Han

Read More...

Jim thanked han in topic Live stacking methods? 2 weeks ago

han replied to the topic '30 sec delay on align module' in the forum. 3 weeks ago

Taking dark(s) is easy. Just cap the (guide) telescope and take image(s) of the same exposure as the images you want to solve. Once you set the option "calibrate prior solving" ASTAP will calibrate any image first by subtracting the available dark(s) from the image. Solving will work better for your uncooled ASI120. This will work also when called from EKOS, but test it first in the ASTAP program. The dark subtraction will remove all hot pixels.


You screenshot looks like you have switched on de-bayer by accident. I assume you have mono camera. This de-bayer could spoil solving. In the viewer go to menu TOOLS and uncheck "activate-deactivate auto de-bayer". Or go to settting and activate restore defaults.

The M33 will solve if you activate options "slow" and tolerance 0.007 or 0.009 despite the hot pixels.


Han

Read More...

han replied to the topic 'Re:Re:30 sec delay on align module' in the forum. 3 weeks ago

I have looked to the images. The big stars are not a problem for detection but the number of hot pixels due to the uncooled ASI120. You can see that if you load the images in the ASTAP directly and use the CCD inspector option (in viewer, menu Tools, CCD inspector). Normally one pixel stars are ignored but due to the noise some are seen as stars.

- NGC2175 image solves if I reduce the maximum number of stars to 80 and tolerance to 0.009. This removes the hot pixels
- M33 solves
- NGC281, fails due to oval stars.

The solving will improve a lot if you use a dark. This is an option in ASTAP but rarely used and also a good opportunity to test now.

First make a few darks with about the same exposure time. Or make several e.g 5 of 10 sec, 20 sec, 40 seconds

To set and test this option in ASTAP:

1) Start ASTAP from the education topic menu

2) Load an existing image in ASTAP e.g. NGC 2175_Light_40_secs_001.fits using the viewer menu, FILE, LOAD FITS OR OTHER FORMAT.
3) Open the stack menu CTRL+A and set the red marked options including "Calibrate prior to solving" in the tab ALIGNMENT:



4) Add the darks to the tab DARKS. If you have with more then one exposure time, then activated option classify on DARK EXPOSURE. In this last case the darks should have exactly the same exposure time as an image otherwise they are ignored. If not leave this option unchecked and ASTAP will use any dark.



5) Then hit the SOLVE button in tab alignment or in the viewer. The settings will be saved. Solving should work better now. ASTAP will remember the settings and dark(s) if called from EKOS.

Could you share a dark so I can test it here?

Regards, Han

Read More...

han replied to the topic 'Re:Re:30 sec delay on align module' in the forum. 3 weeks ago

Hello rbarberac,

Exposure time should not be critical. Either 1 or 300 seconds should work. Could you share a few images made with the guider, so I can have a look?

Han

Read More...

han replied to the topic 'Re:30 sec delay on align module' in the forum. 3 weeks ago

rbarberac wrote: s (no, I can't use ASTAP because my guide CCD is very small, with only 960px and ASTAP needs at least 1000px so the alignmen always fails)[/attachment]

The 1000 pixels is not an hard boundary. The reliability for poor image reduces below 1000 pixels but it should still work. Setting the tolerance form 0.005 will 0.007 will help.

Han

Read More...

han replied to the topic 'New Kstars 3.3.7 ASTAP Plate Solving Speed is FAST!!!' in the forum. 3 weeks ago

An other thing you should check is binning. The height of the image send for solving should be 1000 pixels or more. So reduce binning accordingly.


Checklist for reliable solving:

ASTAP behaves differently then Astrometry.net. As long you adapt the settings for that , it will work fine:

- Resolution, the image height should be 1000 pixels or more. So adapt (decrease) binning.
- Stars shall be pretty round and reasonable in focus.
- FOV (field of view) shall be specified within 5 % accuracy for maximum reliability but detection is possible if FOV is 30 or 40% off. So set telescope focal ratio, sensor/pixel size correctly in INDI.
- A minimum of about 20 to 30 stars should be visible (this could be just above noise level. Exposure time of 1 or 2 seconds can work)
- Image shall not be severely saturated or stretched. RAW images works best.

The FOV is detected from the values in the FITS header. To check the FOV, start ASTAP from the applications menu Education and open an unsolved image in the ASTAP viewer. The image dimensions in degrees will be shown in the ASTAP status bar and are updated as soon you solve the image. If the dimensions change a lot (more then 5%) you better update the focal length and or sensor size settings in INDI.

The image dimensions are indicated in the popup notifier which is show as soon the solver is 2 degrees from the starting point:

Popup notifier indicating 2328x1760 pixels




Han

Read More...