ZOMG I can hardly believe it. I had noticed that Kevin recommends putting in a delay value to improve torque, but I thought "Jeez, this thing is slow enough already" and "It moves the knob just fine, no need to putz with that".

Well, imagine my surprise when I put in a value for that and the pulley started whirling around at speeds never before seen!

If there's backlash, it's less than a step, which means less than 0.03mm focus-tube linear movement by my measurements.

Think I probably got it now. Sigh. Thanks again for all the help. I'll let you know the next time I can see stars how it actually goes.


Thanks guys. [Gals. Folks. Whatever. I may live in Madison but I'm old. I'm still learning this stuff the hard way: Having an ambiguously-gendered kid will do that for you!]

OK, now I think I understand what's going on with the algorithm; it's actually pretty much like what I thought it would be. And given that my backlash is something like 90 steps, and the linear algorithm moves out, then in, several times that at least every time it does a run, you'd think it would Just Work. Maybe there's another source of ugly of which I'm unaware.

I should definitely increase the tolerance, thanks for that suggestion. It's painful to watch it achieve really good focus, then move away from that to establish the other side of the curve, and then never manage to find that point again, poor thing! I think what I might need to do is bring a micrometer and actually measure where the focusing tube at these points on the curve. I tried to keep track of it on the fly by doing all the arithmetic in my head but that worked about as well as you'd expect for a tired old fart in the dark and cold.

If only I could work on this any time I wanted! I've even thought about poking a pinhole in a piece of cardboard, hanging that on the fence with a light behind it, and pointing the scope out the window at it. Who knows, it could work. Of course now it's not just cloudy but RAINING, so it would have to be something waterproof...


What you are describing is the result of excessive backlash. The linear algorithm assumes there is none and that is what the step calculations are based on.

Wait, what? Did you not previously write:

Linear focus is the way to go. Nails perfect focus every time and inherently compensates for backlash.

One of these things is not like the other :-) Hy's answer up the stream also seems to indicate that the algorithm is designed to minimize the effects of backlash.

I mean, "excessive" I might certainly buy, since a step size of 100 makes a visible focuser tube displacement but can be nearly eaten by backlash.

So, as nearly as I can tell, the backlash is actually in the motor; there's really nothing I can do about that without replacing it. Although I recognize that geartrain backlash in a commercial motor seems unlikely compared to my laughably crude setup displaying, shall we say, idiosyncrasies...still, when I reverse direction the thing gronks for a couple seconds and only then does the shaft start to turn. A subsequent move in the same axis makes the gronking and turning simultaneous.

When I ordered the timing pulley they sent me one with a bore about triple the size of what I'd asked for; coming up with a crude bushing for that left me with a setup that certainly might be susceptible to backlash, although as I noted that doesn't appear to be happening. I've ordered another, we'll see what arrives in a week or two on the slow boat from China.


So to the extent that the last couple are directed at the OP, please read the thread. It becomes clear that the driver offers no backlash setting (at least not yet), and the very first sentence of my initial post was:

I put together an autofocuser from a stepper motor, timing belt and pulley, and a bracket to mount it on top of my refractor.

Still, I appreciate the attempt to help!

If the skies ever clear again I'm going to try with a smaller initial step value -- the smallest that will cause a visible change in the focus -- and a bigger multiplier, so that the initial move definitely takes out the backlash.

I also may change the driver a bit, my motor combined with microstepping makes 10 or even 100 steps completely invisible with Kevin's driver out of the box, so I put in a big multiplier to actually get the shaft to move.


So I tried a few combinations of initial step size and multiplier after updating to the latest KStars release. Mostly I went with 20 and 5. Sometimes Linear achieved good focus; other times it goofed. I neglected to run the logs (sorry) and didn't get a screenshot since I was using my iPad most of the night. But what often seemed to happen was that the software would go way outward to clear backlash, then progress inward for a while, leaving a nice half of a V until it had started climbing the other side. Back outward -- not quite as far -- then inward again. But the dots for the second round wouldn't overlay the original slope, rather they'd extend a sort of shelf out over the deeper part of the curve. I hypothesize that the software's idea of the X coordinate (focuser position) is just dramatically wrong, so its mechanics get messed up. The outward and initial inward moves are much larger than step size * multiplier, which is probably as intended.

And then sometimes it would nail it right at the bottom of the curve on the second or third try. Sometimes Iterative would work, or even Polynomial.


That sounds great. Unfortunately my Ekos doesn't provide "Out step multiple". I've got one that I built from source awhile back so I could try the Bahtinov focus metric. (Hopefully that's obviated by the autofocuser!) Like many folks, I'm pretty much a late adopter when it comes to Ekos updates, not wanting to risk a working system for a given bell or whistle. Probably worth it here. Is that in the latest release, or do I have to build from source, do you happen to know?

SEP star detection did not work at all well for me. I got much, much more reliable results with "Centroid".

> So for your case, that step should be larger than your backlash.

Just to be clear, "that step" means the initial step size * multiplier, right? So in your example I should ensure that my backlash is smaller than 5 * 20 = 100. Which I'm pretty sure it is, but only just barely.

I probably should have been taking better notes in "debug equipment" mode Friday night rather than "get it focused and acquire some data", but it was such a nice night... ;-}


Sorry, I didn't save a screenshot. But the successive points were piling up on each other, as if they'd slid past the center. I'm using an initial step size of 100, which is about the size of the backlash.

How do you get that display? I blush to say I've no idea how to elicit that tab in Ekos.


Hmm. I tried Linear last night and it was *less* successful than either iterative or polynomial! It wandered all over and failed to converge at all. Maybe I need to fiddle with the parameters. Any suggestions, given that I have right around 90 steps of BL? I just tested it again and it's quite consistent, in both directions: reversal soaks up just barely under 100 steps and after that it just trucks right along.


Hello all,

I put together an autofocuser from a stepper motor, timing belt and pulley, and a bracket to mount it on top of my refractor. I'm using the Waveshare Motor HAT on my Pi 4 running StellarMate OS (1.5.1, I think).

The trouble is that the system has about 100 steps' worth of backlash when it reverses, so the accounting can get all screwed up in the Focus Module. There is a Backlash text-entry box in the Mechanics tab of the Focus Module but it's disabled.

I'm using Kevin Ross's indi_wmh_focuser module, building from source so I can modify that if I need to set something in the driver itself. Just wondered if there was an easy fix before I dive into the code.



You guys., I tell ya. Thanks so much. Totally working now!


Thought it might be nice to analyze my PHD logs without copying them to another machine. I've gotten as far as the wxFormBuilder dependency for phdlogviewer, but when I try the build step that runs the UI generator I get a message about the fbp file being out of date and it fails. Not super-interested in debugging somebody else's dependencies for a tool I have no interest in using past just getting this thing to compile and run.

So: Anybody else have this running, or is there another tool you like to use to analyze log files?




Rick Wayne replied to the topic 'PHD2 and EKOS interaction' in the forum. 5 months ago

BTW you can exploit the wider FOV of your guide scope/camera to ease the polar alignment process -- just select the guidescope instead of the main imaging camera when you run the Assistant. It doesn't matter if the guider isn't perfectly collimated with the main scope, it can still do the math just fine. If you want, you can then rerun it at higher mag with the main scope, and the vector should be well within its FOV.


Sweet! Thanks! At least there's a workaround.