Falcon Rotator and SGP do not play well together

Here’s hoping you can help.I have two scopes each with a PegasusAstro Falcon Rotator running the latest firmware and Falcon Software.

Both scopes run on Windows 10; SGP 544; ASCOM 6.5.

I only mention the two scopes as both are displaying exactly the same behavior, which is, that the platesolving process cannot set the rotator to the correct angle and at some stage aborts the sequence. This happens with both ASTAP and PlateSolve2.

This is what happens:

The target is set for 90°. The platesolver usually finds the target immediatly and then instructs the rotator to move to 90°. which it does.

  • The platesolver then establishes that the sensor is not at 90° but at 55° (for argument’s sake), which can be seen in the rotator Error column of the Platesolver table.

  • The solver then instructs the rotator to, what seems to me as the observer, any random degree, such as 265°. Random, as I cannot fathom why 265° would be moving the rotator closer to the target of 90°, unless the idea is to “flip” the sensor, to see if the angle is then correct.

  • So, the rotator moves to 265° and the platesolver does it’s thing, coming to the conclusion that the rotation error is now even larger than the last time and sends the rotator to,what seems, another rondom angle.

  • This continues for the 10 tries I have set it up to do and then the whole sequence is aborted, unles I cancel the platesolve, change the Rotator from the Falcon to a Manual Rotator. I then start the sequence again.

  • The platesover finds the target and comes back with the screen to manually move the camera by lets say 35° counter clockwise, which I do using the Falcon software. I click on OK in SGP and Bob’s your uncle, the platesolver now reports that the rotator is at the correct angle and the sequence is started.

  • The manual solution doesn’t always work though. It would seem that SGP gets “confused” at some stage and then there is no other soluton but to restart SGP again.

  • Strangely enoug, once the angle is confirmed and the sequence started and I change the rotator back to the Falcon rotator, the Meridian Flip will work fine and sometimes it even finds a new target without any issues.

The reverse direction has not been set for the rotators, as the run in the correct direction according to the Falcon software.

I’m not sure if this relevant but lose their synchronization after the first move from 0° to say 90° and the platesolve is done. After that, SGP will show that the camera is supposed to be at one angle, the Rotator view will show a second angle and the Falcon software will show a third angle. See attached JPEG.
I have a video clip showing the random behavior if that is of interest.

Here are the links to the Logfiles and the JPEG:
https://onedrive.live.com/?authkey=!AsBo4_OaHYH2iQg&cid=AF0D18E8AC356D22&id=AF0D18E8AC356D22!72943&parId=AF0D18E8AC356D22!1249&o=OneUp

https://onedrive.live.com/?cid=AF0D18E8AC356D22&id=AF0D18E8AC356D22!73345&parId=AF0D18E8AC356D22!54060&o=OneUp

Thank you for your support. My apologies for the long description.

Regards,
Allen

Update: I started both scopes with a „manual“ rotator last night. After setting the angles requested by the platesolver manually, using the Falcon software, the sequence started correctly.
The rotator Settings were then changed to the Falcon rotator and all subsequent target changes and meridian flips worked perfectly.
My assumption is, that there needs to be an initial synchronisation between SGP, the Falcon software and the rotator.
I have a suspicion, the SGP and the Falcon SW „expect“ the camera sensor to be at different positions at angle 0°. The Falcon SW suggests the long side of the sensor to be horizontal, whereas I get the impression, SGP „expects“ the sensor long side to be vertical (90° to what the Falcon SW expects). I’ll test this as soon as we have clear skies again.

Thank you.

No help from anybody? I’ve installed SGP 600 and changed the angle of the sensor, still have the same issues.
Apparently the rotator works fine with NINA.
I suppose they will just have to go back to the dealer, as they are useless without SGP support. :pensive:

SGP doesn’t care about the initial angle. When a plate solve is done we hold an internal offset inside of SGP for the rotator and sky angle. If you solve and sync with SGP you’ll see the rotator angle change inside of SGP, if you then tell the rotator to 10 degrees off of this position what happens?

Jared

Hi Jared,
Thank you for getting back to me.

I accept that SGP does not depend on the initial angle of the sensor and that an offset is established with the platesolve and that works fine in the first step. The next step would be to calculate the difference between the offset and the angle the frame should be. SGP sends the rotator to the new angle and takes another solve to establish the new offset.

Then usually things go really crazy and SGP send the rotator completely to the other side of the circle. Why? There a new solve is taken and the offset is larger than the start offset. This goes on until the maximum number of solves are reached and the whole sequence aborts. The attached Logfile is full of such examples.

Regards,
Allen

SGP doesn’t control how the rotator gets to a position. SGP says “Go to 270 degrees” and it’s up to the rotator to determine how to get there. However it could be that SGP expects the rotator to go CW and the rotator moves CCW. Does the rotator have the option to reverse direction in the ASCOM settings?

Jared

Yes, there is a switch in the Rotator SW and the rotator moves correctly. I’ve tried using the reverse switch in SGP, with the same results.

To your statement, the rotator doesn’t know what the measured offsets are and therefore cannot send itself to any specific angle.

I made a short video of the process:
https://1drv.ms/v/s!AiJtNazoGA2vhMFVglvGdrR9Tfq0pA

One can see that Plate Solver sends the command to the rotator which angle to move to.

Thanks,
Allen

So , we had a few hours of clear skies here yesterday and I’m fairly have an inkling where the problem may be.

  1. SGP and the Falcon software both move the rotator in the same direction! Tersted that.

  2. Let SGP run the rotator with abysmal results. See video clip and Excel analysis of the run. Run abortet manually after 7 unseccessfull attempts.

