Hi,

I have the same mount AzGTI and essentially have/had the same issue, i.e DEC axis was not moving enough and I was getting the same error in the calibration step.
Note, I use EQMOD in this case, with EKOS and KStars, have guiding going to the mount, not ST4 cable, but have a serial port directly to the AZGTI.

Interestingly I did tear down the unit and adjust gear mesh for both DEC and RA axis. This I'm not 100% sure has made a huge difference, and I think that something else is at play here, and I will try to explain.
Hopefully Jasem might also validate what I'm seeing...

Before and after I adjusted mesh & re-assembled the unit, I performed a calibration and guiding session "test" indoors on a fixed "target", with the equipment fully loaded on the mount and tripod with the main & guide camera.
How do you do a Guide Calibration indoors? ... I hear you ask

Well from what I understand and can see in the INDI panel for EQMOD, when the unit is setup and in tracking mode the RA Tracking Rate is set at 15.04... and DEC at 0. This assumes you are aligned to the celestial pole exactly and only require RA rate tracking.
However what can be done for the indoors test is to set the RA rate to 0, and make sure the Track Mode is set to Custom.
Then slew your mount/scope pointing to a fairly distant wall (or adjust focus of guide scope&cam, if walls are closer), try find a dark surface or put up a piece of dark paper, and then try simulate a tiny star (i used a tiny pinprick of toothpaste lol, something bright to contrast on the dark surface). You may need to play with exposures and gain to get to the point where the star detection/tracking works.
With your fake star in focus on your guide cam, in the Guide Module, select it and start a calibration run, and watch the behaviour of you mount... and the deviations and pulses being applied.

My observations from the mechanical mesh adjustment:
Before - The DEC would not move very much in the forward step and then take very long in the reverse direction. This was surely an indication of backlash. I would have to set very high Calibration Pulses 3000-5000 to get it move as much as RA would. Then also whilst guiding had started the DEC would eventually drift out and then start to be very erratic, being slow to react to what ever motion was detected in the image noise or slight vibrations in the floor.
After - The DEC was much more well behaved. The calibration step seemed a bit more linear in the forward and reverse phase, and when guiding it stayed within the 2 arc/sec range on DEC, and would recover fairly well if I forced some fake vibration/movement through the floor, although this was not great ans was still slow...

Additionally I also tested using the Backlash settings for DEC, this can be enabled in the Indi Panel for EQMOD. But it can be a double edge sword. The amount of movement here has to be small enough to take up the slack/backlash of the mechanical movement. Any more and you start getting overshoots, and will play havoc with the guiding algorithm. Also it is hit and miss for when the mount is instructed to execute pulses of alternate directions when it thinks its near centre, sometimes making the guiding drift out significantly. I spent a few hours trying to fine tune the amount of backlash comp. having the mount cover open but fully connected to Kstars, and issuing forward and reverse commands to visually see the amount of backlash required in the gears.

Something else at play here...?
Finally, whilst I had the unit open, and I could also observe the movement of the motor & gears, I experimented with how the tracking rates and pulse guide rates behaved.
When the Tracking Rate is set to anything over 0, like the default Sideral ( 15.04 ) then guide pulses in reverse or forward seem to have a significant impact on the current tracking rate, i.e. a speeding up or slowing down proportional to the tracking rate (for a fixed pulse length)
When the Tracking Rate is set at 0 however, like when we are in normal celestial tracking at least for the DEC axis. Then the I could see the motor not moving at all for no input pulses. When pulses are issued, then movement of the motor just a handful of micro-steps, a minute amount and seemed to me would never result in any movement on the DEC axis. It seems to me that as the tracking rate was 0, the proportional movement applied to the motor on forward and reverse commands was just an decimal error amount or some small number.
I strongly suspect there is something wrong with how this unit works with EQMOD, or what commands are issued to the DEC motors when the Tracking Rate is 0. If the required movement command to the motor is some proportional value of the tracking rate, and that is zero, then we have a problem. Also the approach used for guiding in this case is based on pulse duration, and guiding then equates to commands like: speed up/slow down motor by X for Y milliseconds...

A few things I took from this:
1. This unit will always have backlash purely from the design using a cheap reduction gearbox off the basic dc motor, a set of gears off the gearbox then the worm gear onto the DEC axis. Adjusting the mesh may give you a little better reaction time when the motor is reversing direction, however we have to balance the tightness of the mesh with preventing binding and gear wear. Adjusting the mesh for gears is quite fiddly and the adjustment I did was so small, its hard to believe it made much of difference.
2. Increasing the number of Calibration Steps to use in the settings was needed to get a clear indication of the full movement and how much backlash was evident in the hardware. My Kstars/Ekos was defaulted to 2 or 3 steps, and would always fail calibration.
3. Enabling Backlash compensation, was not very fruitful and needs fine adjustment of the amount of motor movement, for little gain I believe.
4. Whilst using the indoors fake star test, i was expecting to essentially have no movement, but interestingly the guding algorithm was issuing correction commands. I put this down to noise and how it was calculating small pixel movement in the fake star image. There are some things to get right here, like making sure the fake star is not too big in terms of pixel and maps to what you would see in practice. This is a scope/cam resolution and binning configuration exercise. This will affect the amount of correction the algorithm thinks it needs to apply on each axis.
5. I believe there may be an issue in the mount/motor commands issued in relation to the 0 tracking rate. I think there is a minimum value in the Indi Panel somewhere, but again this is a pulse length, and I don't think will impact the dc motor rotation, because anything X 0 = 0! The motor is always instructed to rotate at some rate for a Y ms pulse.

Overall, I have resolved myself to testing my mechanical fixes when I get another full clear night, although I dont think much will have changed, and that I need to invest in a better mount.
I don't think this mount can deliver even consistent 1-2 arc/sec guiding and I would benefit from not wasting the scarce clear nights we have in the UK if I had a better mount.

I just hope Jasem and the wisdom of the pros in this forum might illuminate the situation, and maybe I'm just seeing things wrong, and there is some switch/fix that would make this mount a little better...

Thanks, and I hope I haven't bored everyone!

Maria

Background:
I have day job as a software engineer now for 15 years, build and fly model electric helicopters and am quite comfortable taking things apart.
Setup is AzGTI, RedCat 51/Tamron 600, Astro Essential guide scope, ZWO 294, ZWO 290 mini, RasberyPI 4, Astroberry, latest KStars etc...
Guide Rates and config were based on defaults other than changes made for my investigation...

Read More...