Are you attempting to auto focus drive a camera lense on the camera body?
Can we get a warning in the status output for low star SNR with a recommendation to increase exposure time?
I'm still using the same motor I used with the adafruit motor hat. A smaller nema 14. It has plenty of torque at 12 volts. However, I have purchased a 12v nema 17 motor with 0.9°/step (400 step/rev) as an optional upgrade. I'll decide what to keep once I've used it a bit more.
As for attaching it you have options that you will have to work out what is best for your case.
Direct drive the focus shaft for zero backlash, but may not have the step resolution within the CFZ (critical focus zone)
Direct drive the fine focus knob. May introduce backlash, but increases step resolution.
Gear driven focus shaft or fine focus knob. Minimal added backlash, allows for gear reduction.
Belt driven. Use fiber reinforced belts with enough tension to avoid slack when changing directions. Belts also seem to slacken in the cold.
For hardware, there are shaft couplers and motor brackets. But truly the best asset is access to a 3d printer to produce custom gears, mounts and enclosure.
For connections I use DB9 sockets that can be screwed on.
I have a tip. Use the solved frame on the sky map to guide you as you push the scope closer to your target and desired rotation. Solving again after each movement.
Ubuntu has very recently released an official 64bit version for the Raspberry Pi 4. Today I attempted to install KStars, but unfortunately I was met without success. The PPA is not prepared for it yet (understandable), and I had issues building from source. Hopefully this will be made possible soon.
They were done at different times of day. But the instability was resolved after getting around to recompiling the test application. But you are saying that it should not have had an effect. Odd.
I was testing with what I stated as a different system, but was really a clone of the SD card to an external SSD used as a new boot drive. So the systems were virtually identical.
On the SD card, I updated everything, self compiled. Specifically I ran AstroPi3 script to update KStars. And did a Git Pull for Stellarsolver and ran both Linux setup scripts for the solver and test application.
Later this same day, I did the same for the SSD system clone. Except I skipped updating the test application.
I was not aware that the test application itself is integral to the operation of the internal solver in KStars as it appeared to be to be its own entity.
I found that since it was less up-to-date that the solver and KStars, the internal solver became unstable.
I was having a rather unstable experience today after updating Stellarsolver and KStars on one system, but not another also up-to-date system. While the internal solver in KStars would solve, it frequently crashed on the next image or on the same load and slew afterwards.
The only real difference between the stable and unstable system experiences was that on the unstable one I did not update the SolverTester application. Once I did, the internal solver in KStars became rock solid.
What's that about?
I removed a couple of the largest unnecessary indexes from my system hoping to get the total low enough for parallel loading into memory. I found it will work once. But after the first solve more ram in consumed and it states there is not enough on the next solve.
Disabling the inParallel option. 2020-10-23T23:33:37 Not enough RAM is available on this system for loading the index files you have in parallel 2020-10-23T23:33:37 Evaluating Installed RAM for inParallel Option. Total Size of Index files: 1.53425 GB, Installed RAM: 3.56387 GB, Free RAM: 1.51933 GB
free total used free shared buff/cache available Mem: 3736984 610880 1571604 70892 1554500 2912904 Swap: 3736976 0 3736976
It is a wonderful idea, certainly the next logical step ahead of refocus on temperature change. And an elevation criterion on its own would also be applicable to most astronomers, since a majority probably don't monitor temperatures.
The new solver really can solve fast! But I'm not exactly sure how fast as I did not see a time to solve stat in the output. That would be useful for determining optimal profile or custom settings.
I have managed to crash it on occasion with the simulator, but it's not very repeatable.
Thank you for bringing this new controller board to our attention and for all your efforts in creating the driver for it. I must say, this controller is far superior in every way to the adafruit motor hat. My motor can now run smoother, quicker and quieter with much greater torque.
I haven't had an opportunity to use it in the field yet, but I expect it will perform much more reliably.
Does this not calculate atmospheric refraction vs altitude in a linear relationship? Surely that is not the reality, as the atmosphere is more substantial at lower altitudes Especially below 30°.
Apologies for going off topic. But yes, I was referring to Canon CR2/CR3, and Nikon NEF. I image in native format because it's an easier workflow as it is compatible with darks and bias captured in camera without ekos. Currently I have to make a point of saving a FITS image to use later as a realignment frame.