I dunno why, but whatever you added to ‘double check’ my plate solving has broke SGP plate solving. I haven’t figured out why I couldn’t center over the past few nights. Well, when I try to plate solve using PS2 and it fails to blind failover, I get your error telling me my plate solve might be bad… but it’s not. And this causes the sequence to fail.
Logs attached. Please turn that off!
Chris
PS2 works perfectly fine for me with 2.5.2.5.
The problem is when it goes to failover it for whatever reason reports ‘might be a bad solve, fix it’. It’s not a bad solve, and it ruins the rest of the night.
Skipping PS2 fixes it. I don’t know what causes the check, so I can’t insinuate why it’s failing. I’ve never had a bad solve so I don’t know why this ‘feature’ was added.
Um… no. 
We have not changed plate solve validation for a long time and it is an important safety feature.
I don’t really have enough context to speak directly to your issue, but the hint data you passed to the solver was simply too far away from the actual solve and, because of this, was considered suspect.
Hint
RA: 0.71 hrs; DEC: 41.32 deg
Solve:
RA: 23.14 hrs; 41.31 deg
That is a pretty significant difference in RA (1.5 hrs)…
There may be a better way to do this, but turning off the validation is likely not a viable option. This check has been around for more than a year and has protected against many gear damaging slews. If it’s suddenly affecting you it points to change in other areas. One question to ask is why does your mount think it’s pointed more than 1.5 hrs away from it’s actual position when the centering process begins?
Is this a sign or wrapping issue somewhere. 23.3 is 0.7 from 24.
Frank
Chris,
I had the exact same issue two days ago with two of my Gemini based mounts. Just as Ken pointed out the coordinates SGP was getting back from Gemini.NET were bonkers compared to where the mount was really pointing. Not only that but sometimes when I slewed to a target (via SGP or Gemini.NET) it was way off.
Here I discovered the CMOS batteries needed replaced. What tipped me off was when I went into the Avanced Gemini Settings window and vewed the model parameters there were crazy values in some of the parameters like -32345 and such. They should all be 0 (no model).
I was disappointed as I replaced the CMOS batteries only 5-6 months ago. 
We seem to get obscure issues like this at about this time of year every year and I get the impression that they could be down to problems with the arithmetic and logic around the 0/24 or 0/360 rotation angles. This is the time of year when that’s passing through the meridian in the evening.
Saying that things haven’t changed for many months isn’t an answer for problems that only happen at one time of year.
Chris
True, but this is an answer to the implication that 2.5.2.5 introduced the issue.
While I realize the location’s proximity to 0 hrs automatically causes some suspicion, in this case I am not sure I understand why folks seem to be fixated on it. The math, in this case does not even need to consider RA “wrapping”. The bottom line is this:
Now… what I am not saying is that this is best way to handle this (certainly open to discussion…). I am saying that this is functioning as intended and that @mads0100 should look at why the hint to the solver is 1.5 hrs (22.5 deg) from the actual location at the start of the centering operation (before any mount movement occurs).
The dec. value appears correct - and if the RA value of 0.71 is in fact a bad wrap of the value 23.29, then the actual offset is only 0.15 hours off at a declination of 42 degrees - which would have been an ok “hint.”
I’m not saying sgp did an error in the wrapping. I’m just saying that since people are wondering why the hint was 1.5 hours off - one explanation is that there was a bad wrap somewhere in the pipeline and the true hint should have been 23.29 - but it conflated with a bad wrap at 0 to become 0.71
Frank
ah, ok, I see what you are saying.