Noticed the following issues:

  • SGP does not check to see if the angle error is + or -. Subtracts the angle error from the current position and tell the rotator to move (in the wrong direction). See Excel table and clip. This goes on for as many attempts are set in the rotator settings (10 in my case) and then aborts the sequence.
  • The angle error is thus doubled with every step. There seems to be no check to see if the angle is increasing and take counter measures, by increasing the angle by the already moved angles and adding the original 3° angle error. That would have moved the rotator to the correct place.
  • The SGP “Current Position” is not updated after step 2. Platesolver just mentions that it is sending the rotator to 90°, but is in fact moving the rotator by 2 * the current angle error.
  • Yes, SGP does not control which way the rotator moves by telling it to move clockwise or counter-clockwise, but it does tell it to move to a certain angle and if that angle is calulated incorrectly, then it won’t work. The rotator being “dumb” does not know in which direction to move and relies on SGP to issue the correct command.
  • The “manual” process works with only 3 steps, using the rotator software. See the second attached clip as proof. Except for changing the rotator type in SGP, no changes were made.

From my laymans persceptive the issue is definitely in SGP and how it controls the rotator. I hope you can fix this soon.

https://1drv.ms/v/s!AiJtNazoGA2vhMIHzXsFM0869wY27A?e=efCkgh
https://1drv.ms/v/s!AiJtNazoGA2vhMIJjWDCm8LoE6f8LQ?e=rn1mI0

Thank you and Clear Skies,
Allen

P.S. I’m using SGP 609 and the latest Falcon ASCOM driver.

You need to set the reverse direction option, this is exactly how my rotator worked when that option wasn’t set.
It’s very easy to see because the error is doubled after every attempt.
My Gemini rotating focuser har worked flawless for over 1 year after that option was set :+1:

Hi Xplode,
thank you for the feedback. Where should I set it? In SGP or in the Falcon Rotator software? I had it set in the rotator software and that caused SGP to just send the rotator all over the place.

Thanks once again.

Regards,
Allen

It seems your software moves in the correct direction so you want to set it in SGP.

I wonder if the devs could add some type of error detection so if the rotator error doubles 3 times it will switch the rotation direction automatically? This can’t be that hard to add?

Thanks, will try it during the next clear night.

I wonder if ASCOM commands are somehow moving in the opposite direction or the the reverse switch in the driver isn’t getting applied to them? I find it difficult to attribute this directly to SGP as we the same code is used for all rotators and this seems to be a specific problem to the Falcon Rotator.

If you start at 0 and have SGP move the rotator to 90 does it move to the same location as if you were to do the same with the Falcon Software (I mean the actual camera…not what the UI displays). The behavior shown in the video behaves exactly as I would expect if the rotator needs to be reversed in the ASCOM driver.

Jared

Hi Jared,
I’ve stood next to the rotator and camera, during daytime testing and have moved the camera with both the Falcon Software and SGP. They move in the same direction and to the same location physically.

The “disconnect” appears when the first platesolve is completed and the first position is calculated in SGP. To be honest, I’ve not stood next the setup during the night, when it goes through the platesolving process. I’ll give that a shot during the next clear night.

As already stated above, I did have the reverse switch set in the ASCOM driver. That’s what you see in the very first video. Maybe the app needs to be restarted to apply the change. I’ll let you know.

Allen

Hi Jared,
I did some testing this afternoon.

The reverse switch in the ASCOM app doesn’t seem to work. The direction of the rotator does not change when I activate the switch in the Falcon app.

In SGP the reverse switch only works if I disconnect the rotator and activate it again, and then only if the current position is larger than 0. For instance if the current position is 90°, it jumps to 270° after the inactivation and reactivation. That does not happen in the Falcon app.

Allen

For SGP are you referring to the “Reverse corrections for Manual Rotator”? That will not change the behavior of a “normal” rotator…and honestly should be moved from that panel.

Thank you for testing that. As I thought from the video it didn’t appear like things were reversed thus the doubling of movement. I believe the Pegasus folks are aware of this issue but I’ve also sent them an email so hopefully they can fix the reverse handling.

Jared

Hi Allenk,
Latest firmware (v1.3) of Falcon Rotator does not require the reverse motor option. Please unselect reverse (this is a one off setting as it is stored in Falcon 's memory).

Please try to center (platesolve) the target via SGP without the reverse option

@Jared: yes I’m refering to the “Reverse corrections for Manual Rotator”, which I now realise won’t have any effect on the Falcon rotator. Sorry about that.

@evans: I am running v1.3. I’m not entirely sure what you mean with “this is a one off setting as it is stored in Falcon 's memory”? What do you mean with “one off”? Once I’ve set the switch, it’s stored in the Falcon software? Then if that functions correctly, then the rotator should physically run in the opposite direction than the software is showing. This is definitely not the case.

Does that mean that there is no reverse mode anymore and the switch is actually just left over from previous versions? In that case it would not matter if it’s selected or not. Does the ASCOM driver have a reverse function or not?

The point is, that the switch was not selected during the video clips you can see above. So why is SGP not able to home in on the target whilest doing a the platesolve?

There is obviously some communication issue between SGP and the Falcon ASCOM Driver and I would really ask that you get it sorted out. If I can contribute with additional information, please don’t hesitate to ask.

Allen

image

As you can see from above image the reverse motor is enabled. Click the highlighted “<<” button once and press NO at he question box to restore to default direction.

One off means that you need to do this once. After that setting is retrieved on falcon’s boot.