Can't plate solve using RA/DEC hints
Stacking program, astrometric (plate) solver, fits file viewer
Brought to you by:
han59
Menu
▾
▴
I have a new mount and since installing it, I am having issues plate solving. I am using NINA but have also used ASTAP directly to try to solve.
When I configure ASTAP to solve manually, and do full blind solves, it works. What is very odd is that if the image has an RA/Dec value in the header, it fails on a regular solve, even though the header values for RA and DEC are basically the same value that ASTAP returns on a blind solve. If I do a regular solve on an image taken seconds after that previous image, but with the mount disconnected in NINA so the fits header has no RA/DEC, and I provide ASTAP with the RA dec in the textboxes on the top left of the screen, it solves instantly.
But this fails in NINA every time, because images taken in NINA have both the RA and DEC in the fits headers and are also sent to ASTAP via the command line params. This is the main issue I'm trying to solve - I can't get any plate solves working in NINA on this Pier right now. Using latest version of ASTAP exe and the D80 star database.
Tried to attach the fits files but get a server error from sourceforge. Let me know the best way of sending the files.
Mount Connected
Mount Disconnected (no RA/DEC in header)
here
Hi Jeff,
They only way solve reliable when you activate the option slow. I think that is mainly due to the red filter which makes red stars brighter then white and blue stars. Also the exposure of 6 seconds is a little short.
What I suggest is:
1) Open ASTAP and activate the option slow. Click once on the solve button to save the setting. The setting will stay in the ASTAP settings. See attached.
2) Expose 20 seconds rather then 6 seconds. You could later try to reduce it.
3) If possible try to solve images with no filter or better luminance.
Tell me if this works for you.
Cheers, Han
The header says L for luminance. The filename says "rot" which is likely rotation and not the German for red. So I assume the filter was luminance. Then just activate slow and expose longer.
Han
Thank you for the quick reply Han. Yes this was with a Lum filter. I will try longer exposures tonight once the sun is down but one question I have is that this exposure length has generally worked fine for me on this setup. Both files also solve instantly when some of my friends have tried to solve them on past versions of ASTAP (various 2024 versions) on their setup, with D80 and even D50 databases. I see plenty of stars detected when I hit F4 on both of these images - certainly more than the 30 required.
I am trying to solve using the same test image I uploaded before, using the slow option, and one thing I notice is that ASTAP is showing that it's binning it to 2. I don't believe I have that binning option enabled anywhere. Is that normal? Could it be part of the issue?
Hi Jeff,
Oops, I think your correct. Is seems to perform poorer compared with older versions. I have to fix this....
You could download an older version. E.g for Windows:
https://sourceforge.net/projects/astap-program/files/windows_installer/older%20versions/
Binning is default in auto=0. For your image ASTAP decides to bin 2x2.
Work to do.
This happened for versions after 2024-02-03. The solver has been fine tuned several times. First impression is that it only effects your (type?) images for some unknown reason. I have to investigate what the cause is.
This Windows version should work fine for you:
https://sourceforge.net/projects/astap-program/files/windows_installer/older%20versions/astap_setup%20v2024-1-12.exe/download
Han
Thanks Han. On the Bin thing - when you say ASTAP decides to bin 2x2 despite my having downsample set to 0, and NINA set to bin 1, are you saying that's normal or a bug of some sort? I'll use the 2024-2-3 version for now until I hear back. Thank you!
Binning is controlled via Nina. 0 is automatic, 1 will force no binning so 1x1, 2 will force 2x2.
I have analysed the problem. At this moment I assume this is a one time only problem. The change I made on 2024-02-07 was that after the first lock on the stars it does a second solve with a larger field. This to achieve a higher accuracy and because it searches in squares and most sensors are rectangle. For your square image it would require a field of 1.41 times the height to cover the whole image field under an angle of 45 degrees. You image is just near a star poor area where there is an unbalance in star density. See screenshot. That resulted in a poor or no lock.
Maybe it can be improved by a better processing of the database but that is far in the future.
The older H18 works better for your image. This one is sorted on magnitude and not on star density. If it happens again can you share the failed image? More images could help to tackle the problem in future. You could also consider to use the H18 database but then any possible problem will stay hidden. I will keep your image in my collection for any future testing.
Cheers, Han
An other experiment would be to expose longer. That would help as well. 6 seconds is short for your field of view.
Thanks for all the support Han. I will try tonight with the older version of ASTAP from early 2024, I will up the exposure duration to 10 seconds, and for now I will keep the D80 star database unless I run into this issue a lot more. I have attached some files that were from NINA's failed solver folder, from last night.
Is there any decrease in accuracy with the H18 DB vs the D80 DB? Asking because I use ASTAP to plate solve when building models for my mount with absolute encoders, so I want good accuracy. I'm assuming the answer is no but just want to be sure. Thanks again!
Tested again tonight under the stars and it still isn't working. I am using up to 30 second long exposures at gain 300. I am using the 2024.1.12 version of ASTAP with the H18 star database. I have the Slow option checked.
When I tried to solve through NINA, the first solve worked, then zero solves after that would work in NINA. All failed.
When I take a fits file out of NINA's failed solves folder, load it into ASTAP manually, ASTAP solves it just fine. When I take a photo in NINA and save it, then load it into ASTAP manually, ASTAP solves it just fine.
There appears to be something going on with the command line params NINA sends to ASTAP, and how they possibly overwrite what's in the FITS header of the image itself. What is odd and I can't explain is that NINA appears to be sometimes sending coordinate hints and sometimes not sending coordinate hints. But it doesnt' really matter because the solve always fails when executed through NINA either way.
Someone informed me that NINA might send ASTAP more command line params than what shows up in the NINA logs. They mentioned FoV for example. My FoV is correct in NINA - or rather, NINA knows my focal length, the pixel size, and the sensor size, so it knows the right FoV.
Hi Jeff,
**The screenshot explains the problem. In your Nina ASTAP settings the maximum object is set at 75. This should be 500 default. See attached screenshot.
**
This should fix your problem :) I assume you can go to a newer ASTAP without problems. The H18 has the same accuracy but goes to magnitude 18 maximum and will be slower. The D80 can go down to magnitude 21. The D80 is sorted on star density so it goes deeper for star poor areas.
All your images solve fine.
Tell me if this solves all your problems.
From your log screenshot:
The regions =5000 is for platesolve2 and does not effect ASTAP
In the solver\failed directory you can look inside the .ini fails. The .ini records the command line should look like this
PLTSOLVD=F
CMDLINE="C:\astap.fpc\command_line_version\astap_cli.exe" -f "C:\Users\h\AppData\Local\NINA\PlateSolver\jggixqop.ljx.fits" -fov 1.046142 -z 0 -s 500 -r 30 -ra 19.690522 -spd 179.781908
-S 500 will be in your .ini files -S 75
Cheers, Han
Thank you Han, I am not sure when or why I would have changed that value but I will give it an update tonight and see if it fixes it on my end. Thanks again for the support!
I noted that this is likely caused by Nina having the same parameter for Local plate solver (astrometry.net) and ASTAP. If you set maximum object in "Local plate solver"the ASTAP setting for "maximum objects follow." A poor design choice.
Even worse it is also the case for down sample factor. Likely more people have solving problems due to this.
There is no size fits all. I will raise an issue for Nina. So this will result in an improvement :)