Alt AZ Skywatcher 14 goto Planetary Tracking

[admin]

Hi Mike,

thanks for sharing the videos - it makes all the difference!

In the one where you try to calibrate I can see straight away what the biggest problem is... Once you start monitoring, SharpCap draws a '+' on the screen at the point where it has calculated the center of the planet to be, and that '+' is nowhere near the Jupiter image. That means that the data going into the calibration is mostly garbage due to the measurement of the planet position being incorrect.

So, from there we can look for the root cause of the cross being in the wrong place... The likely cause of this is incorrect settings of either the image brightness, or the 'background level' in feature tracking or both...

First step is to ensure that any display stretch in the mini histogram is turned off and that the image is exposed correctly without needing a stretch - the feature tracking works on the unstretched image, but you see the stretched image, so at this point having a display stretch can be misleading.

The second step is to adjust the background level percentage until the cross moves into the center of the planet and follows it. When calculating the center, SharpCap ignores all pixels below the background level, so you have to set the value so that the black background of the image is below the % set but the planet itself is above it. Showing the histogram before feature tracking would let you see a good value to pick. If the background level % is set too low then the dark areas of the image get included in the calculation, and even though they are not bright, there is a lot more dark area than planet, so it can be the dominant effect and put the cross roughly in the center of the image.

You get some signal in the movement of the cross, because as Jupiter moves around the image it does affect the calculated position, but the signal is much smaller than it should be and has a lot more random error.

There may be more problems to overcome beyond this point, but getting that cross to follow the planet is the first thing to get sorted. If you have saved videos (SER format) from a previous session then you can load them into the High Speed test camera and have a play with adjusting the background level without needing to wait for a clear night.

cheers,

Robin

[MikeHuerto]

Hi Robin
Apologies my bad. Normally the cross is indeed centered in the planet. I just didnt notice as I was uploading the video I sent yesterday that the cross was not in the planet. The simple reason was that for that video I had gain turned up very high (723) to see jupiter throug the clouds- as a result it looks like SC placed the cross on the backround noise. Sorry!

Take a look at this video where the gain is set lower, but still very high at 500 - again due to thin clouds ' you can see the cross on the planet. It gets throug Dec + and - and then fails. Normally with this camera I have it set at 350. You should be able to align this run from 21.10 with the logs.

https://www.dropbox.com/scl/fi/ixue5cj8 ... 5iva0&dl=0

Ill try and do some more runs when the clouds clear - perhaps with the higher required movement at 200 and low gain, it might be better. We´ll see.

Best

Mike

[admin]

Hi Mike,

OK, that's a relief that it wasn't like that for all of the attempts. I have actually made the cross a fair bit more visible as a result of watching your video, as the current display is easy to miss...

Anyway, watching the other calibration run, the first direction looks fine, but the movement in the second direction hasn't really begun when it fails. At that point I suspect SharpCap has been telling the mount to move the other way, but there is substantial backlash that needs taking up before it starts to move back in the opposite direction. Normally the alignment routine would cope with that - it keeps trying to move the mount in the required direction until it starts to see some movement, but that relies on there being no other movement of the image going on. In your case I can think of at least 3 potential problems...

1) Tracking is turning off each time SharpCap tries to move the mount - that means the image will drift in RA while taking up the Altitude backlash, which could be sufficient to cause issues

2) Windy conditions with the planet being quite unstable - these movements could be picked up and assumed to be the response to the dec movement SharpCap is requesting

3) The cloud running through causing tracking to be lost - this is not helping, particularly during calibration, and may be leading to the blue crosses not staying near zero until the backlash is taken up.

Increasing the initial step size and movement speeds may help - that would mean that the movement of the mount will happen more quickly, leaving less time for the other issues to become a problem. Better conditions would also be nice - it's hard to tell from what we are seeing if it would work in good conditions, or if it would still fail even with no wind/cloud/etc.

