autoguide with synscan AZ

[admin]

Hi,

I have fixed a few small bugs in feature tracking in the latest build, but I don't think they are anything to do with this particular issue. There is some additional logging now (to a separate guiding log), but again I'm not sure that this will help - in the case of this problem the mount just seems to have a mind of its own and isn't doing what it is being asked to do!

Out of interest - have you had any success guiding this mount with software like PHD? If PHD works then at least I know it's possible. If PHD has problems then I think a solution would be off the table for the moment.

cheers,

Robin

[balliamo1]

Unfortunaltely I have not found any way of guiding the Skywatcher Dob goto mount with AZ synscan so far.
PHD did not pass the test either, but all the apps require the mount to be EQ.

[admin]

Do you have a camera with an ST4 output port (QHY/ZWO/Altair)? If you have and your mount has a guiding port it may be worth trying that option instead - select 'On Camera ST4' from the list of mounts in the hardware options screen.

cheers,

Robin

[balliamo1]

The Skywatcher 14" does not have an autoguide port, only the 18" Dob will support that.
I never tried to connect St4 cable to the serial port of the synscan, since the electronics might be permanently damaged.
I will keep using the AZ mount unguided with short exposures, I am having pretty good results with QHYCmos.

[LaCasaCorp]

I have the same error with my skywatcher AZEQ5 (in equatorial configuration, controlled directly from eqmod with the USB cable). I use the autoguider port very often, and behaves correctly, but I receive the same error when trying to use the feature tracking (and, if I recall, the graph looks almost identical to the one in this thread)... I didn't saved screenshot, unfortunately

[admin]

If you see the error again, please look in the folder

Code: Select all

C:\Users\<your user name>\AppData\Local\SharpCap\logs

for the GuidingLog file that corresponds to the problem (latest build creates these guiding log files - please make sure you are using that). Send me the log file and the screenshot and I can see if there is anything in it that explains the problem.

I have had success with the latest builds with an EQ6

cheers,

Robin

[MikeHuerto]

Any update about this issue?
I am wondering if this is a synscan driver problem, or something else.

Yes, it is a Synscan issue. The Synscan app does not respond to pulse commands in the reverse direction.

I've been communicating with the Skywatcher/SynScan folks in the UK trying to solve a similar problem. To cut a long story short, here's their latest email

SynScan app does respond to ASCOM's PulseGuide command in both RA and Dec direction. It's just that SynScan app applies some filtering: when app receives PulseGuide command on an axis AND that axis is already moving, app ensures that PulseGuide will not reverse the original direction. App will only speed up, slow down, or stop the axis.

So this would explain why I and others have not been able to complete the calibration steps in SharpCap and PHD (and why I cannot auto guide in Firecapture).

A possible solution might be to provide an option to include a STOP command before each RA/DEC calibration command? Is this doable Robin?

PS.I have asked them twice now if they can update the Synscan Software to accommodate reverse pulse commands. It does not appear to be a mechanical issue when I use the Synscan app to nudge the mount in any direction during planetary capture?

[admin]

Hi,

I wonder if it would be enough to set the guide rate (if possible ) to less than sidereal rate. If it was set to say 0.75x sidereal then a reverse RA pulse guide would just slow the axis down to 0.25x sidereal, which might bypass the filter.

Any chance you can run an ASCOM conformance check on your ASCOM driver, which would reveal if it has that capability - the key lines in the output would be

Code: Select all

15:17:52.278 CanSetGuideRates                  OK       True

and

Code: Select all

15:18:01.322 GuideRateDeclination Read         OK       0.00
15:18:01.331 GuideRateDeclination Write        OK       Can write Declination Guide Rate OK
15:18:01.364 GuideRateRightAscension Read      OK       0.00
15:18:01.392 GuideRateRightAscension Write     OK       Can set RightAscension Guide OK

If both of those blocks look OK, then maybe that would be a workable approach.

cheers,

Robin

[MikeHuerto]

Hi Robin

All looks good. Here is summary of the relevant blocks. I´ve also attached the complete log in case you see anything there.

I assume this means that you would program in the reduced sidereal rate, or is just about me playing with the existing guiding rate option. I did try various speed settings, though can't recall which rates exactly. I´d be happy to test a pre-beta update of this. This would be a game changer for me and many ASCOM synscan app driver users!

Best

Mike

10:19:15.653 CanFindHome OK True
10:19:15.662 CanPark OK True
10:19:15.669 CanPulseGuide OK True
10:19:15.676 CanSetDeclinationRate OK True
10:19:15.685 CanSetGuideRates OK True

10:19:24.975 GuideRateDeclination Read OK 0.00
10:19:24.986 GuideRateDeclination Write OK Can write Declination Guide Rate OK
10:19:25.037 GuideRateRightAscension Read OK 0.00
10:19:25.049 GuideRateRightAscension Write OK Can set RightAscension Guide OK

[admin]

Hi,

unless there is a setting in your ASCOM driver setup window to set the pulse guide rates then this would be something I would need to add to SharpCap - a way to specify what rate to use for pulse guiding operations (probably in the settings). It might be best to test first - I will try to think of a quick and easy way to allow you to set the rate to see if it solves the problem.

cheers,

Robin