The focused worked much better last night. I now get the expected V / curve during auto focus. I could repeatably move focus away from the focus point and back to the same step number and things were in sharp focus. I still need to tune the parameters for the auto focus algorithm itself. It was never able get it to automatically choose the focus point (though I was able to choose it myself based on the data from the auto focus process). I’m using the linear focus algorithm. Once it finishes the first pass, it then appears to try to take multiple readings at the same steps right around the focus point. However my seeing must be varying enough that it couldn’t get consistent enough readings without moving the focuser and would eventually error out. I adjusted the tolerance % without success, though I’m not sure that’s the right parameter. I didn’t spend a lot of time as I wanted to get started imaging, so I just chose the best focus point and moved on.
For myself, auto selecting a single focus point has never been reliable. I either need to manually select a single point, or use full field mode. Full field mode is the method I use now. You can even tell it to limit itself to the central part of the image, if you prefer.
I use the polynomial focus method. It seems to work well enough. I never tried the linear. I might give that a try. Some people say it works better.
I have always used Full Field mode. Set tolerance to 5%. Much depends on the initial step size with the linear focuser. If that is too large, it may miss the minimum. But once established for a specific focuser and telescope, it will hit the optimal focus every time.
If you have NO backlash, polynomial may be better, because step size will continuously decrease while converging upon the minimum. But if there is ANY backlash in your system, linear will be more consistent and reliable IME.
Atlas Pro AZ-EQ, ASI1600MM-Pro, ASI120MM-S, ES102ED, WO-Z61, Nikon D3300, ASI-EFW, ZWO LRGB,Ha,O3,S2 filter set
Thanks for the advice everybody. Full Field mode worked *great* last night! It was bang on and worked the first time. Linear worked just the way that I would expect it to. I even tried polynomial mode and it picked the same focus point as Linear, though it didn't seem like it took enough data points to come to that conclusion. I'll have to play around with it more before I put my trust in it.
Woot! I'm really happy with how things are working. I'll still probably switch to the 5:1 stepper at some point, but I'm not in a hurry.
Everything has been working well over a few nights of imaging with one exception. I had an (apparently) unrelated issue where I had Kstars crash on me a couple of times. Once that happens while the focuser is not at zero, I have to manually move focus back to the zero position before starting indi / Ekos again. If I don't, the focuser is at the previous focus position (say 78) but the driver now thinks its at zero and there's no way to move past the zero point. Does anybody know of any way around this? I'm not sure there is a good solution. The best I can see would be to always save the focus position and assume it hasn't moved (while also moving to zero on a clean shutdown). Support for going below zero would also help manually get out of this situation if there was then a "set as zero" option to go with it.
I was hoping the stepper driver hardware might have support for stall detection so we could use something like 3d printers use for senseless homing, but it doesn't look like it does. I suppose another option would be an actual end stop / zero switch, but that would be a good bit of extra work / hardware.
Hi Kevin, I'm glad you found my
driver inspiring and base for your project. Great work!
I have just purchased Waveshare motor HAT and given it a try with
, which is much more advanced focuser driver than Astroberry AMH.
It supports DRV8834 and A4988 stepper controllers, supports custom GPIO pins, uses kernel native libgpiod instead of bcm2835 or wiringpi, remembers focuser position between runs and provides focuser temperature compensation with DS18B20 sensor.
It uses typical DIR, STEP, SLEEP, M0, M1, M2 pins connected to Raspberry GPIO so I tested it with Waveshare motor HAT. Well, it works but I faced some issues with microstepping and sleeping a motor.
As you probably have much more experience with this device, I've got two questions:
1) It looks like the device does not handle software microstepping without touching hardware i.e. dip-switches. Am I right saying that you cannot control microstepping with software only?
2) Another issue is related to sleeping a stepper motor. Apparently hardware designers did not wired SLEEP pin of DRV8825 to any of Raspberry GPIO. Does ENABLE pin cut off step motor power circuit so it does not get hot?
| Orion CT8 | Askar FRA 400 | NEQ6 (hypermod) | Atik 460EX | ASI 1600 | ASI 120MM | Atik EFW2
Truth be known, I didn't know Astroberry DIY focus driver existed when I wrote this, I only knew about the AMH driver. I probably would have used yours had I known about it.
To answer your questions:
1. Correct, they haven't exposed the microstepping select pins to the GPIO pins. They were nice enough, though, to provide solder pads that can be jumpered so that you can select the desired microstepping via GPIO. Not sure why it isn't enabled without doing some soldering, though.
2. Yes, the ENABLE pin will turn off the motor, cutting all power to it, keeping it from getting hot. That's what I do in my driver, I shut down the motor as soon as the move is complete, so the motor doesn't get hot, and to save power, if you're running off battery power.
For some reason, the sleep pin is tied directly to 5V, and the Waveshare manual states: " Should keep High, otherwise chip will enter sleep mode, and module cannot work properly."