It might be interesting to do a manual test of backlash in the two movement directions to see how much movement is required of the mount co-ordinates before the image starts moving when reversing from alt+ to alt- (and az+ to az-). There is no way to enter this info in SharpCap, but some mount handsets have options to allow backlash compensation amounts to be set... Not sure if those settings apply to ASCOM movements though.

cheers,

Robin

[MikeHuerto]

Hi Robin
Yeah, agree that conditions were hugely sub optimal for testing. But at least we know that the reestablish tracking code works, and that at least the pulses move the mount in Dec + by small and consistent increments. Dealing with the backlash is the next challenge. I will try again, and experiment with adjusting backlash compensation in the Synscann App on the PC, and increasing the initial step in the SC tool.

I can probably optimize the backlash compensation amount during the day, by focussing on a distant fixed object, and seeing how long it takes for the mount to move after a pulse is given, and then adjusting the backash compensation accordingly. This will probably help my tracking in general, with or without Feature Tracking. I´ve played with it before, but its worth revisiting.

Here´s the backlash compensation screen that I see on my PC. As you can see it allows for incremental increase of backlash compensation.

backlash comp offScreenshot 2024-02-07 210813.png (55.99 KiB) Viewed 284 times

I wIll retest as soon as clouds clear.

Best

Mike

[admin]

Hi Mike,

yes, a test during the day if you have a distant tree or similar to focus on might be a good idea - You can even put feature tracking into 'surface features' mode and see how the calibration goes with no tracking movement in the background to cause complications.

cheers,

Robin

[MikeHuerto]

Hi Robin

You willl probably laugh at this, but we´ve gone full circle. One of the reasons, I know SC FT disables tracking (or used to) is that in 2022, I did a series of tests using a synthetic jupiter. Basically a flashlight on a tripod 30 meters away from my Dobson. I turned off tracking and was able to calibrate using this static synthetic jupiter. After practicing this during the day several times, I tried it at night. I had things set-up such that I could calibrate with tracking off, on the synthetic jupiter at the end of my yard, then, switch tracking on in the Synscann App, and slew to jupiter (the real one in the sky), then activate guiding in SC FT . However, SC FT would still not guide the scope, the planet just kept drifting away, and I had to keep nudging it back into view with the Synscan App controls. This was very dissapointing, After reaching out to Skywatcher several times to fix this, I just gave up. I didnt think you would be able to fix it at your end. My mistake!

Here are a couple of screenshots of the calibatrion process from that night of 2022_09_03. You can see that I even painted a band and added a great red spot to the the torch, so it looked like jupiter!

CaptureGuide1-50-settings.JPG (206.48 KiB) Viewed 246 times

CaptureGuide1-50.JPG (203.68 KiB) Viewed 246 times

Also, attached is the Guiding Log from that period. I´m a bit lost in the log, but it looks like SC was sending guide instruction, but my guess is since tracking was off the pulses were not sufficent to keep the planet in frame. As I said, I had to keep nudging the mount to bring the planet back into view. You can see this in the screen video I made at the same time. The planet kept drifiting of to the upper right. You should be able to align the video´s time stamp with the guide logs.

Here is the link to the video: https://www.dropbox.com/scl/fi/pl0e4r5b ... txf4o&dl=0


Interesting, I note that I was using a mount speed of 1 to calibrate at the time. Perhaps if after calibrating on the synthetuc planet I would have raised the speed to 720 for the real jupiter, it might have worked - even with no tracking? What do you think.

Either way, since you have now fixed the tracking issue, perhaps, under good conditions, FT will work?

I will test more, we are having an unusually cloudy January in Valencia!

EDIT: QUESTION: Is it worth trying this again, now that SC FT reenables tracking? That is, calibrate on a fixed object, then activate tracking and slew to a real planet, and try and guide? Or does the calibration step need to include the tracking movement and drift etc. that occurs when calibrating with a real planet. If it is feasible, would I be able to save calibration settings permamently so that I can use on a different day, and skip the calibration step.

Best
Mike

[admin]

Hi Mike,

