last night while switching targets from M57 to the veil, auto centering failed displaying a crazy rotator angle (-497.5 degrees), and the auto-centering process simply stopped, leaving the dialog box open all night. the telescope would have tracked into the pier except that APCC saved my bacon. the -497.5 degree angle does not appear in the log anywhere.
there could be an element of user error here, as i have asked for 1 degree rotator accuracy, and the rotator angle is set to 357.5 degrees in the target UI. it is possible that rotator itself may not be commandable to an accuracy of less than 1 degree. i saw this happen once before, so in an attempt to ameliorate the problem i set the rotator angle in M57 to the same as the veil, hoping that no rotator correction would be necessary. the veil nebula angle of 357.5 was auto-populated from the solution of a prior image and i never thought to sanitize it if that’s indeed necessary.
there seems to be some relationship to the plate solving. for some reason PS2 occasionally fails on the veil field and falls back to local ANSVR. as mentioned the initial centering on M57 uses the same angle and i watched it working - i believe PS2 solved everything in that centering run. however on the veil the backup solver was called at least once.
attached is the log and a screenshot of the centering dialog box as i found it this morning.
I suspect the erroneous position angle reported by the rotator hosed up some part of the software. I can’t provide any insight as to what actually caused that angle to be calculated but it was likely the rotator firmware.
Having used a rotator for more than a year, I can offer some ideas to check. The ASCOM standard says a rotator must send a controlling client its internal (or mechanical) position. It is up to the controlling client to use plate solving (or similar) to determine the actual sky position angle of the camera. Then the client computes an offset between the mechanical angle position of the rotator and the sky position angle of the camera. Once that is done, the client (that is, SGP) can then send accurate move commands to the rotator.
If your rotator is not sending consistent mechanical angle position, then SGP could well end up calculating an invalid position angle. I recommend that once you sync the rotator position in SGP, you should let SGP, and only SGP, move the rotator.
For my rotator, I must always home the rotator on power up to force it to mechanical angle position 0. I then I have to use the rotator’s own software to set the rotator’s sky position angle to also be zero. So while my rotator is sending what it thinks is sky position angle, it is actually sending mechanical angle since I have sync’d the two. A bit of a kludge but it allows SGP to accurately position my camera.
Also, I would expect any computer controlled rotator to be able to accept positioning commands to a 1/10 of a degree or better.
thanks for the reply… well, that’s the thing, i don’t see any evidence of a bad rotator angle in the logs, but then again i have not picked over the log in great detail. in the end i’d expect SGP to be doing modular arithmetic on these angles so an angle delta > 360 (or +/- 180) in the UI seems to be pretty suspicious.
do you think that synchronizing the rotator is necessary? this particular rotator always homes itself on power-on, so it’s starting at the same exact angle every night. initially when i set this system up, i did zero the rotator in SGP but the last time i reinstalled the camera i did not (i have been experimenting with reducer spacing.).
in this case i am using @Andy’s driver for optec rotators. my “1 degree” idea came from the Optec GUI which apparently does not let the user input a non-integer angle in its UI. but that may just be a UI thing.
at any rate, the the optec software is not running (neither the rotator control gui nor the optec ascom driver) and although PhD is also connected to the rotator i assume all it would do is read the value. so SGP is the only entity attempting to move the rotator.
I don’t see anything in the log indicating that the rotator is reporting its position erroneously or inconsistently. Did I miss something?
The Optec Pyxis has a 1-degree step size. ASCOM Rotator devices have a StepSize property indicating the minimum step size, and the ASCOM Driver correctly reports the Step Size as 1.0 degrees. I’m not sure how SGP deals with the minimum step size, that would be a question for Jared or Ken.
andy, do you think it is prudent for me to specify integer angles in SGP? what’s weird is that in the GUI everything looks OK up until the point that it gives the big negative delta.
i think what i am going to do tonight is remove the rotator constraint from the veil target (it usually starts after i go to bed) so that i can watch it center on M57 and make sure everything happened correctly.
I don’t think that would accomplish anything. The plate solving precision is much finer than 1 degree and your rotator moves in 1-degree increments. Say for example you start at sky angle 6.47 degrees, and the rotator position (mechanical) is 0 degrees. If your target angle is 25.0 degrees, SGP will want to move the rotator (25.0 - 6.47) = 18.53 degrees. The rotator will actually move 18 degrees (due to the 1 degree step size), and the new camera angle will be close to 6.47 + 18 = 24.47.
@andy@ken I have some more info on this. it appears that the problem occurs when the main solver falls back to ANSVR during validation. SGP and PS2 are apparently talking about angles relative to sky N but astrometry appears to be talking about angles relative to sky S. the requested angle here is 357.5 degrees; when ANSVR solved the validation field it returned this string:
176.95 + 180 = 356.95, however somehow SGP has computed the rotator error as -497.5 degrees.
hopefully this is something to go on; this bug has hit me twice. it causes the center scope/rotate dialog to hang open forever and in the absence of meridian limits the telescope will just track forever right into the pier if it happens to be on the west side when this happens.
OK… I’m a little late to the party. Here is my take…
There was a bug specific to failover behavior with respect to the validation step. This has been fixed (just tonight). The bug was related to defaulting the angle to -500 before the solve. The first solve fails and the failover accidentally does math with the error value. Also, just FYI, SGPro normalizes all sky angles to “east of north” so we already do modify orientation from Astrometry.NET to conform to this.
I think that the other error where the centering dialog stays up was exacerbated by this behavior but unrelated. I believe it is timing related and has to do with camera state. A fix for this will be out in the 2.5.2 beta as well.
excellent, thanks for looking into that and fixing it! i will look forward to the beta. PS2 seems a little fickle, tonight on the same target it happily solved all of the frames it was asked to. i was lucky that i happened to be watching it the other night when it failed.
