Hey Folks,
I love my az-gti(x) in AZ mode and the concept of kstars/ekos in combination with an RPI4 is so cool, but at the moment I'm dealing with some problems.
I installed Katars/Ekos from the astroberry repository and everything connected perfect. Mount via wifi and asi120mini of course via USB. If the tracking works i can even guide with 1.3 to 1.8 RMS what I think is amazing in AZ.
But sometimes i have serious problems with the tracking that I just can't explain. I tried now for a week every button in the options, but no success. Its so frustrating.
If it happens for example, with no tracking the stars drift in the southwest to the right side (normal) - if I start the tracking (via the padlock or with a goto) the stars drift more to the left side. It seems that the speed is just too high and wrong. If I slew to another target, I may have the problem up/down or diagonal direction.

But I can’t understand why:
- if I use the synscan App on IOS tracking works really good, even with one star alignment
- date and time are ok
- 12 volt is ok (tested 2 different sources)
- location is fine (my city is in the database)
- platesolving runs perfect (solves every picture and syncs)
- gotos with inbuildt math are good

things that might need mentioning:
- AZ Mode!
- now newest az-gti firmware 3.40
- track factor in the options doesn’t seem to work (0.5 to 5 no difference in wrong drifting)
- polling makes no difference
- guide calibration fails (i think it simply cant overcome the wrong drift)
- track factor less than 0.4 causes a super crazy mount movement (described from a user on issuehunt )
- sometimesI can’t stop tracking via padlock symbol it just runs in the background (I can see the drift, but padlock is unchecked) so I have to press the abort-motion-button (that works every time).

And there are days/ moments it just works - with exact same setup. So it can be that I m tracking a target fine, changing the target (goto works!) an the new target i get the wrong drift.

my first question to go one step further:

If I have a perfect platesolve from a target and I start tracking, does the alignment have an influence on the chosen trackingrate?

And is there any other way to control tracking speed than track factor option?

Are there updates in the indi_skywatcherAltAzMount (Version 1.7)?

Are there any updates on that issuehunt topic (lots of my problems are described here too)

I would be grateful for any hint, because I'm really frustrated... if it runs, it is so cool!

Regards,
Mat


<strong>EDIT: A solution/workaround was found for the problem of strong drift. can be found in post:</strong>
end of thread

There is a long discussion on INDI Github issues about this very topic. I'm out of any fresh ideas on this subject. We need someone who is experienced with this or even perhaps SkyWatcher (doubt it) to step in and improve the situation.

We were working on Celestron AUX driver and Thomas used a sniffer to check the packets sent from the HC to to the mount. I think a similar approach might be useful. Perhaps use Wireshark to check packets exchanged between AZ-GTi and Synscan App? Maybe this will provide some insight on what needs to be done at the driver level.

Thank you for your reply and for supporting this software.

sad to hear - the weird thing is - one day it works for a target and than most of the time it simply tracks to fast / wrong... it's annoying, because AZ-GTI in AZ mode with KSTARS/EKOS is so fast to set up and fun to use.

Perhaps somebody else finds a solution. I will try a few more different routines - perhaps I am lucky and find a way to get it working. My next step is that i ordered a cable (FTDI USB to RJ12/6P6C Serial Cable for Sky Watcher AZ-GTI Mount ) to see if it makes a differnce not to use wifi. otherwise I would give up soon... it took me many clear nights

Regards
mat

Mat,
I also recently acquired the AZ-GTI mount as a lightweight travel setup and have the same problem. I use a Raspberry Pi 4B with Ubuntu Mate 22.04 64 bit and Kstars / Ekos 3.6.2 installed from the PPA.
I use an ASKAR 135 / ASI 585 as the imaging scope train and a RVO Horizon 32mm / ASI 120 mini as the guide train.
In AZ Mode the tracking is slightly too fast and it seems to struggle to get a decent image with an exposure of more than 15 / 20 seconds.
I've also tried to use it in EQ Mode and the result is similar, the tracking rate in RA is always West of where it should be.
Polar alignment in EQ Mode is done via the Ekos Alignment module and it works fine without issue.
Also in EQ Mode the guide calibration seems to work every time with the internal guider.
I was sure it was my particular mount that was at fault and the RA motor was running too fast or the encoder isn't quite correct.
Sky Watcher do say that it's not suitable for astrophotography, so I just assumed that the tracking rate is only as good as the tolerances on the components used to build it and some units will track better than others.