I don't think that calibration on a fixed object then moving to the target is going to work well - as you move to higher altitudes with your AltAz mount, the amount that the image moves sideways for a specific Az movement reduces (proportional to cosine of altitude) - however SharpCap doesn't take account of this, so the calibration needs to be done in the vicinity of the target for the scaling to be taken care of properly. In particular, if you calibrate near the horizon and then move to a high target, SharpCap will underestimate the motion needed in the AZ direction.

Another thing to note is that using a guiding speed of 1x is not going to work in your situation - this is because the tracking disables for the duration of the movement - in fact for longer than the movement because it takes a short period to re-enable it after the movement finishes. You will need to choose a fairly high rate (32x or higher I suspect) to keep the movement pulses short and therefore keep the time with tracking disabled to a minimum. In your testing with a synthetic Jupiter, a higher movement rate when guiding might have helped, since although each correction in Az would be too small, the code would keep trying to correct and might succeed - providing it reacts fast enough to keep the target from going off screen.

cheers,

Robin

[MikeHuerto]

Hi Robin,

don't think that calibration on a fixed object then moving to the target is going to work well -

Thanks for the explanation, that makes sense. But at least I think it demonstrates, that without tracking, on fixed object, the mechanics of the mount are sufficient for calibrations, and that backlash is perhaps not a major issue - since using the synethetic jupiter, the + and - points are in opposite sectors, and do not overlap. And also the the pulse guides in in Dec and RA are perpendicular. Is that a reasonbale interpretation?

Another thing to note is that using a guiding speed of 1x is not going to work in your situation

Agree- in my most recent tests, reported above, the best results were obtained at x 720. I assume this not only shortens the time that the mount is not tracking, but perhaps also acts like a form of Backlash compensation. Is that correct?

So, will try again when the clouds dissapear.

Best

Mie

[admin]

Hi Mike,

I'm not 100% sure about the fixed target implying backlash is not a problem... Both the calibration and the guiding will deal with backlash - the calibration keeps going until the mount starts moving and the guiding will repeat the movement if there is no response from the image, which will take up the backlash in the end. That all works well if there is no time pressure on making the adjustments - as with a fixed target or with a mount that manages tracking during movement better than yours). However, in your situation where the mount stops tracking, the amount of time taken for backlash to be taken up by the 'keep trying' approach could become an issue, hence the need to keep the adjustments fast.

Using faster speeds definitely helps reduce the 'not tracking' time, but at some point there may be an issue because the accuracy by which SharpCap can command *how long* the mount moves for is limited (how long does it take for the mount to respond to a move/stop command? Is it consistent? Is it delayed sometimes if SharpCap is querying the mount for the current position?). With very high movement speeds, the uncertainty in movement time may become an issue - it may be impossible to get an accurate movement of 0.05s at 720x, but possible to get a decently accurate 0.5s movement at 72x for instance.

cheers,

Robin

[MikeHuerto]

HI Robin
Thanks

Using faster speeds definitely helps reduce the 'not tracking' time, but at some point there may be an issue because the accuracy by which SharpCap can command *how long* the mount moves for is limited (how long does it take for the mount to respond to a move/stop command? Is it consistent? Is it delayed sometimes if SharpCap is querying the mount for the current position?). With very high movement speeds, the uncertainty in movement time may become an issue - it may be impossible to get an accurate movement of 0.05s at 720x, but possible to get a decently accurate 0.5s movement at 72x for instance.

Thanks for the clarification. I better understand the issue now. So, I think I will try and contact Skywatcher again - to see if they can prevent tracking being turned off by guide pulses in the AZ/Alt mode of the Synscann Pro App. Before I write, can you let me know if I am using the correct terminology, and could you provide a sample of the SharpCap code, that initiates a guide pulse, such that the SW programers can test? Feel free to message me directly if you dont want to post that here on the forum.

They have been responsive to some of my re-programing requesst on previous occasions. So if I persist, perhaps they can fix this

Best

Mike