Sorry guys, I don't have much to contribute on rotators. I have a nitecrawler, but I don't connect the rotator because I don't want to re-do flats but 1 or 2 times a year.

Bryan.

drive.google.com/file/d/1XuYre4_OPqZKjK9...EZy/view?usp=sharing

Some examples. I think I got the internal solver to work by adjusting the 'extraction params' for min star area from 10 to 2. I also adjusted min and max size in the middle block to 1 and 25. I turned off use scale and auto update... then adjusted those values for the image scale to what I know them to be (1.47). It seems to be plate solving reliably.

Now, with this particular build it is crashing every 5 pictures. I'll let you know if it's still doing that after this run...

Any idea when your differential fix will be pushed to a stable build?

Toni,

Ran into where it did the freezing on rotation again. Logs attached. The nightly build also crashes after 5 images in scheduler.. not quite sure what to do from here.

Hey Toni,

Jasem logged into my machine and worked through a bunch of issues. First, we figured out that unless you have filter offsets... don't use adaptive focus. It'll crash it. Then, we learned that because I have a color camera, I do need to have it debayer in the fits viewer.... otherwise it just can't solve for whatever reason.

I don't know where I changed that or why (I think I read it saved resources). But, I'm squared away.

So if you're using an ASI2600MC (color/OSC) camera... make sure you debayer the pictures for plate solving. He's going to add it to the align troubleshooting guide.

Thanks again for the help, and to your original support, rotation is working along with differential slewing.

One thing I've seen about rotation... everytime I start (even though I've been at the same rotation) it says I'm at:
2024-02-24T22:44:56 Setting camera position angle to 65 degrees ...
2024-02-24T22:44:56 Target is within acceptable range.
2024-02-24T22:44:56 Camera position angle is -114.709 degrees.

At -114.709 even though the last time it put me at 65 degrees. Then it will rotate it to 65 degrees. I feel like it's going in circles everytime I start the scheduler. Is there a way to have it detect that the negative number i the ame thing as the postive number? I don't want it to keep going in circles and break cables.

... I'm squared away.
Hi Chris. I was away for a couple of days and couldn't follow the discussion.
I'm glad you were able to bring EKOS to production level! And of course I'm pleased that differential slewing is working now.

One thing I've seen about rotation...
Actually there is a routine, which should read the current position when starting EKOS and display a message in capture module:

Is this working for your nightcrawler?

I can’t imagine the satisfaction in getting a bug fixed. Im very thankful for it.

I don’t see a setting to enable that feature? Is it in Ekos or in the INDI driver?

I guess I would wonder why the routine wouldn’t judge the first picture taken and adjust from there as opposed to relying on a stored value that may or may not be relevant.

I use the same PA (during these tests) night after night and it does a 180 flip each time.

I don’t see a setting to enable that feature?
There is no such setting, the initialization should be activated by default.
But the problem is timing: I had to introduce a delay because very often the rotator did not return its current state. Thus if you do not see this message, the routine is not able to fetch the initial state of the rotator. (See also capture log: "Rotator Settings: Reading initial raw angle failed.") If you can confirm this behaviour, I have to find another way for initializing the angle.

This does not explain the 180°-rotation though! Which flip policy do you use? If the reference image was taken on the opposite pier side and flip policy is "Preserve Position Angle" the rotator will always turn about 180°.

ADDENDUM: When did you take the screen shot in the attachment? Directly after a new start of EKOS?

Hi,

Is there any way to do plate solving and syncing without issuing a goto in 3.9.6? As of now all options end in the error message "No Target - Please pick an object."
Since my motor controller (EQDrive Unitrack) is completely erratic, when it comes to goto (just happily goes round and round until the end of time), I was relying on manual slew-platesolve-correct cycles, that are now not possible anymore, since it is not allowed to do any action.

Lehel

Hey Toni,

Yea, that screen shot is right after startup of the server/connections made. I checked tonight and there is no message on any of my module pages that match your initial alignment angle. I'm assuming that's why it's defaulting to something random. How do you create a delay on connection? I can't seem to find a setting for that. Or, is a manual thing where you connect to the focuser individually?

This wasn't an issue in previous iterations... I feel like it's a bug related to how it's figuring out rotation.

Is there something specific I can turn on inside the align module or some other tool that would help ID what I'm seeing for you?

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

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 and I'll try to circumvent this weak point with a change in the code of the EKOS rotator module.

Toni,

I think your implementation of the rotator is fundamentally flawed... while I agree that it should be the driver that does the work, it needs a 'seed'. Aka the first plate solve needs to populate what the current is into the driver for that session. As an example, I take my camera off and shift the angle... it needs to be updated. I shouldn't have to manually do that.

On the flip side, I can 'sync' my rotator. Perhaps there needs to be a warning that there has been no 'sync' this session and that unexpected movements will occur.

My mount defaults to a random -114 degrees. Why? I dunno. But, if your implementation relies on better device drivers, that probably should be worked out with the developers before implementing. What it breaks is scheduler automation.