We’ve been sending a scale error of 5% with a known scale for a very long time now. We only send an error of 100% when when the scale is empty. This way, if no scale error is set in ANSVR, SGP can request a truly blind solve. Otherwise there is no chance of the solve ever being blind. This does require that the user removes the scale error from ANSVR though, otherwise that percentage will always win out.
We could change it so that blind is truly blind. The problem is that most folks know their scale or can easily get it and if the scale is known then this speeds up blinds considerably. I guess for Astrometry the scale is the only parameter that is needed so maybe “blind” for astrometry needs to truly mean blind.
But it sounds like the main issue with Andy’s solves has been figured out to be that the scale was bad.
thanks all! Yes my scale was set for the QSI583 while I was using the 532. It didn’t occur to me that I had to change the scale because I was used to Pinpoint which worked with both cameras without changing the scale. It looks like I will have to create separate profiles for the two cameras so that I will solve consistently.
Just a note that may be of help. Following Jared’s comment, I went into ANSVR settings and removed the “5” from the scale error estimate. I then downloaded your original shot again - and was able to solve it - even though you had the incorrect scale on it. In fact - the blind solve actually worked as A BLIND SOLVE. Try it - I am leaving my ansvr config now like this…
That surprises me because on my system I see SGP is now passing “5”, so it should not have mattered that you removed the override of “5” from ansvr.
Maybe we are invoking the blind solve differently and SGP is passing different values in different contexts? The way to tell for sure would be to look at the ansvr log. Look for “scale_err”: you will see both the value passed by SGP and the override (if any.) Would you mind checking you log or posting it? It is in
C:\Users\YOUR_USERNAME\AppData\Local\cygwin_ansvr\var\tmp\platesolve\
It shows blank in the log like this: “using scale error override value percent
[2014-11-20 21:29:51]”
I right click on the image, clicked on “Plate Solve”, blanked all coordinates, scale and angle and clicked on “Blind Solve” button and about 20 seconds later the plate solve was successful. I verified RA/Dec coordinates with Stellarium and they matched.
I stand corrected on my previous comments. It’s been too long since I’ve looked at 2.3. And what also might be confusing things is that Andy is likely using 2.4 as he’s in our closed beta group.
2.3 is currently always sending a 100% error. So if you blank the setting in ANSVR you end up getting a true blind solve no matter what you requested.
2.4 is always sending an error of 5% if the scale is non-zero. However setting the scale as 0 will send the error as 100%.
To be honest, neither of these options is really correct, although the behavior in 2.4 is closer. So for 2.4 I’ll be changing it such that “blind” is truly blind and we will send in an error of 100% even if the scale is known. Non blind will remain as is in 2.4 with an error of 5%. This means that if you want the blind behavior that you’ll need to blank out the value in ANSVR otherwise you will never be able to get a blind solve.
But the above does explain why those of you on 2.3 were able to successfully solve with a blanked value in ANSVR and why it failed for Andy. 2.4 has been in beta too long so changes get blurred occasionally (fairly often).
yup, there it is. That “request_json” message in the log is the message from SGP to ansvr. For me it is “scale_err”:5.0
It just dawned on me that I am using a beta version of SGP so that is probably why it is working differently for me. I’ll post a note on the beta-tester thread in case Ken and Jared are not following this thread.
Again following up on what Jared explained…have I got this right?
We are in the future - using 2,4. I have blanked out the scale error estimate in ANSVR.
Again I try to solve Andy’s image with the incorrect scale. I hit the solve button…(In my case anyway) Elbrus has a go and fails over to the local astrometry.net. Because the image scale has a value (albeit the wrong value), SGP calls for a solve with an error estimate of 5%. As we have seen with this image - it will fail. In such circumstances I now hit ‘Blind Solve’ and because of my setting in ANSVR , I will indeed get a blind solve - and most like actually get the image solved.
Most of the time I will not need to hit blind solve (not often the scale would be out more than 5%) - but it is there if I want it.
If I have it right and that is how it will work…sounds good to me.
OK here is another image that I am having trouble with. I believe the pixel scale is set correctly. It solves in 10 seconds using the online server but I can’t get the local server to solve. Pinpoint solves it in abut 10 seconds but I would really love to use Astrometry.net and blind solve to sync the scope.
Anyone want to try? Dropbox - Error
I have the timeout set at 360 seconds and the solver just times out every time.
I would love any help!
It will work - guess it needs a little persuasion. From one of my posts above - I had the local astrometry net error estimate left blank and now I have put 5% back in …and it solved as per the screenshot.
Just a note re the solve with Elbrus…in case some tried it and it would not work. For me, I had to uncheck the ‘auto’ for the threshold and set it at 0.009. Then it solved the image with 34 sides in a couple of seconds at most.
I am not sure what this means. The first image solved with “blank” Scale error estimate and the second image solved with 5%. Can anyone explain? Does this mean we may have to tweak this settings for different images to solve locally?
The first image the scale provided in the FITs header was more than 5% off…which is why having it set at 5% didn’t work. You could have likely upped this value to get it to solve. But blanking the value effectively sends a true blind solve (for 2.3). So this is why the first image worked.
The second image likely has the correct scale (or within 5% of it).
And no, you shouldn’t need different settings provided the scale in the image you’re attempting to solve is correct. This is the issue with setting the override in ANSVR is that it is now global and SGP has no ability to change it…which is why the recommendation for 2.4 will be to leave this blank. Currently (in 2.3) if you leave it blank SGP will send the image in with a 100% error which will get you a blind solve no matter what…which isn’t great for performance and thus the ability to override this behavior.