I observe a very strange behavior when trying guiding (internal guider and PHD2) my SkyWatcher “Star Discovery AZ SynScan WiFi GoTo” mount. After wasting many nights I did some experiments at daytime with the CCD simulator. My setup for this test was:

• Mount: “Star Discovery AZ SynScan WiFi GoTo” (Alt-Az mount with a WiFi dongle)
• SynScan Pro app (latest version) on Android phone, in same WiFi network as the WiFi dongle of the mount
• Linux laptop with KStars/EKOS and INDI (latest versions), in same WiFi network as SynScan Pro app and mount
• INDI server runs on laptop, drivers are: indi_simulator_ccd (to simulate guiding camera) and indi_synscan_telescope (to control mount)

SynScan app and mount work fine together. I do alignment with the SynScan app before connecting the INDI mount driver. When connected to EKOS I can control the mount without problems:

• “Find telescope” in KStars sky map shows same position as the SynScan Pro app
• “GOTO” in KStars sky map moves mount as expected to new positions (position in SynScan app also gets updated)
• Tracking works as expected
• When taking photos with the CCD simulator I get pictures of a simulated sky
• When tracking is enabled the simulated stars hold position on the photos
• When tracking is disabled the simulated stars move on the photos (as expected)
• When moving mount with SynScan app in North, South, East and West the simulated stars move as expected
• When moving mount with the “Motion Control” tab of the indi_synscan_telescope driver the simulated stars move as expected

Everything fine so far. But when I try guiding the trouble begins. I slewed the mount to a good guiding star in the East at about 30° altitude. During calibration the guider makes movements in RA and DEC. The calibration diagram (and the photos of the simulated stars) show:

• RA forward pulses move star.
• RA reverse pulses move star in same direction as forward pulses. Step size is larger and growing.
• RA and DEC movements are not orthogonal.

I tried guiding with PHD2 and the internal guider, both show the same strange behavior. The symptoms match to the ones I saw at night with a real camera and real sky, so I think it is not caused by the CCD simulator.

The driver has a tab which allows to send guiding pulses in North, South, East and West directions. I tried a number of such guiding pulses in each direction and watched the effect on the photos:

• Pulsing to North moves the simulated guiding star in one direction
• Pulsing to South moves the star in the same direction like a pulse to North
• Pulsing to East moves the star to a direction which is not orthogonal to the North/South movements
• Pulsing to West moves in opposite direction as the East movement

It is clear that guiding can not work when North/South movements are not reversible. When this does not work with simulated sky it will also not work with real sky. I am sure this is an issue in the indi_synscan_telescope driver or in the SynScan app.

I also tried the indi_synscanlegacy_telescope driver. This driver has no tab to send guiding pulses and is not supported in PHD2. But the internal guider seems to support this driver (does it use the normal motion control for guiding?). With the legacy driver the internal guider works nicely: it has a perfect orthogonal calibration diagram and makes a stable guiding. Of course, on a real sky I will see the imperfections of my mount.

The SynScan App user’s manual (inter-static.skywatcher.com/downloads/sy...nual_en_20201008.pdf) states that a 3rd party software (INDI driver) has to connect to TCP port 11882. But the command set description (inter-static.skywatcher.com/downloads/sy...and_set_20210824.pdf) specifies port 11881. Both INDI driver work on port 11882 only. The command set description is about a complete different protocol than the one used by the INDI driver. I could not find a description of the protocol used by the INDI driver. Can it be that Sky-Watcher uses now a new protocol and does not bug fix the old one anymore?

Is there an INDI driver which uses the new communication protocol?
Is there something I need to setup in the indi_synscan_telescope driver to make it work?

In my post I stated that guiding worked with the indi_synscanlegacy_telescope driver. I can not reproduce this with a real camera. Likely I did something wrong during my first test. Maybe the guiding interface of the indi_simulator_ccd driver was used.

Asking the Sky-Watcher support regarding guiding interface of the SynScan App was not helpful.

