It appears the forum submit button is working on my end again (yay!).

Mat - that is great news. From the personal messages and images you sent over, it appears you are getting consistent results by performing an alignment with sync points around the target. As mentioned in our correspondence via PMs, I am currently unable to test this as my plate solve feature is not working correctly. I've posted the instructions to the simpler driver below.

Jasem - Platesolving seems to be broken on my end. It used to work very well, but it doesn't anymore. I have the same symptoms as these folks here . In addition, "slew-to-target" will slew once, sync, pretend to slew again, sync, pretend to slew again, sync... .etc. I have confirmed that manual slewing and goto works, so it's something with this particular platesolve function. Is there a directory of previous indi versions which I can revert to?


P.S. for others:
I've reverted to a previous version of the az-gti driver with partial changes from a comment I made above in regard to tracking. If you remember, this is the version where pretty much only the PID terms could be set. What I've done:
-reverted back to prior version.
-added harcoded deadband of -4 microstep to 4 microsteps for the error. That is, the frequency and track rate will stay the same if the error falls with the deadzone.
-Changed PID track rate constraints of -50 to 50 to 1 to 100. This will allow a frequency range of 16,000,000 hz to 16,000 hz.

Here is the Branch .Essentially, copy and paste (replace) the skywatcherAPIMount.cpp to your local indi/drivers/telescope directory and re-build without grabbing the indi official repository source files. make sure you replace the files and don't hit "skip".

For those interested in helping, test this with the alignment procedure Mat has discussed above.

First many thanks to Michael for all his input via PM, while posting in the forum didn t work.

Since I had free sky for a short time yesterday, I put the "circle procedure" to the test and it worked again!
First the telescope drift was there on the target and i minimized it with many randomly placed sync points (17) around the target so that the drift almost completely disappeared again.

The target was NGC7479 and i made 220 frames with 14 seconds exposure. You couldn't see the galaxy on the individual 14 sec frames (i m located in a city and only use the pi-cam), but after stacking it became slowly visible - amazing.



195 frames (46 min) used
Raspberry PI HQ cam
Scope 420/76
(I used kstars 3.6.0 and the actual INDI from GITHUB.)

But I think you have to mention that the azgti in "alt az unguided" also has its hardware limits. I couldn't use every frame and sometimes it's inaccurate or a frame is not good. But that was it with the original synscan app from Skywatcher too - I would say that the level of the original app has been nearly reached, what is amazing, because ekos is so much easier and more convenient to use than the app (and has platesolver ).

i will keep you updated!

Regards,
Mat

Attachements:
a standard singleframe
a "lucky" test frame 45 sek (that realy works not everytime with the az-gti )

Good news. I was able to perform the alignment procedure Mat outlined above with excellent results on the first time. My target was Polaris, and I achieved multiple 45 second exposures similar to the one attached.

I normally use the Ubuntu version of Kstars on the interface end ( i.e. non-stellarmate end) however due to the recent upgrade to Kstars 3.6.6, platesolving is pretty much useless. I switched over to windows and ran Kstars 3.6.3 (which had a few performance issues, i.e. super slow and froze repeatedly) but it was able to sync multiple times unlike with 3.6.6 allowing me to perform the alignment procedure.

Clouds set in, and I could image only one target. I'm pretty confident in the process. I'll attempt again on a clear sky.

I'm surprised that you have problems with plate solving in KStars 3.6.6 on Ubuntu.
I follow this thread ~ since beginning but since 4 weeks I'm using a polar wedge and run AZ-GTi in EQ-Mode.
Plate Solving works now perfect and I'm completly excited with AZ-GTi in EQ-Mode.
But perhaps EQ-Mode is the reason why Plate Solvings works so good now.

Hi Peter,

thank you for your input. I'm glad to hear that the wedge helped you succeed. I have also read many positive experiences with the AZ-GTI with wedge. But AZ mode really has a lot of advantages (set up in under 5 minutes, no polaris needed), so the point of the thread was to get to the bottom of these problems.

