When I fire up SGP I can successfully do a sync with platesolve2… no problem. Yet the minute I start a sequence it won’t successfully plate solve and every time gives me the following screen !
My log is here … Dropbox - File Deleted
I am running ASCOM 6.3 and EQMOD V1.28k.
I have also found that it all works with the Astrometry remote service so I know it’s not a hardware issue or snagged cables etc.
Can anyone please take a look at the log and suggest what on earth is going wrong?
Many thanks 
Hi Sara,
1st question is “Are you sure it is actually doing a Sync” on that 1st solve?
Looks like PS2 had to search quite a way away from where it thought the mount was - that is why it gives the warning (sorry - stating the obvious).
At this stage a blind solve will work as you see - but for some reason PS2 has to keep searching out 518 regions …the mount is not where PS2 expects it to be.
If it is actually doing a sync on that 1st solve…then something might be slipping. Surely not …knowing your attention to detail 
This was a totally new sequence on a new log so that anyone looking wouldn’t get bogged down with too much irrelevant stuff! So in this case I didn’t do a sync, but I’d done many previously!
Also, it won’t work in the local ANSVR but works perfectly in the remote astrometry… I’m as confused as hell. This means that there is no slippage, cable drag or hardware issues as it works perfectly using one of the methods… but why is it not working using the more normal methods?
I am not sure that is true. Doing a plate solve via online ANSVR, it just plate solves what it sees at that moment - regardless of where the mount was pointing before. PS2 as you are aware needs to know pretty closely where it is at, to do the solve. In the example (screen shot) above it was not ‘that’ close and that is why you get the error warning.
What is confusing for me though, is that the online ANSVR plate-solves whereas the local does not. But that might be a different problem altogether (incorrect indices?)
Suggest you point anywhere convenient: plate solve & SYNC with ANSVR remote. Without moving the mount, try a plate solve with PS2. If it has synced from the 1st plate solve, then you should get no error warning when PS2 does it. (If you still get that error warning, then looks like the mount is not being sync’d…but you are pretty sure that is not the case I believe).
If it is the case of no warning, then slew the mount quite a ways across the sky (preferably with a computer command rather than a hand controller) and do a plate solve with PS2 only. If PS2 throws up the warning then, then it is obvious that your mount does not go where PS2 is expecting. That would point to a mechanical issue (I think).
At least it is something to try which might confirm your mount is being a) correctly sync’d and b) is or is not going where your computer program is telling it to go.
Perhaps others will chime in if they have experienced & fixed this. I am just trying to figure a way to narrow down the problem so you can put your finger on what is happening. Good luck! 
Thanks Brendan… last night I DID a sync and solve… perfect. I did a plate solve to my target… perfect. start the sequence and this is where it falls down and won’t centre during a sequence, but outside of that and doing it all individually it works fine 
️
Only other thought then is that it is related to EQMOD problems that you were having previously …which I know nothing about…other than people talking here about which type of sync should be selected!
This hobby is bad enough without these ‘hard to nail down’ problems…hope you sort it soon.
This sometimes happens to me in certain fields of view (25’x25’ FOV). Example, M13 or FOVs with really bright stars (e.g. Vega or some other really bright star for purposes of using a mask for focus). I simply slew to, take some centering frames and manually center the target. Another dodge is to plate solve somewhere near the target, then slew to target and manually center. This works well when the mount has to flip. I note that you target was close to the pole. Could this be a problem? PS2 isn’t magic, sometimes you need to think of inventive ways to solve the problem. Also, the nagging “max region” glitch – if it has not solved in 100-200 tries it probably is not going to solve. Don’t waste time, keep checking that you are not on “max regions” before every plate solve attempt.
This is similar to autofocus, its not magic, sometimes is simply doesn’t work on a particular FOV/scope/default parameters. Parameters need to be tweaked.
Ed
(No expert SGP user, relatively new to the program)
Thanks for your replies Brendan and Ed…@Ed Sadly I don’t think there are any work arounds for a sequence that involves auto meridian flips and target changes…
I don’t buy the sometimes it doesn’t work with certain parameters / kit combo’s as I’ve had this working fine for months.
I guess that no one is seeing anything in the log that provides an answer? I’m not great at reading and understanding these If there was any settings that were wrong these would be jumping out at people who looked at the log I’m guessing?
Hi Sara,
I have had similar issues over the last two nights. I can get it to solved a downloaded sub outside of the sequence but cannot get plate solving to work at all during sequencing, Pinpoint, ANSVR remote or local.
I can solve instantly using Pinpoint in MaximDL. The only change is is to upgrade to V3.0.2.82.
I’m going to revert back to V3.0.2 as I had plate solving working in this version.
Steve
I hate reading the logs too so take this with a grain of salt. In your original log I saw this:
[05/07/18 22:07:03.156][DEBUG] [Telescope Thread] ************* SOLVE HINTS ****************
[05/07/18 22:07:03.156][DEBUG] [Telescope Thread] SOLVER: PlateSolve2
[05/07/18 22:07:03.156][DEBUG] [Telescope Thread] BLIND: False
[05/07/18 22:07:03.156][DEBUG] [Telescope Thread] METHOD: Max Regions
[05/07/18 22:07:03.156][DEBUG] [Telescope Thread] RA: 10.5924532109655
[05/07/18 22:07:03.156][DEBUG] [Telescope Thread] DEC: 73.1885237068965
[05/07/18 22:07:03.156][DEBUG] [Telescope Thread] SCALE: 6.73564
[05/07/18 22:07:03.156][DEBUG] [Telescope Thread] ******************************************
[05/07/18 22:07:03.198][DEBUG] [Telescope Thread] FitsFileHeaderData: Angle - 0
[05/07/18 22:07:03.198][DEBUG] [Telescope Thread] FitsFileHeaderData: Scale - 0
[05/07/18 22:07:03.198][DEBUG] [Telescope Thread] FitsFileHeaderData: RA - 10.5924532422
[05/07/18 22:07:03.199][DEBUG] [Telescope Thread] FitsFileHeaderData: DEC - 73.1885237068965
[05/07/18 22:07:03.205][DEBUG] [Telescope Thread] PlateSove2 Param: RA (RAD) - 2.77309776592191
[05/07/18 22:07:03.205][DEBUG] [Telescope Thread] PlateSove2 Param: DEC (RAD) - 1.27738071335927
[05/07/18 22:07:03.205][DEBUG] [Telescope Thread] PlateSove2 Param: Width - 1663
[05/07/18 22:07:03.205][DEBUG] [Telescope Thread] PlateSove2 Param: Height - 1252
[05/07/18 22:07:03.205][DEBUG] [Telescope Thread] PlateSolve2 Command Line:
[05/07/18 22:07:03.205][DEBUG] [Telescope Thread] C:\Users\PrimaLuceLab\AppData\Local\SequenceGenerator\PlateSolve2.exe 2.77309776592191,1.27738071335927,0.05430577093497,0.04088444089632,3000,C:\Users\PrimaLuceLab\AppData\Local\SequenceGenerator\Temp\psXSolve_0.fit
[05/07/18 22:07:24.491][DEBUG] [PHD2 Listener Thread] Error: Guide star reported as lost!
[05/07/18 22:07:24.491][DEBUG] [PHD2 Listener Thread] Adding sequence level notification: Guide star lost!
[05/07/18 22:07:25.103][DEBUG] [Guider Camera Thread] Frame restart: Guide star was lost.
[05/07/18 22:08:59.806][DEBUG] [PHD2 Listener Thread] Error: Guide star reported as lost!
[05/07/18 22:08:59.806][DEBUG] [PHD2 Listener Thread] Adding sequence level notification: Guide star lost!
[05/07/18 22:09:00.169][DEBUG] [Guider Camera Thread] Frame restart: Guide star was lost.
[05/07/18 22:09:10.336][DEBUG] [Telescope Thread] *********** SUCCESSFUL SOLVE *************
[05/07/18 22:09:10.336][DEBUG] [Telescope Thread] SOLVER: False
[05/07/18 22:09:10.336][DEBUG] [Telescope Thread] SUCCESS: True
[05/07/18 22:09:10.336][DEBUG] [Telescope Thread] CONF: 100
[05/07/18 22:09:10.336][DEBUG] [Telescope Thread] BLIND: False
[05/07/18 22:09:10.336][DEBUG] [Telescope Thread] RA: 9.9527269024747
[05/07/18 22:09:10.336][DEBUG] [Telescope Thread] DEC: 84.628927654322
[05/07/18 22:09:10.336][DEBUG] [Telescope Thread] SCALE: 6.73655
[05/07/18 22:09:10.336][DEBUG] [Telescope Thread] FLIPPED: False
[05/07/18 22:09:10.336][DEBUG] [Telescope Thread] ANGLE (EON): 106.61
[05/07/18 22:09:10.336][DEBUG] [Telescope Thread] MSG: Valid solve.
[05/07/18 22:09:10.336][DEBUG] [Telescope Thread] ******************************************
[05/07/18 22:09:10.340][DEBUG] [Telescope Thread] Checking to see if solve might be bad…
[05/07/18 22:09:10.347][DEBUG] [Telescope Thread] Solve might be bad (auto center)! New solve coordinates deviate too far from current position.
What stands out to me are two things:
The HINT image scale is 6.73564. What binning level are you using, and does that scale seem right? Bin 2 would give a 1x1 image scale of 3.36782. The successful solve shows a very similar image scale so that’s good.
The HINT RA=10.59 and DEC=73.18 are very different than the successful solve shows, which is why you’re getting the “solve might be bad” message. For some reason your initial slew to the target is quite a ways off. In other words, your mount thinks that is is at 10.59/73.18 but it’s not.
To me, that would indicate an issue with the mount. Why isn’t the mount getting closer to the target hint coordinates on the initial slew? I’m sorry I can’t be more help but it actually appears to me that solving is working correctly, it’s just that the mount thinks it’s in a different place than the solve. (Unnecessary comment: I have seen so many issues with EQMOD over the years. People seem to like it but I’ve seen loads of problems with it on this and other forums.)
Complicating matters, it has been my experience that solving around the NCP can be problematic. The successful solve coordinates (9.95/84.62) are rather close to the pole and I’ve had trouble when pointed that close.
Oh, can you post an image for me to try and solve?
Thanks very much for the help Joel - I really appreciate it…
Just one question then… If prior to the sequence start I’ve done a solve and sync so that the scope knows where it is, then why would I still get this issue? That is what happened in the first log, which made me start again with just a sequence to show this issue so that the log wouldn’t get bogged down in unnecessary stuff.
The image to plate solve is at the following link Dropbox - File Deleted
Yeah, that’s what I don’t know either. What I was suggesting is that even if you do a solve and sync so your mount knows where it is, by the time it slews to your target for some reason the mount is not physically pointed at the right spot.
After you slew to the target, are you sure it is pointed at the right spot? The target coordinates and the strange solve coordinates are in the same general area of the sky but significantly different.
When you solve and sync the mount, are you pointing at your target, or at another spot in the sky?
I solved your image and it is at the right target coordinates.
After a sync and solve the mount is pointing to the correct area of the sky as far as I can see… When I solve and sync I just pick a random piece of sky, normally in the east… Should I sync and solve near the target do you think?
Sara
Just a minor point to help: I downloaded the 300s Red sub you placed in your Dropbox and can confirm that it is an image of the target (by comparing it directly with my image of MW2) - so your mount was pointing at the target co-ordinates when you took that sub.
I have read a thread about the potential of the EQ8’s encoders giving incorrect information and should be disabled (was it in this forum or SGL? Can’t recall now, and I’m at work currently) - is this an area of investigation for you?
I’m sure we’ll get to the bottom of this mystery.
The image is in the right place as the only thing that would work during the sequence was the remote solver…not Platesolve2 nor the ANSVR blindsolve failover.
The EQ8 encoders are disabled in EQMOD as I think I’d also read something about the encoders and the syncing software in effect ‘fighting’ over who was right
It certainly couldn’t hurt to try.
Does the EQ8 have a pointing model? With some mounts, like the Losmandy mounts for example, building a pointing model can eventually get corrupted by solve and sync. When I had a Losmandy mount I would always do a cold start (without pointing model) and just let the mount plate solve its way to the target. Otherwise I’d start getting slews that were further and further away from the intended target.
This sure is a mystery.
As far as I now there’s no pointing model with the EQ8… Certainly I’ve never built one and wouldn’t know how to. I hope that I get a little clear tonight to try it again… but sadly I think it will be cloudy
Hi Sara,
I would suggest, let’s make sure there is none.
The pointing model, if any, is a function of EQMOD. To check if there is one, please do the following:
That’s it. The other settings in that group are irrelevant.
Kind regards,
Horia
Just a thought - I noticed that when I updated SGP to the latest beta, my telescope sync method defaulted back to sync. On my Paramount I cannot use sync and have to use target offset. The details are on a different thread and will likely be resolved. In your case, can you check the telescope sync settings are as you expect?