Next days I will have a deeper look in the code of the indi_synscan_telescope driver.

Hey Ronald,

were you successful with the guiding? I have the same issue. Calibration via synscandriver does not move the Mount. Single pulse from indisettings Guide tab seems to work.

Regards,
Mat

Hi Mat,

Short answer: I did not have success and I gave it up.

Long answer:
I tried different INDI driver:

• indi_azgti_telescope gives many “Serial read error”. I am not sure anymore but I think basic alignment and goto did not work.
• indi_skywatcherAltAzMount which connects directly to the mount. With that driver basic alignment and goto did not work. Even a goto to the alignment point ended in a complete different direction. I got many “Mount Error: Motor not stopped” - maybe the protocol between driver and my mount does not fit.
• indi_synscan_telescope and indi_synscanlegacy_telescope. For both you still need the SynScan App because the driver sends commands to the app which controls the mount. I use the app since long and I like the app! After alignment with the app I can connect with the driver and control the mount. The slew buttons on the app make the fine adjustment easy. But the indi_synscanlegacy_telescope does not support guiding and with the indi_synscan_telescope the guiding pulses do strange things. My mount reacts on these guiding pulses very randomly.

I looked in the source code of the indi_synscan_telescope driver. It uses slew commands (like the slew buttons in the app) for guiding. A guiding command sends a slew to the app and after the guiding pulse length a timer stops the slew again. That sounds simple and straight forward. But for any reason the app does not execute such short slews correctly. Maybe it has something to reject keybounce or there are other timing restrictions in the app.

The indi_synscan_telescope driver uses the "SynScan Serial Communication Protocol" (inter-static.skywatcher.com/downloads/sy...otocol_version33.pdf) which does not support guiding pulses like other mount protocols. The app also supports the "SynScan App Protocol" (inter-static.skywatcher.com/downloads/sy...rotocol_20230902.pdf) which is based on ASCOM's ITelescopeV3 Interface (www.ascom-standards.org/Help/Developer/h...ace_ITelescopeV3.htm). This second protocol is prepared for guiding pulses but I do not know if guiding is implemented in the app (the app should set the CanPulseGuide property to True - I have not tested this). The SkyWatcher support team did not answer my questions. As far as I know there is no INDI driver using the SynScan App protocol. I could not find an evidence on the internet that an ASCOM driver can do guiding with the app and this mount.

On internet you can read that guiding is only possible with an equatorial mount. For my opinion this is a wrong doctrine! It is only easier with an equatorial mount and you will get field rotation with an Alt/AZ - but it is possible and viable. On an Alt/AZ mount the software must adjust both motors. But that should not be an issue for modern computers and microcontroler. Both motors rotate already all the time. For a guiding pulse the software just needs to do some coordinate transformation and adjust the motor speeds for the given time. That can't be so difficult. I am thinking about making my own driver or fixing the issues in the indi_skywatcherAltAzMount when I have more time.


Marry Xmas and Happy New Year,
Ronald

Hey Ronald,

Thank you for your detailed reply.

I used the direct version of the driver a lot with my AZGTI and in the end it worked somewhat and I was able to minimize the tracking drift (see here ). The guiding also went well in principle (both axes - also with PHD2), but I had the impression that I couldn't beat the rest of the tracking drift (it rocked up).

That's why I'm now testing the Synscan indi driver with the synscan app. There the tracking drift is still better (with three star alignment model) and I think it might be possible to use the guiding successfully, but as described the guiding pulses from the calibration don't seem to be transferred to the mount at all.

Regards,
Mat

Hey Ronald,

just for the record - i found the mistake (it was me ) - the train was wrong (guiding must of course be via Synscan driver) with this setting the internal guider works as he should via Synscan app with synscan driver (see screenshot)! Guiding with PHD2 worked as well.



The guiding was shaky, but perhaps it is possible to find good parameters...

Regards,Mat

Hello Mat,


Happy New Year!

