It’s supported for sure. It’s required by the ascom driver to be supported.
This is my perspective, but there is also the possibility that I don’t understand something. It is also possible that the solver has somehow miscalculated the angle during the solve. It may be an interesting exercise to use PlaneWave’s PlateSolve2 and see if you get the same results.
No, sorry. This is a fairly time consuming operation that we’d prefer not to implement or support because it shouldn’t be required.
If I remember correctly, RC scopes also produce an “upside down” image like a refractor so there should be no consequential differences here.
I am curious if both solvers produce the same target angles though…
I am also using ASTAP in NINA. In any case, I’ve used platesolve2 today and for some reason, SGP is never waiting for the rotator to finish rotating, that weird behavior is back. After some retries, I restarted SGP but had the same issue. Started NINA, everything is working fine.
If it has the same issues then I am unsure and PL may need to be involved to determine why it happens. From our perspective, I am not sure what else to do. We have traced the process and we are at the point where the rotator, for an absolute movement request seems to be rotating counterclockwise, despite its reading indicating it rotated clockwise.
This is either an issue with the solve angle or the rotator, but since you were able to reproduce the same behavior with a different solver, it seems like the rotator is more likely.
I would consider the “move absolute” command to be the best command to use since this allows the rotator to avoid cord wrap – assuming your rotator has that option. If the imaging software just kept issuing move +20 degrees, the rotator could move past 360 degrees of rotation snagging or breaking the cables.
When a move absolute command of move to 20 degrees is issued, the rotator is free to do something like move +20 degrees or -340 degrees as needed to avoid cord wrap.
Something isn’t working properly between ARCO and SGP. I sent everything I have from logs and observations, as well as yours, and a link to this forum to PLL. But they rarely reply. I even offered them an SGP license to do the test (not that they cannot afford it). I am not sure if you have a direct contact with them to sort this out?
If PLL or you come up with a new test that is needed, or something to verify, then I will happily do my part.
Maybe it is the best command to use, but that’s for PLL to worry about.
What I care about is having my rotator work, and for the moment, that’s only working with NINA. I am not saying SGP is broken, this may be well an issue with PLL’s driver. But I can’t even start to bridge the gap between the two, I am not a developer, nor an expert on ASCOM drivers.
NINA actually has a smart way of dealing with this. You can set a starting mechanical position, then set a +90 or +180 degrees limit. That’s very useful for cable management. I rotate to the angle where my filter wheel hit the cables (cam/efw/power from asi to ppb on top of the ota), I set that position as starting position, and set the range to +180 degree.
Just an update, I finally got a beta firmware and ascom driver from PLL and tested it with the latest SGP (stable). The behavior is the same unless the reverse direction is enabled. They added this option in their ascom driver settings. It’s weird that this is needed for SGP and not NINA, but I guess this has to do with the move commands in ascom.
In any case, there’s a solution now, time to go back to SGP finally
As far as the “reverse direction” option – ASCOM has a definition for rotators that says the rotator’s mechanical angle must increase when the resulting sky position angle decreases (or similar). If the firmware of the rotator wasn’t doing that, then the ASCOM option of “reverse direction” is needed to make the rotator compliant with ASCOM standards.