I do use the FTDI USB cable to control it, I've not tried WiFi yet.

I also noticed the track rate adjustment made little or no discernible difference

Next time I have a clear sky I'll try setting it tracking in Lunar or Solar rate to see if this may help.

Thanks

Alan

Hey Alan,

yesterday I tried to visualize the whole thing. Befor the screenshot i took about 15 platesolves in different areas and the goto was fine.

Here are two screenshots.



After about 10 attempts I got a valid calibration (really crazy looking one). Then I deactivated RA and DEC and started guiding. Now you can see the tracking drift very well in the guide plot (no guide pulses used). The normal direction (without tracking) would be down left in the plot - red arrow shoes what is happening with the tracking. The track factor <1 or >1 even with 5 has absolutly no impact on the tracking. The plot ist excat the same every time.



The second image was taken about 20 seconds after I stopped tracking via the padlock (it is unchecked). You can clearly see that the tracking is still active in the background as the star in the green box is still moving to the down left (what woult be right up in the plot ).

>>>I do use the FTDI USB cable to control it, I've not tried WiFi yet.

i hoped that coult fix it for me... but i will try anyway

For me the solution could be a button like "do what you do, just 20% slower" - it's a pity the track factor has absolutly no impact. It coult be the solution. i would love to short trail and error the right speed before imaging!

There must be a solution! I think we just haven't found it yet...

Regards,
Mat

Mat,

I've just checked my firmware version and it's the same as yours 3.40. It's currently in the Right Arm setup so I can use it either way AZ or EQ.

The weather is promising to be clear here on Friday night so I may get some testing done with the different track rates. I'll let you know the results if the weather behaves itself.

Thanks

Alan

hey
I tried again yesterday. The USB cable connection didn't change anything, but I will continue to use it to avoid connection problems. At the beginning of the evening the tracking went briefly, then it got bad again. Then at 12 p.m. suddenly a short period with good tracking (pulse guiding was active):



I now have a new suspicion: The power supply of both battery packs (12 V 2 A) and the power adapter (12V 1 A) should actually be sufficient (0.75 is required). Nevertheless, it could be that the batteries deliver less voltage when it is cold or perhaps for a exact tracking you need more power, so I will buy and test this evening with a 13.5V 3A power adapter.

I think the screenshot shows that the tracking can work... I will report the results!

Regards

No Luck...

12,2 with 3A
13.7 with 2,4A

No difference in tracking with INDI. Sometimes it works for a short time, than the hard drift starts agin.

Hello, Mat. Your symptoms sound 100% identical to mine. I'm in the same boat as you and have been struggling as well. As someone mentioned earlier, we've had a pretty extensive discussion about it here: github.com/indilib/indi/issues/1646. If you have verbose logging turned on, could you attempt a session and send me your log? I'd be interested in the calculated offsets during each tracking attempt. For privacy reasons, remove your location data from the log header.

Thank you for confirming that it isn't a power supply issue. I performed the same test as well, and we can rule that out.

Hey Michael,

glad (and sad) to hear somebody else is struggling.

My Setup is a AZ-GTI(x Version) with newest firmware 3.40 (normal, not right arm). The x-Version is in the inside the same as a normal AZ-GTI, but you can load a bit more and on both sides. My primary scope is a Sharpstar 76 APO with 3 kg.
But can definitely rule out weight problems, because yesterday I built an adapter (finder shoe to normal rail) and operated the mount the whole evening only with the guidescope (Svbony 30/120). The load was a maximum of 400 grams (with cables) yesterday... and I can definitely say that I don't have such an extreme drift with the synscan app (up to date iOS), even with the sharpstar mounted. So I m quite sure it has be a software issue. I also have no problems with the plate solving that others have mentioned, solves every time.

the only thing that which is still a mystery to me, Jasem mentioned on Github not to use inbuilt math. For me it's the only plugin that creates a working goto (and that works great gotos a mostly on point). So i still do not unterstand if alignment has actually an influence on the guide rate? Can i do one platesolve an start guiding? would it be the same as putting 10 platesolve points? (With the app even with a one-star-alignment the drift is relatively good.)

Logfile: Is my location only in the header or do i have to remove other lines?

Rendering Error in layout Message/Item: array_keys(): Argument #1 ($array) must be of type array, null given. Please enable debug mode for more information.

Please Log in or Create an account to join the conversation.