FYI: invent.kde.org/education/kstars/-/commit...fb1456a989fbf2abe790 is merged into 3.7.1 development cycle. I don't know if there will be a backport to 3.7.0.

Read More...

Yes your'e right, unforunately! I once reported the bug to the team and at a first glance it seemed to be corrected. but it is still present. I'll take a look at it once again.

Read More...

Milestones

Read More...

Jasem already merged the PR, so it shoudn't last long until it is in the nightly build.

Read More...

A pull request to fit the initialization problem is underway.

Read More...

Saving the .esl file and loading it again, won't load the FITS File value.

This is a known bug in 3.6.9. It's already rectified in current 3.7.0beta (nightly builds).

Read More...

Hi Chris
There are a lot of discussions about the features a rotator driver should have or not have. Here is an interesting one from the past.
Of course a proper functioning of your NiteCrawler - as all rotators - depends on reading the initial angle when EKOS is starting. As I said the problem with the NiteCrawler driver is the fact that it does not set the control led to green (see below). Right now this is a confirmation for the rotator module, that the the value in "Goto" angle field is indeed the initial angle. If the control led is not green, the rotator module doesn't read in the angle.

I use the same PA (during these tests) night after night ..
Can you confirm that the displayed rotator angle of 129.18° in the "Goto" field corresponds to this PA? If this is the case, I can try to read in this value without checking the control led.

So what is the reversal point and is it defined outside of the driver context in Ekos?
As I said above I wrote the new rotator module with subsidiarity principle in mind: Let lower levels of hardware/software do as much as possible. My rotator device is a Pegasus Falcon (rather lower price level) and it has reversal point built in (hard coded in firmware, but nonetheless usable). So I thought that the majority of the rotators in this price level and above have this option too (Correct me if I'm wrong). Thus I did not embed such an option in the rotator module.

.. so please share the recommendations to setting the mechanical zero from this perspective,
I personally have put the cables in such a way that they are wrapped partially around the camera in order to do a full 360° rotation. Then the Falcon has an option that syncs the rotator angle to zero, so I can set the mechanical zero. (As stated above I thought that this is standard and I did not implement any constraints in the module regarding device mechanics.)

But will Ekos be okay with the resulting image being flipped relative to the expectation? Will the alignment routine successfully finish in this case and not go into some infinite loop asking the rotator to move by 180 degrees?
I wrote the refactor of the rotator module before the option "limit angle" was added. So there aren't yet implemented any assessments concerning this option Frankly I think it will be not very easy to catch all possible entanglements regarding the interferences of this option with the rotator policies. And I confess, that I do not understand in detail how this limit works or should work. So it's best to ask Jasem if he can explain what his intentions are concerning this option.

But will Ekos be okay with the resulting image being flipped relative to the expectation? Will the alignment routine successfully finish in this case and not go into some infinite loop asking the rotator to move by 180 degrees?
As you can conclude from my statement above, I'm not able to answer this question. I fear there could emerge big problems with this "limit angle".

Generally I still think the best way to rectify mechanical problems is mechanics. There are certainly ways to put the cables in such a manner, they do not wrap up. (See my second answer).

Read More...