I recently updated my observatory PC with the most recent version of ASTAP and the updated “h” series catalogues. It appears this new version has broken SGPro’s plate solving. This image:
Check the below thread. Somewhere during 2022 ASTAP started providing a negative angle, which I think is the issue. I haven’t seen anything from the ASTAP author (@han) yet though.
Does this have to do with settings or information that SGP sends to ASTAP that would have to be changed on your end? Or is this something on the user’s end? For now I’ve just gone back to using PlateSolve2.
Everyone must be using old versions of ASTAP… This is a big problem.
NINA has fixed this in their software but you have to use Their framing wizard for rotation angle.
Previously the angle from astrometry matched through all the software now ASTAP has it’s own new angle system which I am sure is right but if all the software doesn’t switch to this it will be inconsistent.
Interesting you brought this up about the new ASTAP. The other night I was trying to image NGC 3180, Little Pinwheel Galaxy, using my Observatory rig. I just recently installed a new PC with the latest software but was having an issue with the rotator and Plate Solver which I never had before. After each plate solve the rotator would rotate as directed by the solve. However, if the ASTAP solved first and for some reason on the next solve it did not and the fall over did the solve, ANSVR, the rotator went in another direction, like opposite direction. after several tries I give up for the night, figured I’ll take a look at the rotator in the morning. The next day I inspected and tested the rotator and didn’t find any issue with the rotator which left me wondering what was happening.
I ran across this and decided to do some testing using the Observatory rig and two of my travel rigs. I loaded an image I had, M74, and preformed plate solving using both the ANSVR and ASTAP. On my two travel rigs they are both running the older ASTAP version while on the Observatory system is running the newer version of ASTAP.
On the travel rigs both the ANSVR and ASTAP angles always agreed. However, on the Observatory rig, running the latest ASTAP version, the ASTAP was always approximately 180 degrees different. I did this on several images and the ASTAP solve was always different by approximately 180 degrees from the ANSVR solves. Sometimes the angle showed a negative value.
This difference between the ANSVR solve and new ASTAP solve might be the reason my rotator was confused. One time ASTAP told the rotator to go to one place then the next solve, if the blind solver kicked in, ANSVR told it to go to the opposite place.
Not sure if this is what is happening, but I’ve been running SGPro for several years using this rotator and never had an issue until the other night while using the new ASTAP version.
Below is the screen shot of the different solves for M74.
Maybe there’s a simple setting I’m missing so both the ASTAP and ANSVR can agree on the same angle.
Thanks Yep, I brought it to the attention of the ASTAP creator and he explained the change he made. Now SGP, Voyager, etc have to make the changes to make use of his change. Apparently we have to ask the developers ourselves? I asked Voyager they said talk to ASTAP, they pointed me to voyager… Loops I gave up… Installed Old ASTAP life is good. Goodluck
Reverted ASTAP back to version 9.560 and the plate solves between ASTAP and ANSVR Astrometry net now match. If and when we get a clear night, need to test everything while under the stars. I don’t expect to have any issue since version 9.560 is the version I used in the past.
Unfortunately there’s not as much communication between developers as you would hope for…so this is basically the first we’re hearing of it.
I emailed with him as well. It sounds like the result is only for flipped images but it seems it may be affecting non-flipped as well. I’ll have to do some additional testing.
Has there been any resolution to this that I’ve missed? I had the same error in rotation solving with ASTAP as described above so I’m assuming it’s the same issue. Version 4.2.0.972
