I'd be happy to look at your issue. I couldn't tell from your log, though, which guiding scheme you were using, and the log record much info.
Could you please:
Very sorry about the issues you're having, and I appreciate you sending in logs and raising the issue.
I did look through the log, and it looks like the guider is doing what it should, e.g. it measures error and sends out the appropriate pulses to counter the error.
Unfortunately, it looks like the computed pulses are having no effect at all on the mount, as if it was not even connected.
Yes, very similar to what you said "as a Guide Assistant run in PHD2, that is, with no corrections sent to the mount".
In fact if you view the phdlogview output to the file you sent me, you can see that.
I'm glad you figured out at least a workaround for your issue.
What do you mean by "rotated the saddle"? Can you add a picture?
Do you literally mean that just the piece of metal that clamps the OTA onto the mount was rotated,
but the mount itself and OTA itself are in the same position (not rotated)?
Also, why did you "rotate the saddle"?
Sorry Magnus, not much to say.
I assume you're using PHD2 through KStars/Indi, so they're using the same Indi mount drivers.
I will note that as I understand it, the PHD2 folks recommend calibrating once and leaving it, e.g. not recalibrating for months, unless you change the guiding imaging setup (e.g. rotate the guide camera, remove it, or something like that). I have taken that to heart, and I personally don't calibrate often either. As you probably know, the internal guider has options to keep use the calibration--e.g. do it once where it works nicely, e.g. near the meridian and the equator, and keep that calibration for a long while instead of recalibrating on every slew.
The calibration scheme simply pulses the mount the amount specified, e.g. 1000ms, every step it takes, without regard for the guide rate, until it sees enough movement. Is it possible you have a lot of backlash, and somehow PHD2 compensates for that better than Ekos? I guess you can measure that with the PHD2 guiding assistant.
Do you have these issues in both RA and DEC?
BTW, now that I think of it, it's also possible that the issue is star detection, not mount movement (e.g. the issue could be improved with improved stellarsolver parameters for guiding). That would be obvious in a log with debugging enabled for guide and fits.
There is certainly significant noise is these estimates due to many of the different components (hardware and software) in the system. I would not expect (and do not experience myself) exactly the same numbers when repeating measurements like that. I do tend to get similar results, e.g. within an arc-minute or so.
Slightly off topic, but my advice would be, assuming you're talking about Raspberry Pi 4, to skip the SD Card altogether and use a SSD instead. (OK, then you might ask how to clone an SSD, but I digress).
Starting with KStars 3.5.2, polar alignment works in any part of the sky. You just need a stretch of clear sky.
For details, please see this post:
So, for example, you could slew to just west of the Meridian a bit above Polaris, and set it to slew west at 30-degrees per slew. Start high enough so 2 slews of 30-degrees West in DEC would stay above the trees. Then click Start. If for some reason you didn't have those 60-degrees of unobstructed sky, you could set it to slew 20-degrees instead, and it would likely work fine.
The sky parameter is a byproduct of SEP star extraction. Take a look at the Background and Background Map sections for details: sextractor.readthedocs.io/en/latest/Background.html It is the all-sky RMS background (whole image noise standard deviation).
I was thinking of converting it to an SQM measure, but I believe I'd need to know camera gain, and probably need darks and bias images. I decided to keep it simple, but am open to suggested measures.
As a relative matter (e.g. how the sky is improving or degrading throughout the night) the current measure is probably fine. A similar measure from that respect (relative sky conditions) is # stars detected in the main and guide cameras, and guide star SNR.
I guess my pic is misleading. I've only traveled a few times where I've needed batteries.
I built a couple lead-acid marine-battery-based boxes to power my equipment back in 2019, but only used them a couple times.
I'd recommend you start a new thread on the battery topic.
I haven't used the legacy polar alignment. If it works for you, by all means use that. I was just suggesting that you try the recently developed polar alignment scheme, since you seem to be having issues polar aligning.
If you can find an arc in the sky, where you pick a starting point, then just move in declination for, say, 40-degrees, and that entire arc is visible through your window, then the recent scheme should work, whether or not you can view the northern celestial pole.
Why not try the standard polar alignment, as opposed to the legacy one? Assuming your Astroberry is using KStars 3.5.2 or later, the polar alignment scheme does not need a view of the pole anymore. In theory you can point anywhere, though I'd guess it's best to start on one side of the Meridian, and slew down from that side. E.g. use KStars to slew the mount to just West of the Meridian, and then set up polar alignment to go West in two 30-degrees slews. If you don't have 60-degrees of view, from there then reduce it to two 20-degree slews, or whatever. I'll be that will work for you.
I did have an email conversation with Rob--he's aware of the issue.
I was just letting folks know.
It seems like EKos is sending the max dimension to StellarSolver, so it's somewhere between Ekos and StellarSolver and ASTAP.
Interestingly, ASTAP seemed 5-10% quicker without scale! Was I just lucky? I have disabled scale.
@han.k Also, FWIW, it might be interesting for ASTAP (or all the StellarSolver solvers) to have a "if the search fails, try again without scale/position with timeout" sort of backup possibility. This could be expanded to other parameters as well, if there are more. Perhaps enabled with some flag.
@han.k Finally, as I'm on the topic, does ASTAP have a star-detection interface? StellarSolver has the possibility of using ASTAP to solve location, but perhaps it could also be an alternative star detector as well?