As I have described before - having a mount remove backlash is easy and I expect all would. Certainly my cge-pro does. But having a mount go to a specific ra/dec value at a specific time - quickly - involves timing and dead reckoning - at least for some mounts.
I’m not talking about the true ra/dec values - but the ra/dec values of the mount’s encoders, or where it thinks it is. This is easy to check by telling a mount to go to a particular ra/dec value - and after the slew you ask the mount where it thinks it is. If there is any error there - it will also be there in the sync/slew process used by sgp. And it has nothing to do with backlash - and repeated syncs/slews will not improve anything.
Unfortunately right now I can’t test my mount but I will when I can. Anyone can check this with a mount. Use its handcontroller or something and tell it to go to a specific ra/dec value - probably not too far from the equator so there is no dec. issue. Once it gets there read the ra/dec value where it is. Any error there will be a problem for sync/slew centering.
That is why I suggested adding log info for where the mount thinks it lands after a slew - and before the sync is applied.
If you do see an error - the next question is if you can adjust the target ra/dec value by correcting for that error. Again - this is NOT backlash. As long as the error is repeatable, sgp could measure it and correct for it - without doing a sync at all. This should work for all mount models and for mounts that don’t land exactly where they are told to go.
Right now this is a big problem for me - and I am not alone in having the mount fail to reach a given centering tolerance because it just gets stuck some distance away - and stops converging. My only recourse is to make the tolerance large.