Hey all, I finally read through the whole thread. I got here from a google search and am having the same prob with my Sky-Watcher Virtuoso GTi 150p using this driver, wired with a usb to st4 cable. Firmware 3.40.

I'm trying to decide if it's worth spending significant energy on fixing this. I guess I have a few questions.

Has anyone made any progress in the last month?

Should I try to tcpdump / wireshark the traffic from Synscan Pro? Has anyone provided that yet?

Does the indi synscan driver work with these mounts? I realise it doesn't quite have the same features but I wonder if the tracking works.

Some people say versions of 1.9.x work. Should we find what version if first broke in and use the diff for clues?

I'm a software dev running kstars / ekos on linux and don't have many options when it comes to mount control.

Thanks for all your efforts!

+ No updates in the last month.
+ Not sure how useful this would be, but it doesn't hurt to have this information, it might indicate a much simpler approach is required. The dump itself will only be useful if decoded and annotated so know what each packet is doing.
+ Syncan requires a controller, so it won't work on direct WiFI connection AFAIK.

Hey Folks,

i'm glad there's still interest in this thread. I just wanted to check in for a moment. I will be fully involved again from autumn. right now it's just getting dark too late for me. I'm confident that we can still get this working and I'm really looking forward to further testing and trying things out.

Regards,
mat

Hey Folks,

yesterday and today was clear sky so i set the azgti up for the first time this year. I noticed something when I had the drift again (with the standard settings after 4 star plate solves).

Here are the settings:



I accidentally changed the !polling rate! (in Options) without changing any other tracking settings. And the drift changed speed! so i was able to slow down the drift with the polling rate. i approached zero drift at 100ms and was fascinated and left everything as is and collected frames for an hour. apart from a few gusts of wind, i was able to use almost everything.

Today i wanted to try it again, and it worked again. here are two screenshots:
The camera was again the Raspberry pi HQ cam with 12 sec per frame.





so today i have zero-drift at 100ms again for over 30 minutes now. At south east i had no drift with around 500ms... i dont understand it.

Michael, can you do me a favor and double check that? does it work for you too? (wait around 20 sec to settle after rate change)

Maybe it's just coincidence and i was lucky twice or maybe there were changes in the INDI driver over the summer?

Regards
Mat

Yesterday i tested again and I was again able to reduce the drift via polling. but yesterday the drift was so hard, that is was simply not enough. So i was able to make it a bit slower but not to stop it.

so i tried it out all evening and maybe Jasem can answer a short question here:

1. are you 100% sure, that alignment has nothing to do with tracking? because when a star X drifts and i slew away to an other star Y und make a platesolve with sync und go back to star X than the drift sometimes changes its direction? So it seems adding a point to the alignment can change the drift behaviour?

2. also another super short question. in site-management tab the TIME field, does only change at the start to the local time, right? it is not realtime every time i click on the site-management tab? because it only is set after the connect an than stands the whole evening on the set up start time. is that right?

Regards,
Mat

1. Alignment with nearest algorihtm should not have an effect since it simply returns the offset. If used with other algorithms, then it may have an effect due to the calculations involved. You can also try tracking without any alignment at all and it would still not work with any random star. i.e. it would start drifiting
2. Correct, the time is only for initial setup.

hey guys

thank you for your answer. That makes it easier for me, because i can do a one-time-plate-solve and can test around without a further alignment. today (indoors) i tested to listen to the traffic while the telescope was tracking sideral with synscan pro app from skywatcher.

i had traffic from and to the telescope alternating. Port 11880(steady) to 57681(incrementing, plus one with every packet)

But of course I don't understand what that means at all, I guess that doesn't help, does it?

Regards,
Mat

What tools are you using to snoop that?

The tool is named wire shark.

Greetings, again. I hope everyone is doing well.

Not to sidetrack us from the wireshark data, but I wanted to see if this question got answered.

<strong>A general question at line 1684 and below (resetTracking) in skywatcherAPIMount.cpp: why is AXIS_AZ and AXIS_ALT used inside the bracket instead of AXIS1 and AXIS2 in this instance (i.e. m_Controllers[AXIS_AZ].reset......... versus m_Controllers[AXIS1].reset).

Everywhere else in the code, AXIS1 and AXIS2 is used.</strong>

P.S. Mat, I had sent you a PM on Sept. 6th (was related to polling time testing, but beside the point now).

It makes no difference. Both have values 0 and 1 respectively.

I don't think that will lead to a solution because we simply don't know what the numbers mean. As Jasem said, we need a commented version.