I've had really great sessions over the last three days. It really works every time to slow down the drift using the circle procedure. It remains to be seen how much this can be optimized (how to set the sync points perfectly). It's very cloudy right now and over the last few days I've only been able to collect frames bit by bit between the clouds, but with the new method the imaging starts for me:

This was a test on M16:
700 frames a 14 sec (over 4 days between the clouds )
Raspberry PI HQ Camera
76/418 Scope
Balcony in a midsized City



And it's clear to me that with my skills (absolute beginner) and the Raspberry cam, that's not the top edge of the possible, but without the drift I can now take pictures, which I think is really great!

Feedback from other testers is still welcome!
Regards,
Mat

Hey Folks,

I've been testing again for a few days now and would like to mark this topic as [solved/workaround]. I changed the title and I added a reference to the end of the thread in the opening post.

Thanks for all the help and input over the last month and thanks especially to michael and jasem.

Here is a short summary of what ended up being the best approach for me:

AZ-GTI altazimuth mode (in my case the x-version)
Motor firmware 3.40
Kstars 3.6.0/ INDI from github
Cam for platesolving: ASI 120MM Mini (on 120/3 Scope)
Imaging: Raspberry Pi HQ Cam (on 418/76)

1. Pointing scope (0-Level) roughly in direction of the target
2. Boot pi
3. Connect to mount
4. Change mount-settings to:

- Options-tab: 100ms
- (Options-tab: disable Logging )
- Alignment-tab: Change to inbuilt Math / Press Reload OK
- Sitemanagement-tab: check time
- Tracking-tab: All standard (but Deadzone = 4 and Offsets all 0)

KSTARS solver setting "use scale"

5. Slew upwards a bit with "mount control"
6. Solve with option (sync) and slew with goto near the target (may take a few steps)
7. On or near the target: in ekos mount tab "tracking off" - and "clear model"

6. Solve first time with option (sync) - goto target and solve again
7. Check drift. if its there - start procedure:

- slew with goto to a random point near the target and solve with option sync
- slew with goto back to the target and check drift
- repeat in a kind of a circle around the target

The drift will disappear, but sometimes it only needs 3 sync-points and sometimes (much) more. I also set a sync point every now and then or clear the model after an hour or two.

It should be noted that the drift of course never disappears completely, but in my opinion it can be reduced to the level of the original synscan app. But the extreme drift in which the target leaves the FOV in a minute can definitely be slowed down to make images with an exposure of 12 seconds or longer possible. The rest is probably hardware, field rotation, loading, leveling and all the other tweaks that are recommended in the many threads about the az-gti.

Attached here is a picture from my bright city balcony from the last three days. It really only takes 5 minutes from switching it on to getting started, which is just a lot of fun for me... next stop - darker place and clear sky!

M51 - 840 frames with 11 sec (2h 30 min in total) / Raspberry Pi HQ Cam / Scope 418/76



Further feedback from your experiences (and perhaps optimization of the procedure) is of course always welcome!

Regards,
Mat

This is really great, thanks!

Do you suspect there are still inefficiencies or a bug in indi related to this? This is fantastic but do you feel it's a workaround for an actual problem or no?

You are right, that is a good question. To be honest, I don't have the experience to say for sure. Perhaps the model with this mount just works that way in AZ mode.
In any case, it works differently than synscan, where even a few distant points work well. However, thanks to platesolve, the above method is much more convenient and faster than the synscan app.

Edit - just for the record:
I found out that there is a driver for ekos called "Synscan" - its kind of a remote controll for a running Synscan App (e.g. on a Windows PC). This turned out to be the best combination for me. Platesolve and orientation via Kstars / Ekos and the tracking engine of the original Synscan app is used in the background. In my opinion, with a simple 3 star alignment it delivers the best performance in this way.

Regards