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.



Read More...

Toni Schriber replied to the topic 'New Ekos Rotator Module' in the forum. 3 weeks ago

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...

Toni Schriber replied to the topic 'New Ekos Rotator Module' in the forum. 3 weeks ago

Of course the whole logic could be delegated to the rotator drivers themselves, kind of similar to how mount drivers handle meridian flips. Actually that could probably make more sense since different rotators may have different capabilities.
That's exactly the conception behind the buildup of the rotator control in KStars. It follows the idea of subsidiarity principle: EKOS is responsible for the highest level of control (setting angles, starting rotations, calibrating, define flip policies and so on), whereas lower level functions or settings are delegated to the device. A good rotator device should manage the reversal angle in the firmware. So indeed, the right place for this setting is the device driver.

Read More...

Hi Richard
Which version of KStars are you running? 3.6.9 has the issue you are describing for option "Differential Slewing". It's corrected now: Look here and here .

Read More...

How do you create a delay on connection?
The delay is hardcoded, so there is no possibility to change it. But even such a facility would not correct the initialization, because the "Goto"-field does not return an OK (the led button stays gray!). In some respects this is flaw of the driver. I suppose however, that a majority of the rotator drivers have this problem, I'll try to circumvent this weak point with a change in the code of the EKOS rotator module.

Read More...

Is there any way to do plate solving and syncing without issuing a goto in 3.9.6?
Hi Gyuro
I suppose you mean version 3.6.9, right? There was an edition of this version with this "feature" I introduced by mistake. Meanwhile there is a new edition of 3.6.9 without this restriction. So an update of KStars should bring back the traditional behaviour.

Read More...