Amazing! The diagram of the RA/DEC errors shows immediate reactions on guiding pulses. In my setup the errors continuously increase. It makes no difference if I enable or disable the guiding pulses in PHD2.

Do I understand right: you did this with

• indi_synscan_telescope driver,
• SynScan app and
• AZ-GTi mount?

If so I can still have hope and will continue to search the issue with my setup.

I have a different mount "Star Discovery AZ SynScan WiFi GoTo" (www.astroshop.de/azimutal-mit-goto/skywa...an-wifi-goto/p,57362). But it is from same manufacturer and also controlled by the SynScan app. I can not imagine that the app allows guiding for AZ-GTi and not for Star Discovery. I would not wonder when they use the same hard- and software in both mounts.

My guiding scope has a higher focal length of 250mm and my camera has a different sensor size. But my field of view (86' x 65') is not much smaller than yours (137' x 103'). In fact my setup should react more sensitive to guiding pulses.

The connection between my guiding scope and the mount was provisional and maybe not mechanical stiff enough. In the meantime I made that better. I also got a Bahtinov mask for better focusing my finder scope. I should repeat my tests.

My camera delivers Bayer pattern raw data. Maybe that confuses the calculation of the star center and makes the guiding more noisy. But what I see is a slow and large drift similar to what you see without guiding.


Regards,
Ronald

Hey Ronald,

- indi_synscan_telescope driver,
- SynScan app and
- AZ-GTi mount?

That is my exact setup! SynScan app was installed on Windows (not on a mobile device). A few times the driver was on "error" in the background and stopped working, took me a while to see it:



That little light turned red -> a simpel disconect/start/stop helped.

I hope it works for you too!

The use of the internal guider is perhaps easier for testing (no extra software).

>> I can not imagine that the app allows guiding for AZ-GTi and not for Star Discovery.

That's something I unfortunately don't know. But I could also imagine it.

What is you your optic train looking like?
Can you send a manual guide pulse? (that is something you can check indoors)




Regards,
Mat

Hello Mat,

Sorry for the late answer. You give me hope and I will do more experiments with my Star Discovery mount.

Last week I could prove that the issue is not caused by my guiding camera, PHD2 installation or mechanical setup. I used my optics with an equatorial mount and could successfully guide. Before that I was not fully sure if the camera is good enough for guiding (a Raspberry Pi HQ camera with my self made driver github.com/scriptorron/indi_pylibcamera). Attached is a picture of my equipment after a frosty observation night. The guiding scope is a Svbony with 190mm focal length, the main OTA is a Newtonian with 750mm focal length. Both have their own Pi with HQ camera. The Pi on the guiding scope operates the guiding camera, runs PHD2 and sends the guiding commands over WIFI to the Pi on the main OTA. The Pi on the main OTA runs KStars, operates the main camera and drives the mount. That setup sounds strange but it was the only which avoids sending camera pictures from one Pi to the other (that would be too slow). Controlled is everything using remote desktop (xrdp) from a Linux laptop in the same WIFI. I can do this from the couch and do not stay connected all the time.

As mentioned guiding works with the same optics, same cameras and same Pis on my equatorial mount but not on the StarDiscovery mount (www.astroshop.de/azimutal-mit-goto/skywa...an-wifi-goto/p,57362). The only differences on the StarDiscovery setup are:

• different mount (of corse),
• different mount driver (indi_synscan_telescope and SynScan app on Android, connect in same WIFI).

Testing indoors with a terrestrial target is a good idea. I will do that in the next days.

Regards,
Ronald

Hey Ronald,

yes, i think the next step is to check if the mount moves on guiding commands at all. But to be honest, even if the guiding works i have problems to find parameter to get calm guiding. Perhaps that are the limits of ALTAZ... or we have to find the right parameters

>>Attached is a picture of my equipment after a frosty observation night.
>>That setup sounds strange but

Very nice looking setup - my main camera is a Raspberry Pi sensor module too

So good luck with you tests!

Beste Grüße,
Mat