Recenter image using platesolve .... problems

[MunichAtNight]

Hello Robin,

I tried the new promising and exciting new feature "Recenter..." and there are problems with it. I tried it repeatedly in several processes and each time it showed the same behavior and problem.

Initial situation:

• Skywatcher AZ-EQ5 with Celestron Starsense auto-alignment in AltAZ mode. This means that the Celestron Starsense hand controller is connected to the Skywatcher AZ-EQ5. The Celestron Starsense hand controller is connected to the Windows 10PRO computer (8GB RAM) via a USB cable (50 cm) via an active USB HUB from the PC to the hand controller by the Celestron ASCOM driver
• Camera: ASI183MC Uncooled.
• Telescope: Skywatcher 200PDS with
• Pegasus Falcon rotator running in “derotation mode”.
• All active components are connected via ASCOM driver and are visible from the side in Sharpcap.

I have been successfully using this setup with Sharpcap (3.x / 4.0) for a more than two years. Sharpcap Platesolving works great without any claims.

Yesterday I viewed M39 in the telescope. Positioning mount to M39 was done by Steallarium. In a second run I used Sharpcap to postioning M39. When M39 was succesfully found I carried out platesolving, then aligned the rotator to 0° / north, started Derotations mode in Falcon Software, performed platesolving again and then selected M39 in the DeepSky Annotation-Results window, adopted the name for the stack and then pressed the "Center in View" button and waited until Sharpcap M39 was perfectly centred in the sensor.

I then started LiveStacking in the Guiding TAB. I initially had a "recenter drift value" of 60, but I changed it to 35 during stacking.
sharpcap-41_10.jpg

After about 210 s, 35 was obviously exceeded and Sharpcap started a new plate solving. Everything was executed without an error message.
Time: 00:34 - 104 stacked
sharpcap-41_20.jpg

After completing the first recenter, the observed drift in the Guidind graph window increased dramatically faster. In the stack image you could also see a black bar on the right edge that grew very quickly

Time: 00:36 - 106 stacked
sharpcap-41_21.jpg

Time: 00:37 - 110 stacked
sharpcap-41_22.jpg

From this point on, Sharpcap performed a new recenter after only, one, two, three or four additional sub frames that were successfully added to the stack. After each recenter, the swings in the guiding graph became larger and the black bar became wider and clearer.

Time: 00:38 - 114 stacked
sharpcap-41_23.jpg

Time: 00:41 - 125 stacked
sharpcap-41_25.jpg

I was able to reproduce this behaviour repeatedly in a row. Started from a new starting position each time. At first there was a very quiet, barely increasing guiding graph for several minutes. From the first "automated" Sharpcap recenter procedure, everything got worse and worse, faster and faster.

Here are the links to the last four LOG files from Sharpcap.

Log_2023-09-28T23_19_49-9000.log

Log_2023-09-28T23_35_10-6436.log

Log_2023-09-29T00_08_39-6052.log

Log_2023-09-29T00_17_26-12124.log

I hope my description has all the necessary facts and data so that you can understand the problem. If anything is missing or further details are needed, I will be happy to help. If I should carry out other tests or examinations, I am happy to be able to support you.

Ouch! Too many links in my post. Oaky! No problem. All files in this ZIP file.

https://f2m.org/sharpcap/sharpcap-41_22.zip


Servus - MunichAtNight - Ewald

[admin]

Hi Ewald,

thanks for the detailed description. Unfortunately I am away at the moment, so I have limited resources to look into this right now.

What I can see is a couple of things that will need further investigation

1) The image scale is roughly 2 pixels per arcsecond and the offset to be corrected is about 80 pixels, but the calculated movement is a lot smaller only about 10 arc seconds

Code: Select all

Debug  	23:49:25.341122	#1 	Notification (Status=OK): Moving mount from RA=21:31:58,Dec=+49:00:44 to RA=21:31:55,Dec=+49:00:35 to recenter stack				in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)

2) The mount doesn't seem to end up where we ask it to go

Code: Select all

Info   	23:49:25.341481	#1 	Slew target calculated as RA=21:31:55,Dec=+49:00:35
...
Info   	23:49:47.239394	#1 	After slew, mount points at RA=21:32:01,Dec=+49:00:33	

Again though, the error here is only a few arc seconds, so shouldn't be enough to explain the big jump out to 150 pixels error.

The two things that are left to consider are

* Is there a J2000/JNOW error somewhere or is there a calculation error in the movement - I will check this after getting back from a weekend away

* Is there significant backlash in the mount movement that might be contributing here?

cheers,

Robin

[MunichAtNight]

Hello Robin,

for me there is no rush. Whenever you have time to take a closer look at it and give me feedback on it, that's great.

I think I won't be able to contribute anything to point (1). If so, please let me know.

Point (2) about the backlash gave me something to ponder. But I haven't noticed anything similar about the mount so far. But it's conceivable that I didn't tighten the clutches enough. I don't tighten the clutches extremely hard. But of course it could be that the 8" Newton with the large lever moves when moving, especially when changing direction.... You never know???? I will do the appropriate tests again. I use two different ones Setups with this mount. Once like this evening the f/5 | 1000 mm | 8" Newton - the first night with Sharpcap 4.1 But also a much smaller Newton f/4 | 600mm | 6". As soon as the sky opens, I'll try it again and get back to you.

