The specifications specify 5 volt and 6.6 volt. The largest current is 5 amp. A power supply of the standard value of 6 volt and 6 amp or more will do. 24 volt is incorrect
Stepper motors can run on a lower voltage. They have then less power. Much more then rated is not recommended. Just read the specification.
Probably the best thing is to update the focal ratio & sensor size in Ekos. What you could do is open an unsolved image in the ASTAP viewer. Look to the status bar and you will see the dimensions. Then solve the image in ASTAP or Nova.Astrometry.net and see if the dimensions match with the unsolved image. If they change more then 5% then adapt the focal ratio or sensor size in Ekos. This will be only effective for any new image. To test it with the image in the ASTAP viewer you could overwrite it as shown below.
ASTAP can handle differences up to maybe 30% but solving will be more unreliable. So better correct this.
Thanks for the feedback. Looking to your second image, the stack routine made a mistake. It is also in colour. The first image looks without colour, so I assume the conversion to colour can be switched off. See below. That will speed up the process.
I will look into the flats tab problem.
mpfjr wrote: I have a Raspbian Buster 64bit OS install on my Raspberry Pi 4 and everything is 64bit which I am happy with.
However, the .deb packages from the ASTAP website that are 64bit do not install using package manager. They all told me they could not be installed. So I grabbed the 32bit which was armhf and it worked fine for the install. I have not tried it live yet.
If there is a way to install the 64bit Aarm64 bit version I would love to know what it is I have to do.
Essentially I downloaded the Rasp buster full from Raspberry pi's website. Did all the updates to it to bring it to latest version. Then I used the install script from AstroPi3's thread. Then updated everything again. Then tried to install ASTAP.
Unfortunately only the 32bit version would install.
I'm a little surprised that the 32 bit installs and the 64 bit not. These are not interchangeable. Maybe there is confusion about the architecture. 32 bit is for armhf and 64 bit arm64. But also AArch64 is used.
You should be able to extract the files like this
sudo dpkg -i /path/to/deb/file
All the files are normally installed at /opt/astap
No dependency. can be installed at any location
Please tell me if you get it working.
schwim wrote: Hi Han,
I'm testing live stacking on OSX. I see the OSX build is listed as being a version or two behind the others. Is it possible to get an OSX build? I'd like to provide feedback on the latest and greatest so I'm not reporting things that are already resolved.
Just released a new macOS version (0.9.298). It would be nice if you could test it. My testing of the macOS version is very limited. I compile it using virtual machine running 640x480 resolution running on a old laptop.
G_Gagnon wrote: Wondering if the 64bits RPI build for ASTAP can be used with the ODroid N2 (ARM architecture) or if a separate build is required.
Both the ODroid N2 (A73 processor) and Pi4 (A72 processor ) are using ARMv8-A 64-bit instruction set. So I expect the ASTAP 64 bit Pi version will run without problems on the ODroid N2 assuming it running Linux and not Android. Try it and tell me.
If your field of view is not very small, you could use the G16 database instead of the G17 to save some space.
Carneb wrote: I'm using Kstars 3.3.7 on RPi4 running Stellarmate and tried to use the ASTAP solver but it's not working. I click on the solve button and literally nothing happens. I went to the directory listed in the options to try to start ASTAP and it seems there is nothing there? Do I need to install it separately? I would have thought that if it's part of the Kstars package then it would already be installed with the Kstars install? Having said that I am a Linux newbie so may be missing something obvious.
It is a separate program. You have to install two Debian packages. One for the program and one for the G17 star database. You can find them on this webpage:
You can download for the Pi4 the 64 bit version and 32 bit version. At the moment I'm not sure if Stellarmate is 32 bit or 64 bit.
The G17 star database is the same for 32 bit and 64 bit.
ASTAP can be used as command line solver only. But for the other functions and analysing you can just start the GUI from menu topic Education. ASTAP is not only a solver but also a fits viewer, stack program. CCD inspector, deepsky annotation program and photometry program.
Hyperleda annotation near M5:
Photmetry, automatic measured star magnitudes near M31 in comparison with AASVO chart:
The command line parameters will have preference. So they will overwrite the setting set in the GUI.
Easiest way to test the solver is to load a FITS image in the viewer. The important data will be extracted from the header like mount position and focal ratio and so on. The Solver specific settings can be set in tab alignment of the stack menu. Loading and solving RAW files like CR2 file is also possible but DCRAW should be installed and you have to set the initial RA, DEC position in the viewer and image height in tab alignment. So for RAW you better test with EKOS.
Settings will be save automatically so if you change some important parameters, reset them later to default from the viewer, File, SETTING, RETURN TO DEFAULT SETTINGS AND EXIT.
G_Gagnon wrote: What I found running ASTAP, in a simulated environment (pointing to Alnitak), is that it would not solve with an exposure of 8 seconds but did solve with an exposure of 4 seconds; and wickedly fast (1~2 seconds). I have not done thorough tests but it would seem that the number of stars used to solve, as mentionned previously, may be a factor as there will be more stars in longer exposures. I will do another simulated test with less stars being used when using longer exposures. So, if ASTAP doesn't solve you may try to reduce the exposure in astrometry.
As far as real life solving, the current weather tells me that I will have to wait .
Bright or very bright stars are normally not a problem. It will work with 2, 5 or 300 seconds exposure. Default there is a star limit of 500 stara. If it sees more stars (typical much more) it will take only the 500 brightest stars (default). Try it live if the weather allow but check prior the conditions above. Especially image height should be at least 1000 pixels (check binning) at focal ratio & sensor size should be set reasonable correct in Ekos . If the search spiral is beyond 2 degrees it will show this popup notififier:
- The first line indicates the search spiral distance (8º) from the start position and the maximum search radius (90º)
- The image height in degrees (1.32º).
- Downsample setting and the input dimensions of the image to solve. (0 is auto)
- The α and δ of the start position.
- Speed normal (▶▶) or small steps (▶)[/li]
Hopefully the weather clears up soon for you.
AstroNerd wrote: I wanted to share my findings using the new ASTAP, when it works it is super fast. But I can only get it to work about 40% of the time, the rest of the time it will not solve and just times out...when it works it’s done in a few seconds...but the rest of the time I just get a box come up in the top left corner of the screen and it just times out...well there is a number in that box that is counting up, so I assume that’s what it is...
What I have noticed is that if you point to random parts of the sky, it seems to work, but when I slew to a specific object such as a galaxy, cluster or Nebula, it will not work, and have to switch to Astrometry.net to get the solve...
Also I have tried with the simulators in Ekos, and it’s the same story with those too....
I suspect this is either the
1) image size in pixels
2) image height in degrees (focal ratio & sensor size)
for 1) The image in pixels provided to ASTAP should be at least 1000 pixels high. Can you check that?
for 2) What is are the image dimension of an unsolved image indicated in the status bar of the ASTAP viewer? Do they change a lot after the image is solved? If so the initial EKOS settings focal ratio and sensor size are not accurate.
If this doesn't help, could you provide an image for testing?
Small change after solving