Error alert, solve coordinates deviate too far from current position


#1

Hi guys,
Last night I received an error alert I’ve never seen before when the sequence attempted to move from one target (IC1848) to the next target (Horsehead): “Solve might be bad (auto center)! New solve coordinates deviate too far from current position…” (1:14:36).

I was presented with an option to either continue the sequence despite the bad solve, or to abort. I’m pretty sure that I chose to abort, and then the recovery window appeared. The log shows at 1:18:10 “User chose to continue sequence, despite possible bad solve…” I was pretty sleepy, but I thought I had chosen to abort intead of continue.

The recovery window popped up and I manually ran recovery and this time the solve was good and the sequence continued the rest of the night without problems.

LOG FILE


#2

We are indeed logging the opposite of what happened (in the original implementation, the check box meant the opposite of what it does now, but we never changed the message). The log message has been updated. The code should be still be functioning as intended.


#3

What does this mean? Was this just a fluke or should I be wary when running the same sequence?


#4

It means that the derived solve was not close to the hints you passed in. This can be quite dangerous for subsequent slews.


#5

Well I’m not sure what could have changed. I’ve used this same sequence over several nights and this only happened once. Guess I’ll take my chances.


#6

Was it you first solve of the night? Sorry, I haven’t looked through your logs… just wondering if our tolerances for error are too tight? Like your solver actually got it right given a fairly imprecise hint.


#7

No, this was the third target in the sequence. I did have some issues with PS2 not solving prior to the first target, but the solves worked fine after that. The targets were NGC281, IC1846, B33 (Horsehead). The problem solve was going from IC1848 to B33.


#8

I had this pop up on me the last couple of nights after long slews to targets with meridian flips. For some reason my pointing is a bit off after a flip (I have to investigate that…just did a drift align the last full moon) and I lost about 1 1/2 nights imaging on a target as I was asleep when it occurred.

Last night I noticed it and accepted the solved position and the sequence continued centering on the target on the next slew. From the log I was about 3.5 degrees off from the target (need to check the hint position, but I monitor the location with the Sky and it didn’t jump much), so what is the maximum error allowed before this comes up? Previously, I’ve had errors as large as 15 degrees after flips that synched properly and continued to work properly the rest of the night (when I removed the ladder…long story), so when was this installed?

Since it default is rejection, your imaging is done for the night unless you are there to correct it. For safety reasons this makes sense, but in my case, all was OK when if took the position and continued the sequence. Can this be disabled or the limits widened (user defined)? One option for safety would be to accept it by default, move the scope a degree or so and do another plate solve. If that is correct, you’re OK, else you’re lost and abort. This would give us a little flexibility since we know our equipment over losing what seems to be a somewhat scarce night of imaging.

Thanks,

Frank Z…


#9

Currently, SGPro considers a solve as “bad” if it is not within 5 degrees (±) of the either the RA or DEC hint.


#10

I’be had this happen a couple of times lately and it worked - both times - when I hit continue. This never used to happen. Did u change the definition of bad? Like Frank I’m worried about losing a rare night. What about defaulting to blind solve if the hints are more than 5 degrees off?


#11

This has to be a recent addition. Last year I imaged LBN576 and for some reason, when the mount slewed to it, the mount would report a position about 12 hours away in RA. Of course, the solve would fail, but the blind solve always locked it in and I was able to image it unattended. I could not do this with the current release and this error check. An option to disable, default to accept or use a blind solve under this condition would be fine. In my case, I have never had a solve throw me of course It would work and give me a good position or fail.

Frank Z…


#12

Not, it has always been 5 degrees. This safety has existed for about 6 months now.

This already happens.


#13

Ken,

If it is too far off with the default plate solver, then it goes to Astrometry.net blind solve? I checked my logs and it did use the blind solve, it was successful but still gave the error that it was too far from the hint position. From the previous post, it looks like it should of used the blind solve to synch and continue, Mine did not work that way.

Thanks,
Frank Z…


#14

It is supposed to if you if you have this option checked, otherwise it is supposed to abort the sequence.

Can I see them?


#15

Ken,

Here is the log from the night in question. The first occurred around 07:37 when the blind solve returned a position that triggered the too far off and at 7:47 triggered the recovery mode because I wasn’t up to accept it. The other around 10:04 after a meridian flip and blind solve and continued to around 11:30 when I intervened.

Log File 12518

Thanks,

Frank Z…


#16

Ya… there is a problem here. Specifically, we are checking the accuracy of a blind solve. I am not sure why we would do this… it defeats the purpose of one since a true blind solve takes no hints. I think all I need to do is remove these checks from the blind solve failover and it should stop failing in this (circular) way.


#17

Yikes, please don’t remove the safety check (if I understand correctly that is what you are suggesting)! The problem I had was that a blind solve gave an incorrect solution and synced the mount to an incorrect position, causing the subsequent slew to target to crash the pier. Even a blind solve in the middle of a sequence should be close to where the mount thinks it is pointing. The situation for me was that the solve-and-sync meridian flip image was clouded over, the normal solve failed and went to blind failover, then the blind solve “succeeded” and produced the bad coordinates.

If I might make a suggestion, I think it would be ok to loosen the 5 degree threshold, to say, 10 degrees or more as long as you also added a sanity check on the solved image scale. A truly bad solve (like the one I experienced) had both a bogus location (off by way more than 5 degrees), but also a very bogus image scale, very different from my true image scale.

Andy


#18

OK. That makes sense.

That’s because it was… seems we might be a bit too restrictive… As @Andy suggested, I will open the location hint to a full 20 degrees (± 10), but only because we are now checking that the solved scale is within 25% of "hint"scale (this is what Pinpoint claims is its max scale error… so I thought it seemed a reasonable place to start).

I’m juggling a lot of things right now (in and out of SGPro), so please let me know if this seems reasonable or if you spot any issues with this implementation.


#19

Ken,

I think I could live with the +/- 10 degrees for my current issues, but as long as the returned image scale is what is expected, then maybe it could be wider as the scale should be within a couple of percent for a good fit. I don’t intend to image LBN 576 again for a while, but if I do, I’ll have to come up with a way to point to it…

Thanks,

Frank Z…


#20

Thanks, Ken, that sounds great.

Andy


www.mainsequencesoftware.com