Kind regards - Servus MunichAtNight - Ewald

[Sierrase]

Hello i have a question which is not relative to your problem.
I understand that the celestron starsense autoalign camera works with a skywatcher mount (azeq5). I thought it was not possible but it seems it works for tou. Do you know if it works for a azeq6 in eq mod? If it works in eq mod for azeq5 I suppose it will work for as eq6
Thanks in advance and have good sky

[MunichAtNight]

Hello @Sierrase,
Starsense should work with Skywatcher AZ-EQ6 as well. But I don't have any experience with AZ-EQ6 neither with EQ-Mode. EQ-Mode based on documentation should work in two steps. First it helps you by doing polar-alignment. Second is working as Starsense usual.
Servus MunichtAtNight - Ewald

[MunichAtNight]

Hi Robin!

I solved it on my own. I found the problem!

I had in Sharcap Plate Solving settings ..

sharpcap-settings-01.jpg (213.83 KiB) Viewed 7666 times

... Offset the mount position to centre the target - I changed it now to Sync Mount and Re-centre target and now it works fine.

My az-eq5 is certainly fully utilized with my Sywatcher 200 PDS f/5 |1000 mm, maybe even a little overloaded. But with a guiding value of 75 to 100, the “soft guiding” worked well yesterday. Thank you for this great function and the implementation in the new Sharpcap version.

I still have one suggestion. I use a rotator that is also displayed and supported directly in Sharpcap in the side area. What I, a lazy hobby astronomer, is missing is a function to rotate the camera to north 0° once you have successfully completed the plate solving and centring. It is displayed in the "success message" of plate solving as an example "330° EofN" and you would really like to have a button/command: Align to 0°!

I regularly feel dizzy, do I now have to turn 30° counterclockwise or clockwise.

If there were a button "Rotation North" next to the "Center in View" button in the "Deep Sky Annotation Results" window - a dream ....

plate-solve-rotate-sync-03.jpg (385.27 KiB) Viewed 7663 times

Even in the "Goto Catalog" function, if you have selected an object and let Sharpcap go-to, it would be incredibly fantastic if Sharpcap would also rotate the object to the north using the rotator to complete the centering of the object!

And AltAZ users who have a rotator without a "derotation function" like the one I use on the Falcon would probably want the Sharpcap to not only be "recentered" in "soft guiding" but also rotate in the opposite direction to compensate for the field rotation! Endless wishes for the future!

When version 4.1 is released, I will buy another additional license in addition to my permanent license. I think that's the least I can do as a user, even if only as a really small token and thank you for the ongoing developments and continuation of this incredibly great software. Thanks!

Servus - MunichAtNight - Ewald

[admin]

Hi Ewald,

that's interesting, as I would have thought that both options would end up with the correct target (at least the first time you use the function after moving to the target - the offset GOTO function will not work a second time on the same target, as it takes the current co-ordinates as the target... One of the things I keep meaning to deal with).

I must admit that the rotator features are fairly limited at the moment - quite probably because I don't actually have a rotator myself, so I'm not really familiar with the things you might want to do using it. One thing that's interesting is the desire to always have north upwards in the image - why? Surely, for lots of targets with a rectangular camera sensor, the best framing can be achieved in other orientions.

cheers,

Robin

[MunichAtNight]

Hi Robin!

One thing that's interesting is the desire to always have north upwards in the image - why?

As an AltAZ EAA observer, I probably have different approaches and desires for the equipment I use. The AltAZ-related image field rotation not only creates the “black” corners in the images, but also depending on the observer geo location and especially the location of the object, there are widely varying maximum possible exposure times from which on you won't get elongated stars. The range is from eight seconds to almost fifteen minutes.

And now important for your question about why sensor north orientation, I have different north orientation depending on the Alt-AZ location of the observed object. Unlike an EQ user, I have to readjust the rotation angle of the sensor for each observation in order to achieve the desired result. Due to the system, an EQ observer has a fixed and always the same orientation of the sensor that never changes. An AltAZ observer like me has to carry out a new sensor north alignment for each observation in order to even know how the object will actually be in the sensor later. The rotator is not only used to set a desired rotation of the object in the sensor, but more importantly is needed to be able to repeatedly assume a defined rotation angle depending on the AltAZ location of the object. Although I don't need to do a polar alignment for my mount, I do need a polar alignment for the sensor.

20221029_frame_M31-00.jpg (290.94 KiB) Viewed 7635 times

Otherwise I wouldn't be able to adopt a predetermined angle of rotation to, for example, place Andromeda on the diagonal of a rectangular sensor.

Which I almost forgot. Last night I was with the AZ-EQ5 and my little Newton Skywatcher Quattro 150P | 6" | 600mm | f/4 on the way. A dramatically smaller starting value of 25 for the “soft guiding” was enough to allow the first re-centering process, started automatically by Sharpcap, to be carried out after a good twenty minutes.

I love this feature!

Servus Ewald

[admin]

Hi Ewald,

thanks for the explanation of how you use your rotator. I think I am going to have to add one to my kit so that I can experiment more (and test properly too for any new features).

Glad to hear that the recentering is working for you now !

Robin