I have written a new INDI driver, for the Waveshare Motor HAT. I've been using Radek Kaczorek's driver for the Adafruit Motor HAT for a while now, and while it works, I came across this Waveshare HAT which looks to be a bit better.
Advantages of the Waveshare Motor HAT versus the Adafruit Motor HAT:
- Real stepper driver, a Texas Instruments DRV8825
- Up to 1/32 microstepping, for super quiet and smooth focusing
- Adjustable current limiting
- Doesn't use i2c
- Can power the Pi and the stepper motor with a single 12V connection. No more 12V and 5V dual power to the Pi!
Even with 1/32 microstepping, I can get very reasonable speeds, since we're not using i2c, but are just triggering a single GPIO pin every time we want to step the motor. At 1/32 microstepping, I can get a full revolution of a 1.8 degree stepper motor in about half a second. 1/16 or 1/8 microstepping will, of course, be 2x and 4x faster, respectively.
From a programming standpoint, controlling the stepper is quite simple, and they include sample C code (unlike Adafruit which only includes Python code, which must be ported to C). My driver code was heavily inspired by (read: stolen from) Radek Kaczorek's original astroberry-amh driver.
Anyway, the code is here. If you do try it out, drop a note and let me know how it works out for you!
I very often get a crash in the autofocus routine. So last night I ran KStars in the VS debugger (KStars built locally from source). The crash was a stack overflow, in FITSData::trace(). The call stack was an endless list of FITSData::trace calling itself recursively. This happens quite often, unfortunately. This is on Win10 64-bit.
I was frustrated that it kept happening on the first clear night in months, so I did not get any other debugging info (no logs, etc.). Sorry about that. If the above is not enough of a hint to figure out the problem, I can get more data on the next clear night (who knows when).
Unless, of course, I can replicate the problem in daylight (possible, not tried). I will try to replicate it during the day to gather more debugging info, and to try to come up with an easily reproduceable test case.
I have similar guiding setup as you, and routinely get under 2' PA error. I have a ZWO 60mm f/4.6 guidescope (276mm focal length) and a QHY 5L-IIm guide camera (same as you), which I use for PA.
Just curious, but is that networkAccessible() check necessary? Could it be removed, and let the code fail normally if there's no network connection?
Yes I noticed the same thing. Sometimes that first correction after dithering is a big one, and it does affect the image.