New KStars (version 3.6.5 ) will carry a lot of changes and improvements. One of them is the overhaul of 'Rotator Settings" (or better 'Rotator Control'). The rotational position of the camera is now called 'Camera Position Angle' in the style of the original meaning of the position angle of a star and describes the angle of the camera upright direction respective to North Celestial Pole (International Astronomical Union [IAU]). This is often called - somewhat unclear - "East of North". A more explicit definition would be "... measured relativ to the North Celestial Pole, turning positive into the direction of the Right Ascension" (Wikipedia).

With the new rotator control the user now only sets the desired camera position angle and the other angles are calculated depending of the pierside. The rotator gauge displays the actual camera position angle (yellow) and the raw rotator angle (gray). Both are represented in viewing direction. Each time a [Capture & Solve] or a [Load & Slew] in the Align module is brought into action the 'Camera Offset Angle' is recalibrated. The raw rotation angle is then calculated from the solved Camera Position Angle and the Cameras Offset Angle.

Apart from these changes in the user interface, the whole internal process was rewritten and based on a new logic. The new Rotator Control implements a throughout "flipped position angle" policy, allowing to preprocess all produced images with the same bias, dark and flat. So after a mount flip, the rotator angle and camera offset angle now remain the same: Only the point of reference for the rotator angle changes (e.g. from North to South if the mount flips from West to East). Thus the camera upright direction flips or rotates by 180° when the mount flips, as seen in the illustrations, leading to a new "flipped position angle" of the camera frame.



In this default mode a [Load & Slew] now checks the pierside information of the reference image and the actual mount pierside when the target is reached. If the two sides differ the rotator moves the camera into "flipped" state too. Please note, that this feature only works if the loaded image is in FITS format and has the pierside information.
You can always override this policy by checking "Save Camera Position Angle to Sequence Job". In this case any subsequent jobs added to the sequence queue would always rotate the camera to the saved position angle before capture begins.

If you're interested in testing, you can download INDI Nightly Build (3.6.5 beta) or compile the upstream master code yourself. Any feedback is welcome and helps fixing issues before KStars 3.6.5 stable is released. Especially experiences of users living in the south hemisphere are highly appreciated.
Remember that INDI Nightly Build is *beta* and the changes are quite extensive. So make sure you can revert to your standard (stable) version in case of issues.

I tested it of course in the observatory and it's running great. There is one thing is irks me which is not new, it's the "Save Camera PA to Job" checkbox. Does this checkbox feel natural? Should we maybe remove it and assume it by default? Maybe we can add a small PA double spinbox in capture settings that would always have the same PA value as the rotator. The user can still override this, but it is synced with the rotator.

Thank you for the feedback.

Regarding the "Save Camera PA to Job" checkbox, I think it does indeed make sense, even though it is not obvious at first sight.

• The default behaviour pattern of the align process is to load a reference image, find the position/rotation via plate solving and thereafter to adjust the telescope and imaging train accordingly. As I wrote above this process works by default under the "flipped position angle" policy: That means the camera PA is set once in the align process and will not change afterwards except if the pierside changes. (The cameras PA is set "flipped" or "not flipped" depending of a comparison of the reference pierside and the actual pierside.)
• However, with the "Save Camera PA to Job" checkbox set, the rotator is activated ahead of each job and moves the camera to the saved PA. On the one hand this allows to rotate the camera PA for each job independently. On the other hand this mode also rotates the camera from "flipped" state back to the saved PA after a mount flip.

These are indeed two different policies! Perhaps the logic behind and the naming of the checkbox are not (yet) optimal, but I did not find a better designation.

Hi there;

I just updated my distro and kstars to 3.6.7. Lots of changes and improvements; thanks guys! thanks Toni!

One of the features I want to try is the new rotator control. Looks interesting and wishing to test the new flip policy. I have to say, to be honest, that first time I opened the tool, got quite confused. I was used to use the former interface and control the raw angle rotator and/or position angle. Now I can set camera's position angle, which is indeed a good idea. However I'm still missing the possibility of control the raw angle rotator. I can do it obviously from the indi panel, which is not a bit deal. However I wonder if is possible to enable the actually "Rotator angle" grayed-out box. I don't know if it makes some sense or even I'm the only one who misses this feature

just an idea

miguel

Hola Miguel

The new rotator control window was meant to have an easy and meaningful design. Thus only the position angle (and now the flip policy) remain relevant in the end. This is indeed the only angle that makes sense and corresponds to the one displayed in the planetary sky (see FOV). The raw rotator angle is somewhat arbitrary as it depends on the the camera offset and on the flip status. Of course it is coupled to the position angle and follows that more or less, but not in straight way. In other words setting the raw rotator angle means you have to do a quite cumbersome calculation to the resulting position angle by yourself (including the actual flip state!) and I think that's not very user friendly. (Depending on the parameters the PA sometimes turns even opposite to the raw rotator angle.)

I think it's a matter of practice and one soon gets accustomed to the new control.

NB: There is one situation which it is necessary to adjust the zero point of the raw rotator angle. That is, if you want to set the reversal point of the rotator in order to prevent a cable tangle. But this is done only once and readily done in the indi control panel.

Hi Toni,

Thanks for your kind reply and effort.

Yes, probably it's a matter of practice. I will get accustomed

I would like however explain a bit further my "issue". As you may know, rotators are prone to procude some tilting depending on the rotation angle. I know quite well mine and where can produce a bit of tilt. Not a big deal; first cause is not an exaggerated tilt, and second because when I realize that my framing sits on a "dangerous" rotator zone, I simply flip 180d my reference fit (where no tilt occurs) and that's all.
The problem is that usually my reference frame is taken pointing the scope to the east (west pier side) but some nights, depending on that particular schedule, I may start to image that object after the meridian flip. When ekos loads the same reference frame it will rotate the camera 180d compared the "original" rotation where the scope captured the original reference frame, and that position may produce tilt. So here my option is to deal with two reference frames: one rotated 180d with respect to the other.

I have to try, but probably the new flip policy would solve the problem, but that would mean that the camera will rotate always after a slew crossing the meridian; which is an operation I repeat quite a lot (for framing, testing, etc) and it's not the behaviour I wish.

Hope I've explained correclty. Sorry if not.

m

When ekos loads the same reference frame it will rotate the camera 180d compared the "original" rotation where the scope captured the original reference frame

With KStars 3.6.7 you can use now option "Preserve Rotator Angle" in flip policy. This keeps the raw rotator angle after a flip and thus will inhibit the rotator to move into the "dangerous" zone. (see here )

That's what I tested last night Toni. That's the policy I set expecting to behave as that. But it didn't. I waited for an object to cross the meridian and then performed a load and slew. The rotator rotated 180d.
Am I missing something?

I did run some tests which all end successful, but I'll run some more!

I can imagine the following situation, where the rotator behaves like your wrote: (I'm sorry, it's a really awkward! )
Let's assume a reference image taken on pierside East. Let's assume also you are on pierside West working with a handmade 180° rotation and the mount crosses the meridian, then the rotator turns 180° to the original rotator angle when invoking a [Load & Slew] based on the the mentioned reference image.

Toni, the PIERSIDE fits header needs to be present in the file, right? Cause I've just noted that the image I used has not such header. I will try again tonight

...the PIERSIDE fits header needs to be present in the file...

Exactly! PIERSIDE must be present in the fits header. Even KStars added this feature only around two years ago.

Toni, I did some tests last night and worked perfectly
This has been a major improvement for me. Thanks for your time and support!

m