Yes, I agree it is easier to play with the micro-stepping.
Taking into account the CFZs you have, 1/4 should fit to both Celestron and WO Z61 with a lot of margin and with backlash numbers < 255.
It seems there is several limitations for the maximum possible backlash value. First, the driver software restricts the number of steps you can set to 512. Second, the focuser firmware itself restricts the value to 255.
As a workaround, you have two possibilities:
-As in the case of the Celestron 9.25 the CFZ=220µm, you could reduce the micro-stepping to 1/8 or 1/4 instead of 1/32 and thus reduce the backlash value to set in INDI tabs by a factor 4 or 8.
- Otherwise, you could try to modify the lines 918 and 224 of the firmware 304 as following:
backlash_count = myfocuser.backlashsteps_in -> backlash_count = (myfocuser.backlashsteps_in * 10)
backlash_count = myfocuser.backlashsteps_out -> backlash_count = (myfocuser.backlashsteps_out * 10)
Doing that, the value set in INDI is multiplied by 10.
For my case, it's the focuser tube that slips.
For sure it depends on the focuser model. Mine is a rather simple (cheap) Kepler "Crayford style" model.
It is equipped with two knurled screws : one is for blocking, the other plays on the slippage tendency.
It looks a bit like a focuser slippage.
I meet sometimes with a similar behaviour that I fix by playing with the focuser tuning screws.
Have a look to this thread : www.indilib.org/forum/stellarmate/6494-i...ate-1-5-0.html#49752 .
Maybe it could help. In your case, you should probably have to replace ...ds3231 by ...ds1307
My feeling is that, generally speaking, 1.5/Raspbian is faster than 1.4.6/Ubuntu, at least on Rpi3B+. Also, the hotspot is established in less than one minute instead of two before.
I am working remotely using VNC. The client is a Linux Mint dell laptop connected to the Pi via its WIFI hotspot.
The buttons were clearly in an inactive state. Only one or two drivers were concerned in a randomly way.
Today, it works perfectly. I have disconnected and reconnected Ekos several times and I couldn't reproduce the problem. I updated this morning some drivers and libraries. Is it linked to that ?
Yesterday, after having installed on my RPi3B+ a new sd card with SM 1.5 in place of 1.4.6, I noticed that the system clock was no longer updated by the ds 3231 RTC. Thanks to Jasem, I could fix the problem.
I had to edit the /boot/config.txt file, go to # Hardware clock section and replace the existing line by "dtoverlay=i2c-rtc,ds3231" and then reboot. Since that, the system clock is updated when booting the Pi.
Jasem told me that this bug is now fixed in SM 1.5.
I found also that sometimes in Ekos/Kstars, some buttons in the INDI driver option tabs were inactive. In particular the save, load, default and purge ones, preventing me to save my new configuration. Today, I cannot reproduce this phenomena...
Apart from that, all seems to be working.
I had a similar problem one month ago trying to connect a joystick in bluetooth to a RPI3 running stellarmate.
Following an advice given by Jasem, I updated BlueZ:
sudo add-apt-repository ppa:mutlaqja/bluez
sudo apt-get -y dist-upgrade.
Since this, BT works reliably.
Maybe it could help