Two questions, Toni.

I just noticed that the forum is not showing the quote in one of my previous messages.

(Toni) 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.

So what is the reversal point and is it defined outside of the driver context in Ekos? I specifically want to know what is doable to prevent cables getting pulled too hard, so please share the recommendations to setting the mechanical zero from this perspective, if you have any. Thank you!

The second question is regarding the driver implementation of reversal when the target angle exceeds the limits (defined in the driver). Say, I go ahead and implement this function, it shouldn't be too difficult. 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?

Read More...

You need to select ADU under the Flat duration section and enter a number that represents your desired brightness (many people go for roughly 1/3 of maximum, which is 2^x, where x is however many bits your camera uses to write pixel brightness values into output files).

See docs.kde.org/trunk5/en/kstars/kstars/eko...e-calibration-frames for some details.

Read More...

The driver logs show that your rotator firmware is from last year, so you really need to update that and see if it makes any difference.

Download the latest firmware from the Wanderer site, go to the download location and use the avrdude command I provided earlier (make sure to look up the correct port in the system log and also substitute the firmware file name to the one you will have downloaded).

Can Ekos connect to your mount when you don't select any rotator at all?

Read More...

That would assume the resulting FOV is going to be inverted, so there needs to be some kind of an acknowledgement from the user they are OK with that. The "preserve rotator angle" checkbox in the meridian flip options could be adapted for that purpose (when checked it kind of assumes the user is OK with flipped images).

Once we have this and Ekos needs to change the rotator angle beyond the rotation limits:
1. Ekos tries to move the rotator to position x
2. Rotator drivers could return some special code/enum to indicate rotation request is rejected because of the limits.
3. Ekos instructs the rotator to move to position (x - 360). Or switch the rotator to the "reverse" mode and move it by the needed amount.

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.

Read More...

I had my first night out with an automated rotator today, and alignment worked flawlessly. However, I soon ran into the situation where the rotator motion started pulling the cables to the extremes and I had to intervene.
Thus, my question.How is the reversal point defined and what is the suggested way of setting up mechanical zero in the rotator driver?

Having found out that the maximum limit that I can impose onto the rotator angle is 180 degrees, so I manually moved it to the extreme position (beyond which the cables are getting pulled too much), subtracted 180 from that, moved the rotator into the resulting angle (extreme -180) and set it to 0.
I think now it should not move beyond my extreme point, but will Ekos know to rotate into the opposite direction when the target camera angle requires so?

Read More...

This new driver is not part of INDI 2.0.6. So you either need to build INDI from the source (github.com/indilib/indi) or wait for the release that will include the driver.

Read More...

Thanks! Updating firmware indeed helped, and the problem is resolved.
BTW, since the official update instructions are only for Windows users, here is the command I ran in case it is useful for others using Linux:

avrdude -v -c arduino -P /dev/ttyUSB1 -b 115200 -p m168p -D -U flash:w:WandererRotatorM54.20240208.hex:i

I've already contacted Frank regrading this, so he is aware.

Read More...

Here's what I did and observed.

1. Connected. Current angle is loaded as 110.
Backlash is disabled, reverse is also disabled.
Limits are set to 0.

2. I click “Mechanical Zero”
Log: Virtual Mechanical Angle is set to zero.
Current angle is also reset to 0.00.

3. I try to make it go to 90.
It rotates CCW by 90 degrees, and as it is moving the current angle field is updated accordingly.
However, when it stops, the current value is set to 9.00 instead of 90.

4. I try to make it go to 0.
It rotates CW, but only by a tiny bit (I suspect by 9 degrees).
And the current angle field is set to 8.10 instead of 81 (I am starting to see a pattern here)

Looks like there is a bug that sets the current angle to only 0.1 of the actual value.

The logs only say what its rotation targets are, together with the commands, but one can see that the second move command parameter (-10278) is only -0.1 of the first one (102780).

[2024-02-27T00:19:48.966 JST DEBG ][           org.kde.kstars.indi] - Rotator Mini V1-2 : "[DEBUG] CMD: 1500002 "
[2024-02-27T00:19:48.967 JST INFO ][           org.kde.kstars.indi] - Rotator Mini V1-2 :  "[INFO] Virtual Mechanical Angle is set to zero. "
[2024-02-27T00:21:28.310 JST DEBG ][           org.kde.kstars.indi] - Rotator Mini V1-2 : "[DEBUG] CMD <102780> "
[2024-02-27T00:21:28.311 JST INFO ][           org.kde.kstars.indi] - Rotator Mini V1-2 :  "[INFO] Rotator moving to 90.00 degrees... "
[2024-02-27T00:22:59.032 JST DEBG ][           org.kde.kstars.indi] - Rotator Mini V1-2 : "[DEBUG] CMD <-10278> "
[2024-02-27T00:22:59.066 JST INFO ][           org.kde.kstars.indi] - Rotator Mini V1-2 :  "[INFO] Rotator moving to 0.00 degrees... "

Hoping to give it a test tonight, although not under the sky as the winds are a bit crazy today.

Read More...

I made an attempt to use the Inspector running a rather fresh build of Kstars on Raspberry Pi and found it crashing just when the autofocus routing is done and results are about to be displayed. Nothing in the logs at all. Could it be that the graphical representation of results is relying on some libraries that are not bundled in my build of Kstars?

The solution was to run Kstars remotely from the laptop, although on my macOS 12.7.1 the latest Kstars 3.6.9 failed to start, but 3.6.8 did, and luckily it already has the AI.
It was a pleasure to use, but I had to go to the explanation video on Youtube to remind myself that the view is towards the telescope.

Read More...