Falcon de-rotation

[knro]

Need to support derotation for Falcon rotator (and others). We need to calculate the parallactic angle for derotation. This is what Evangelos over at Pegasus Astro recomments:

tan q = sin H / [ (tan phi * cos delta ) - (sin delta * cos H)] where H is the hour angle, phi is latitude, and delta is declination.

and convert it to steps per seconds so you can push them to the Falcon Rotator.

or work with the Rate of rotation as mentioned here; http://www.jdso.org/volume7/number4/Frey_216_226.pdf)

I think parallactic angle is better for the alt/az derotation compensation algorithm.

The rotator accepts a value in milisecs (how many steps should do every x milisecs).

To help you further the rotator can do the following movement: (with current firmware)

0.01146 deg Or 41.26 arcsec Is the minimum falcon angle movement = 1 step (full step drive)

DR command (e.g DR:200) commands the Falcon Rotator to move 1 step per 200 milisec. (think it as a timer that ticks the rotator to do 1 step per time interval)

[pawel-soja]

Hi! What a coincidence ;) Very interesting topic and let me share my observations.

I just upgraded my frankenstein with a Falcon rotator. I was thinking of rotating the field to take longer shots. I came across a similar article about rotation speed.

I searched for opportunities in KStars but found nothing. I decided to write a simple program that connects to the indiserver and listens data from the telescope and controls the rotator.

I was wondering why calculate rotation speed and not position to get the same effect as in equatorial mounts.

So I decided to recalculate everything to get this angle. The effect is that the rotator is rotated (visualized in the small app) just like the preview in the KStars app.

Is this the wrong approach? I haven't tested the whole solution yet, because there are still clouds and I can't see anything.

Another problem I expect is guiding because for this purpose, I have a small lens attached to the main telescope, which has no rotator. Here I have an idea to detect the center of rotation of the main camera. For this purpose, I adapted an application that is helpful for Netwon collimation, to detect the center of the image when it rotates using a rotator.

This center is not always in the center of the camera matrix, because the camera may have a shifted sensor, in addition, the entire optical path may not be in the axis. Having marked the center, I am now able to set the center of the image from the guiding camera (from the small lens) to coincide with the found center of the main camera. Now keeping the star centered in the guiding camera, on the rotating camera, the star will not draw a circle and the rest of the camera matrix will rotate according to the rotating earth canceling out the rotation of the field.

It's all my theory, still waiting to be tested (so long that I'm already building a new set on the AZ-EQ5 and WO Z81)

Warm greetings!

[knro]

Lovely photos!!

IMO, I think it might be a better approach to delegate this task to the driver and not the client (i.e. rotation). Otherwise, each client would be required to implement its own rotation loop.

[pawel-soja]

Thank you!

A very valid point indeed. If no one is dealing with this topic, including you, I can suggest something in the form of a pull request. But before that, I want to test what I've created because it's a nice testing ground. By the way, I will do a little refactoring with the transition to INDI::Property (I already partially have it).

I also want to thoroughly analyze the classes related to rotator support, because maybe it would be worth doing for all rotators in some base class.

Today promises to be a beautiful sky (finally!!!), but I want to devote it to the long-awaited AZ-EQ5 mount. I wish you all clear skies and sleepless nights! ;)

[github-actions[bot]]

This issue has been inactive for 60 days and is being marked as stale.

[github-actions[bot]]

This issue has been closed due to inactivity.