I believe I found an inconsistency in the application of image rotation and FOV pointers. As I was gathering some information to reply to another topic I attempted to use the CCD simulator with an arbitrary rotation value set in the configuration, plate solve it, take the result and customize an FOV pointer with it. But it did not quite go according to plan.

First off, I set a Rotation (CW) of 23.63° in the simulator configuration. The solver produced a result of -66.39265°.
This is approximately negative 90° off. When configured to 0° the solver reported -90°.
Secondly, Custom FOVs. Using the solved value given (-66.39° E of N) for an FOV pointer symbol results in a box pointing 180° from the solved frame.
But recall, the driver was set to 23.63°, not the given -66.39. And certainly not the flipped FOV of the incorrect solved rotation.
*I have not had an opportunity to check with a real image.

P.S. Wishlist: It would be great if an option could be added to lock an FOV symbol to the rotation value acquired via plate solving, similar to the option to lock the FOV to the celestial pole.

I am running a self-compiled KStars 3.4.3 from 2020-12-06.

I am running Kstars version 3.4.2 - from Astroberry Server
I set up a simulator camera and telescope info. If I put the angle in the camera simulator at 30 deg the fov symbol does come up at 30 deg. Now, how did you get a solver result in simulation mode? I do not have any access to the align module (it is there, but I cannot access any buttons)?

thanks,
Ron

Actually it seems I mis-spoke. My FOV symbol on the Kstars chart is always pointing at the NCP. None of the simulator rotation settings (in WCS or SimConfig) seem to have any affect on the FOV orientation.

And while you are working on this; it would be nice when you toggle on sensor FOV you get both the main camera and the guide camera FOV and if you could put in a physical offset between the two that would be even more useful (for finding guide stars - see how I just slipped that in!)

thanks,
Ron

I believe you have misunderstood some things.
1. To solve you require a mount in the profile, in this case simply the Telescope Simulator.
2. FOV symbols currently do not get their rotation from solved frames. That is what my P.S. Wishlist thought was for.
3. You can already create a custom FOV symbol with an offset to illustrate an OAG point of view.

I had been looking all over for a telescope simulator not expecting to find it under 'other,' I thought it should be at a higher level like the other scope (small point now that I know where it is).
Yes, I misunderstood what you said earlier, I thought you were complaining that the angle was off by a fixed amount, not that it did not show up at all.
Yes, what I did first was to create a new FOV simulator for both my main camera and the guider, I just missed the lower part of the box where you can put in an offset (trying to go to fast and end up behind where I started!). But there is an issue there as well. If you put in an offset for the guide camera and then rotate it, it rotates about its center not from the center point of the offset (where the main camera is).

As I am only working with ccd simulators, at the moment, I don't know how the 'real' system behaves. If the solver gives the correct angle of the sensor, then hopefully one could at least set that angle in the sensor configuration (or the WCS setting box) and the sensor FOV image on the Kstars screen would be correct. But that does not seem to be the case with the simulator. As I mentioned above setting the rotation angle in either of those locations did not affect the "sensor" FOV symbol in Kstars.

thanks for you help,
Ron

Your questions are tangent to the issues I created this thread to discuss. Regarding an actual bug I believe I have found, not a discussion on proper use of these features. I will therefore request that your points be discussed in your previous thread.
indilib.org/forum/general/7153-camera-ro...find-guide-star.html

Ok, no problem.

thanks,
Ron

So this is not a bug, just needs clarification.

astrometry.net reads FITS image from bottom to top, while KStars reads image from top to bottom. This results in a 180-degrees flip. You don't actually see this since it's done in the back-end so everything looks "correct". If KStars adds support for reading bottom-up then all the number would match without needing to flip.

Ok. Maybe that is something worth looking in to to make it easier to correlate solver results with FOV symbols.
The other oddity was why is the rotation in the CCD Simulator configuration -90° off in the solver?

The CCD simulator is aware of the mount pier side and rotates images taken on the two sides of the pier by 180 degrees. This is what happens in reality.

But 180 degrees is not -90.