Hello,
I know this is experimental, so there is not much to expect for a quick solution.
The mount is roughly polar aligned, although I have some drift is not that bad.
When trying to calibrate, the calibration fails with angles not matching in RA. I have tried guiding rate, 1x, 4x, 8x, 16 to no avail. I have also changed the initial step from 0.5 to 0.4, 0.3, 0.2 with the same result.
The mount is at the latest firmware and with the latest ascom driver. The camera is a ZWO 174MM. I have also tried ST4 guiding but the result is the same.
I am attaching the log and a screen video capture, I hope this information helps.
regards,
Jorge
https://drive.google.com/file/d/10xzmy_ ... sp=sharing
Feature tracking on ZWO AM5 not working
Feature tracking on ZWO AM5 not working
- Attachments
-
- GuidingLog_2023-09-09T14_29_28-4268.log
- (53.36 KiB) Downloaded 147 times
- admin
- Site Admin
- Posts: 13473
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Feature tracking on ZWO AM5 not working
Hi Jorge,
could you please try SharpCap 4.1 for this feature - there have been a number of improvements to try to make the calibration more robust amount other things.
https://www.sharpcap.co.uk/downloads-4-1
Setting a larger minimum movement for calibration may also help (and that setting was sadly ignored in 4.0 due to a bug).
cheers,
Robin
could you please try SharpCap 4.1 for this feature - there have been a number of improvements to try to make the calibration more robust amount other things.
https://www.sharpcap.co.uk/downloads-4-1
Setting a larger minimum movement for calibration may also help (and that setting was sadly ignored in 4.0 due to a bug).
cheers,
Robin
Re: Feature tracking on ZWO AM5 not working
Thank you Robin for your reply.
I did try 4.1 and I think it got better. Thanks for that!!
Initially I tried with my Sky Watcher AZ-Gti which was also failing on calibration. It worked on the first try with standard parameter.
Then I switched to the AM5 again and only got it to work with 32X rate. Still with that, I was monitoring the movement and all the corrections were on the same direction (I assume thats correct because of the drift) but each correction was bigger in pixels than the other, is that normal?
I am attaching the log from that session.
regards,
Jorge
I did try 4.1 and I think it got better. Thanks for that!!
Initially I tried with my Sky Watcher AZ-Gti which was also failing on calibration. It worked on the first try with standard parameter.
Then I switched to the AM5 again and only got it to work with 32X rate. Still with that, I was monitoring the movement and all the corrections were on the same direction (I assume thats correct because of the drift) but each correction was bigger in pixels than the other, is that normal?
I am attaching the log from that session.
regards,
Jorge
- Attachments
-
- GuidingLog_2023-09-11T14_56_08-816.log
- (177.38 KiB) Downloaded 142 times
- admin
- Site Admin
- Posts: 13473
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Feature tracking on ZWO AM5 not working
Hi,
from the guiding section of the log at the end, it looks like SharpCap is sending increasingly large correction requests in Dec, but I don't think the mount is responding because the next time round the measured offset seems to have carried on growing and the next correction is even larger.
I think RA is probably working as I can see the RA (X axis) corrections are staying close to zero and changing sign frequently.
Now, when SharpCap is using a movement rate (not the pulse guiding rate), it asks the mount to move both axes at the same time - basically
StartMovingRA at RA Rate
StartMovingDec at Dec Rate
(wait as required)
then it stops whichever axis needs to stop first - maybe RA if the RA has a shorter move
(wait more as required)
now stop the other axis that needed the longer move
This should work, but I can easily imagine it as being the sort of thing developers of an ASCOM mount driver might not expect or test for. So maybe stopping the first axis actually incorrectly stops both in the ASCOM driver or maybe only one axis moving at a time is handled correctly?
I could try making a test version that moves the two axes sequentially to see if that helps - that would at least confirm if this suspicion is correct.
cheers,
Robin
from the guiding section of the log at the end, it looks like SharpCap is sending increasingly large correction requests in Dec, but I don't think the mount is responding because the next time round the measured offset seems to have carried on growing and the next correction is even larger.
I think RA is probably working as I can see the RA (X axis) corrections are staying close to zero and changing sign frequently.
Now, when SharpCap is using a movement rate (not the pulse guiding rate), it asks the mount to move both axes at the same time - basically
StartMovingRA at RA Rate
StartMovingDec at Dec Rate
(wait as required)
then it stops whichever axis needs to stop first - maybe RA if the RA has a shorter move
(wait more as required)
now stop the other axis that needed the longer move
This should work, but I can easily imagine it as being the sort of thing developers of an ASCOM mount driver might not expect or test for. So maybe stopping the first axis actually incorrectly stops both in the ASCOM driver or maybe only one axis moving at a time is handled correctly?
I could try making a test version that moves the two axes sequentially to see if that helps - that would at least confirm if this suspicion is correct.
cheers,
Robin