Alt AZ Skywatcher 14 goto Planetary Tracking

[Beyondlumen]

Hi! I need help with a technical issue. I have Sharpcap Pro and a Skywatcher GoTo 14-inch telescope. When I tried using planetary tracking, the mount kept slewing non-stop, even though the software sent commands. Am I doing something wrong or is it incompatible with my telescope? Thanks in advance cheers.

[admin]

Hi,

if you are using the Feature Tracking tool (https://docs.sharpcap.co.uk/4.1/#!2!Feature%20Tracking) then during the calibration the mount should move in steps - move a bit, pause to measure the image, move a bit more, pause again, etc. If it is starting moving and never stopping then it might be that the stop command is somehow not working or not getting through to your mount.

Can you control the mount movement successfully and move it at different speeds using the movement buttons in SharpCap (https://docs.sharpcap.co.uk/4.1/#GOTO%20Mount%20Control) - the calibration for feature tracking uses the same commands as those direction buttons, so if those work to move the mount (and stop it when you let go) then in theory the calibration should be able to move it correctly too.

cheers,

Robin

[MikeHuerto]

Hi Robin
Just so you don't go around in circles - this is the exact same problem I presented to you in the Autocenter thread a couple of weeks ago: viewtopic.php?t=6531&start=10. post #12 on the 2nd page of that thread,

In short, the guide pulses disable tracking - and the image starts to drift. This is one of the reasons I, and other Synscan Alt/Az users cannot calibrate SC feature tracking on Synscan Alt/Az mounts. At the time you said you would see if you could incorporate a 'resume tracking' comand in the code.

He has the same mount as I do (a SW 14" GOTO Dobson) I've discussed it with him by FB pm recently.

Best

Mike

[admin]

Hi Mike,

thanks for spotting that - I had assumed from the description of 'kept slewing non-stop' that the mount had started moving at some speed and hadn't stopped, rather than that it had stopped tracking leading to the image drifting.

I did add code to (hopefully) restart tracking after the calibration movements on an Alt/Az mount if the /prerelease command line option is used when running SharpCap. I may have neglected to mention that I had done that though...

cheers,

Robin

[MikeHuerto]

Hi Robin
OK - so then I assume it's in the latest update - I'm on 4.11680 - will try the 4.1.11757.0 from Jan 29.

Also - what do you mean by the "/prerelease command line option"

I see command line options mentioned in the advanced instructions - but Its not clear how I enter or enable them. Is it from the Scripting Console panel? I've never used the Python scripting feature before - so explicit 'how to' would really help me.

Mike

[MikeHuerto]

Ok - figured it out - I think - with the DOS command line .Ran this command - and SC opened up! So I assume I'm in the pre-release version.

"C:\Program Files (x86)\SharpCap 4.0\SharpCap.exe" /prerelease

Here´s a series of updates over the past 2 days:

EDIT
So - I gave the pre-release version a try. Attached is one of several logs- and a screenshot - Jupiter still drifted off the bottom of the screen - thats what I think the low contrast warning is about
Other times. If I started it further up the screen I got a inconsistent angle warning

Screenshot

Feature Tracking Screenshot 2024-02-03 223123.png (56.04 KiB) Viewed 740 times

EDIT Feb 4th. Just looking at it the next morning - wondering should the prerelease option have been for 4.1 not 4.0 for example: "C:\Program Files (x86)\SharpCap 4.1\SharpCap.exe" /prerelease ?

EDIT Feb 5th - I just noticed that when I run the command line for prerelease it opens up SharpCap 4.0.9478 - even though the last version I installed was 4.1.1157. Is that correct?. Also the bug with camera for the prerelease version is specific to the Uranus C Player 1. I tested my ZWO 462MC - and that worked fine.

In general the prerelease version 4.0.9478 seemed to act up a bit - at one stage, it closed the program down cos it said my license was more than 423 days old!! as as I said, other times, it had a problem detecting the Player One camera i was using.

When I finally gave up and started SC 4.1.1157 without the command line prerelease option, all was fine with Player One camera etc. - and obviously Feature Tracking wasn't working. Not sure whats happening there

Mike

[admin]

Hi Mike,

you do need to make sure it is the latest 4.1 version that you are running, so the command line to use will be either

Code: Select all

"c:\Program Files\SharpCap 4.1 (64 bit)\SharpCap.exe" /prerelease

or

Code: Select all

"c:\Program Files (x86)\SharpCap 4.1\SharpCap.exe" /prerelease

The top one is for the 64 bit version of SharpCap, the bottom is for the 32 bit version.

The log that you posted was for SharpCap 4.0, so that version does not have the code to potentially re-enable tracking in it. The screenshot is from SharpCap 4.1, but I'm not sure if you had managed to get the prerelease option enabled or not. The problem is that the line made by the blue crosses and the one made by the green crosses should be in opposite directions, but are both going in roughly the same direction - this is a result of tracking stopping when the mount is moved and not resuming You can see what the graph should look like when everything is working here : https://docs.sharpcap.co.uk/4.1/#!2!Calibration

cheers,

Robin

[MikeHuerto]

Hi Robin

Ok - so I used the correct command tonight
"c:\Program Files\SharpCap 4.1 (64 bit)\SharpCap.exe" /prerelease

The good news is that, the mount no longer drifts during calibration.Even when calibration fails, the mount reverts to tracking. However, I was not able to complete calibration due to lack of alignment of Alt angles - which I suspect might be backlash induced.

It seemed to work best at very high mount movement speed (60 and 720). Below that it didnt complete the Alt+ measurement. The best I got was the attached image.

Screenshot 2024-02-05 220058.jpg (241.54 KiB) Viewed 514 times

The Alt+ and alt - angles are almost identical (46.43 and 46.06) - BUT the Alt- points are in the top right sector instead of the bottom left sector - could this be caused by backlash? Looking at the planet movement on the screen, I could see the planet descending during Alt+ measurements and rising along the same path during Alt-. On the way up, I could see the pulse jolting the planet up to its next position. So, I don´t think it was moving up due to loss of tracking. And when the callibration aborted, the planet stayed put ' indicating to me that tracking was still active. I will try and get a screen video next time. Its a pretty big Dobson mount with large toothed gears and worm drive, so a bit sluggish- same basic design as my HEQ5 mount drive, just much bigger!

I experimented with a range of initial step size and movement numbers - not an exhaustive test, but the 2 aand 100 setting shown in the photo was the best that I tried. I was mainly playing with the Required Movement Parameter. I might try again with higher values for initial step size. I assume that larger initial steps sizes might counter the backlash, as the mount changes direction. Is that correct?

With what parameter do I increase the number of points on the scatter graph.- is that the required movement parameter- I would think more points would give me a more accurate slope on the graph - Is that correct?

So, some progress -

Mike

[admin]

Hi Mike,

good to hear that the tracking restarts now - sounds like my code to have SharpCap re-enable the tracking after moving works for both EQ and AltAz, so I will enable that fully (no prerelease option) at some point once we have more of this ironed out.

I think that you need to set the required movement to a higher value - particularly if you are using fast movement rates, otherwise even if things move in the right direction, the calibration will fail because it will not have enough points plotted.

I'm puzzled by the points for both Alt+ and Alt- appearing in the top right quadrant (and as a consequence the angles being nearly identical) - particularly if the planet seemed to move in opposite directions as you say.

If you have pure backlash then you should see the mount not move to begin with, then start moving after a few movement pulses. The same should happen in the other direction. I'm wondering if your mount has backlash correction set up to try to minimize the backlash effect and if that could be causing issues by over correcting? I would also expect the planet to drift sideways to the main movement a bit during the movements as a result of tracking turning off briefly while the mount performs its altitude movement.

It's probably also worth checking that when you turn off tracking, the drift direction isn't at the 46 degrees measured for the calibration - just in case that is what is being picked up. In any case, worth keeping a close eye on how the planet moves in response to the calibration of Alt+ and - . A log will contain some additional info that I may be able to pick apart.

It may be worth recording the screen during a calibration using a tool like OBS Studio - that would let you look back to try to spot anything you might have missed or share the recording with me...

cheers,

Robin

[MikeHuerto]

Hi Robin

Some more progress.

1)As you suggested, I increased required movement from 100 to 200 and it got through Dec and failed on RA a couple of times. I´ve attached a screen shot from one at 20:31 CET that should correspond to the times in the two logs attached-

failed calibration

DEC and RA Screenshot 2024-02-07 203118.jpg (299.47 KiB) Viewed 307 times

2)I checked and confirmed that backlash compensation was set to zero on Alt and Az drives

3) I tried turning off tracking. The planet just drifts slowly down the screen, slightly to the right. I was thinking that if there is some brief movement due to this drift as tracking is momentarily turned off during calibration, then you would expect it to move more rapidly in one direction when the drift is is the same direction as the guide pulse, but I didnt really see that. There´s a video in the link below, where you can check for yourself.

4) I have attached two logs that cover the period

Log_2024-02-07T19_34_20-17904.log

Log

(174.75 KiB) Downloaded 25 times

GuidingLog_2024-02-07T19_51_28-17904.log

Guiding log

(274.09 KiB) Downloaded 25 times

I have a couple of MP4 videos with commentary that I made with my phone - the Gbox video capture video on my PC does not handle multiple windows. One of the videos show the movement of the planet and the scatter graph during attempted calibration. The other video shows what happens when I turn off tracking. The file names indicate the time as local CET time, so you can probably align them with the logs.

You can access the videos in this dropbox link, together with the other files.

https://www.dropbox.com/scl/fo/ncnmb5yw ... kihfz&dl=0

Again, remember that this is with a hefty SW 14 inch GOTO Dobson, not the most nimble of scopes!

Let me know what you think

Best

Mike

Mike