No problems before the rotator, but can’t get running with it. It connects, is recognized and SGP will rotate it, but platesolves (PS2 and standalone ANSVR blind solver) don’t work, and the sequence aborts. Any idea what the problem is? I tried in both 2.5.2.5 and 2.6.0.17. Pretty much the same. Slews, rotates, but almost never solves. Logs from both are below.
Kevin
If you take an image and solve it yourself via nova.astrometry.net file upload, does it solve correctly?
Yes. The image itself is fine - the slew was perfectly on target (M53) but it almost never solves in SGP. When Platesolve 2 fails, it says it’s going blind solve, but it immediately says the blind solve failed. So I’m guessing it didn’t try. Anyway, PS2 should have worked, without blind solving. So I think something is going wrong with cueing somewhere. No idea what, though.
Is your image scale set correctly in your equipment profile?
Control Panel>Camera>Settings and Specs>Scale shows 0.59 arcsecs/pixel, which is correct. Tools>Equipment Profile Manager>-10C (my current equipment profile)>Camera>Settings and Specs>Scale also shows a scale of 0.59. Does that all sound correct?
It is certainly possible that I do not understand exactly what you are seeing, but I am unsure why the introduction of a rotator would have any effect, at all, on your ability to solve the camera.
Two things:
I don’t know if this matters but does the camera angle in the control panel match the angle you are aiming for?
PS2 goes through 3000 regions, then stops and the failover takes over. That immediately reports a failure - it doesn’t even do a search. I’ll check my settings again, but the fact that both fail - and that both have worked fine for a couple years, right up until the rotator and its software went into the system - makes me suspect the problem is communication-related.
I’m stumped. Tonight the problem seems almost completely different. It solved with no problem at half a dozen different rotations, but each time SGP nudged the rotator, it reported a rotation wildly different from what it wanted. It seemed the positions were almost random. Then the sequence recovery took over, and when I told it to try again, the solve failed. I tried it again a few minutes later, and had exactly the same result - a few successful solves accomapnied by seemingly random rotations, then it failed to solve. Here’s a screen grab, if it helps:
The log is here:
Ack! Help! 
Hi Astrovienna,
Your issue sounds exactly like the issue i had when I first stared using the Optec Pyxis Rotator. It’s been over a year and I can’t exactly remember but I had the reverse direction checked. I believe it was not in SGP but in the Optec Pyxis ASCOM driver configuration files. I’m not at my observatory computer so I can’t tell you exactly but you DO NOT want any reverse direction checked in either SGP or Pyxis ASCOM for the rotator. Once I fixed that in my setup I’ve never had any other issues with the rotator.
Regards,
Mark
Thanks for that tip, Mark. I checked the Optec user interface software, and found that reverse was set to true. Maybe that’s the default. I changed it to false. If I understand correctly, settings here are applied to the ASCOM driver, but if that’s wrong, please let me know. I connect the rotator to PHD2 and SGP, and no reverse options are enabled there. I’ll see if that solves the problem. Kevin
The Hole in the Trees Skybox: The Hole in the Trees Skybox's Photo Galleries at pbase.com
Hi Kevin,
VERY NICE /Images. I’m very impressed. I sent your skybox link home as a keeper. Once you get the rotator working you will wonder how you ever go by without it. It is a very nice accessory to have. I use SGP Framing and Mosaic Wizard (FMW) all the time for framing my Shots. The FMW to frame the image and the rotator work great together.
Mark
Thanks Mark. Yeah, I’m really looking forward to having it up and running. Because of the trees at my site, I can only get 3-4 hours on any given target, so I tend to do 3-5 a night. Without a rotator, my OAG has the same angle to the main cam all night long, so I’m limited to targets that just happen to have suitable guide stars at that position. On the bright side, it’s driven me to image some very offbeat but cool targets!
Kevin
Well, it’s sort of working . . . Tonight PS2 failed on the first platesolve. Then I disconnected the rotator, and set it to No Rotator. Then I platesolved THE SAME IMAGE - ie, no new picture taken - in PS2, and it solved right away. What gives? Then I reconnected the rotator and resumed the sequence. PS2 platesolve failed as usual, but this time the blind solve worked, and it slewed to target . PS2 failed again, but the blind solve worked. So now it’s imaging. This doesn’t seem like a very reliable path forward, though.
Kevin
Bottom line: Platesolve2 will not work when the rotator is connected. I have no idea why. But the blind solve failover (local ANSVR) works. The thing I changed between my initial post (when nothing was working) and now is to switch Reverse from True to False in the rotator driver. Presumably PS2 is getting some bad cue from somewhere that prevents it from solving, but I have no idea what it is. Last night’s log is here:
It slewed to two targets, M53 and M12, during the night, and PS2 failed both times, but blind solving worked. Would love to hear any ideas to get PS2 working!
Kevin
Kevin,
Since Platesolve2 fails but ANSVR works it sounds like it’s an image scale setting issue. I looked in the log and I did see two images scales one was 1.17669 and the other was 0.58901. Someone more knowledgeable will need to take a look but it seems to me that it might be something with the image scale. Also, one more though, what about your search regions? wondering if that is set correctly? I typically have it set to 500.
Mark
I have been using my Optec rotator for more than a year without any problems and I find it hard to imagine anyway the rotator could cause a plate solve failure.
First, the “Reverse” option must be correctly set as it tells the rotator which way to move when SGP sends a move command. With the option set to false, the rotator moves in the direction SGP expects it to move.
PlateSolve2 works quite well but does need a pretty accurate hint in RA and DEC and plate scale – and a reasonable focus. If any of these are off by a significant amount ( 10 arcminutes ), the solve will likely fail.
First check that your pixel scale (in control panel / camera) is accurate. Then you need to make sure your scope’s position and your rotator’s position are accurately sync’d.
At start-up, manually slew the scope to somewhere near the zenith, get a decent focus. Use the “Solve and Sync” procedure to do a plate solve, which will automatically update the RA, DEC of the scope and sky position angle of the rotator. This initial Solve and Sync may very well fail with PlateSolve2 and I don’t think there is an automatic fail over to Astrometry.net (or ANSVR). This will require you to repeat the Solve and Sync with the blind option.
After this, if your scope is well polar aligned and OTA is reasonably orthogonal, PlateSolve2 should work the rest of the night. However, there are times when PlateSolve2 may still fail (should be rare), so a fail over to Astromentry.net (or ANSVR) will occur.
Charlie
I still cant think of a reason the rotator would affect solves (doesn’t mean I’m right… just that I can’t think of one). What would be helpful is if you were able to to perform a successful solve sans rotator and then connect to the rotator and solve again. Use the same plate solve method for both… meaning don’t solve and sync one and then right click to plate solve the other. For each solve, I am interested in the section of the logs that looks like this:
[04/12/17 22:10:24.226][DEBUG] [Image Plate Solve Thread] PlateSove2 Param: RA (HRS) - 10.3614916666667
[04/12/17 22:10:24.226][DEBUG] [Image Plate Solve Thread] PlateSove2 Param: RA (RAD) - 2.71263217501932
[04/12/17 22:10:24.226][DEBUG] [Image Plate Solve Thread] PlateSove2 Param: DEC (DEG) - 0.858352777777778
[04/12/17 22:10:24.226][DEBUG] [Image Plate Solve Thread] PlateSove2 Param: DEC (RAD) - 0.0149810821158614
[04/12/17 22:10:24.227][DEBUG] [Image Plate Solve Thread] PlateSove2 Param: SCALE - 0.58867
[04/12/17 22:10:24.227][DEBUG] [Image Plate Solve Thread] PlateSove2 Param: Width - 2750
[04/12/17 22:10:24.227][DEBUG] [Image Plate Solve Thread] PlateSove2 Param: Height - 2200
[04/12/17 22:10:24.227][DEBUG] [Image Plate Solve Thread] PlateSove2 Param: Regions - 3000
It would be telling if something like scale suddenly changes without you really doing anything to change it.
Thanks for helping out, Mark, Chas and Ken. Tonight I followed Ken’s test plan. I started with the rotator disconnected, took an image, right clicked on it and solved with PS2. Worked fine. Then connected the rotator, right clicked, and it solved again with PS2. All good. Then started the sequence. It slewed to the target, then failed in PS2. It failed over to local ANSVR and then solved. With the ANSVR solve done, it solved in PS2 as well. Checking the log, I see that the scale did not change for the first three solves - steady at 0.5894. Then it starts shifting very slightly: 0.5871. 0.5875, etc. Does that clear up anything? Log is here:
Kevin