I'm sorry, but I have to refresh the thread!

I can't got working my falcon rotator correctly with 3.6.0 now:

Presetting PA for a capture results in totally wrong target position,


whereas setting PA manually works well


Most interestingly the resulting PA in the preset case is always the double of the offset minus the PA preset:
e.g. PA preset is 0.000: Result = 2 x 41.226 - 0.000 = -82.452 (see first image)
or PA preset is 10.000: Result = 2 x 41.266 - 10.000 = -72.452
and so on ...

Moreover I'm getting the same result with the simulator rotator!!! What are the experiences of other users? In any case I will investigate further.

hmm I thought Falcon has reverse? I need to check. Btw, 0 to 90 rotates it CW to CCW (looking from behind)?

OK! It seems I have found the problematic code: In "sequencejobstate.cpp" there are yet two other locations, we have to correct angle calculations!
I will put a PR based on your changes in invent.kde.org/education/kstars/-/commit...cbded39e4891fe3c85e8

Here is the PR: invent.kde.org/education/kstars/-/merge_requests/701
I didn't test it throughout yet. But first tests with the simulator rotator and Pegaus Falcon showed correct behaviour.

I wanted to say thank you for putting this change in. I used my nite crawler when I first went to Ekos and realized this was the issue but didn't know how to get it fixed. I then got a new scope and forgot about it. I just got my nitecrawler scope back out and it was a real welcome change.

One thing it doesn't do is 'save' in the configuration. Everytime I boot I have to re-select it.

Both issues (reverse and not saving) were fixed by Jasem in the Mac version last month. I thought it would have been fixed in all versions.

I'm using a Raspi4 and the configuration save doesn't work. The reverse function is there and working (thank you!!!).

This seems like a good thread to pickup a follow-on question about the Nitecrawler related to limits. The ASCOM driver has the ability to set a minimum and maximum angle which would be helpful for my setup to avoid collisions between the pier and the filter wheel. Being able to go +-180 isn’t really necessary from a framing point of view, +-90 will allow full coverage of the options for a rectangular sensor. Since in the past I have had cases where things rotated unexpectedly after meridian flip or simply due to user error it would be nice to have min and max angle settings to guard against this. As far as I can tell this isn’t possible with the indi driver. Is this the case? It would be a rotator angle limit since it relates to the physical position as opposed to position angle.

I think the way rotator angle works on the Nitecrawler you can’t go negative, it is just ticks times the degrees per tick. The Nitecrawler home is at zero so you would set it so that somewhere like 90 rotator angle puts the filter wheel away from the pier and then set rotator angle min to 0 and max to 180. In this way you’d never have the top of the filter wheel aimed at the pier and would never need to pass through 0 entailing a full rotation in the other direction. Is there any way to accomplish this in kstars/indi?

Sorry Thomas, I run a bit late with this answer. I was quite busy bringing the new rotator module into KStars version 3.6.5. It is now merged in 3.6.5 beta and ready to test. Just go to this article for more information.
I think your idea is a worthwhile proposal. I hope I can find some time to try out such constraints for the new rotator module in the near future. Besides, I think it would be interesting for you to try out the new rotator module. Just pay attention to have a way back to your current standard version, as I pointed out in the mentioned article.