Thanks @jasem, I think you are right in your theory. Below are my findings that match yours. The question is when we can get this update (when losing guide star go to plate solving and restart guiding)?
C9.25 f/10, HEQ5, MyFocuserPro2, OAG, ASI174MC guide, ASI533MC Pro
@Mohamed: Thanks for that analysis. I believe you are correct that there is a bug here in the guider, your annotations help, and I have a theory about what is happening. Let me look into it a bit more, and I'll get back.
@Alessandro: I think it is changing guide stars on the fly, but I believe the problem is that it is not communicating that well to the guider.
In any event, it's best that I look more carefully into it without guessing and get back to you.
I had added a draft merge request that may fix this. invent.kde.org/education/kstars/-/merge_requests/507
This is pretty raw, and I can't test until skies clear up. Tomorrow night is possible,
but I'm not sure. Weather has been pretty marginal around here for a while.
@Mohamed (or others who are also capable): if you want to test, that would be great, but you need to be comfortable with git and compiling KStars.
It is not submitted, so you'd need to get it from my forked repo, doing something like this:
In a new directory, if you are good at getting code off of git repos, and want to test this, then
"git clone invent.kde.org/murveit/kstars.git
and go to the guider-fix15 branch (git checkout guider-fix15), and setup compilation using cmake and compile that and run the new KStars binary.
This code is at the current KStars HEAD plus my new changes.
You would just run SEP MultiStar guiding the way you've been doing.
The new code probably won't trigger unless the skies are poor, like the ones you've been testing with.
Here is your new code from the git yesterday. I'm not sure how I'd test, it but here's the log anyway: drive.google.com/file/d/1BAUAv4ItJ-mWO0Y...DT-/view?usp=sharing
All goes well until right at the end where indi closed the session. I had to go back to the stable version to finish it but I don't think it's the guider which caused the shutdown...
Oh, and MANY congratulations to whoever smoothed the guiding plot in the guide tab from those dreadful square waves:)
I recently looked into the original complaint (imaging shifted by the internal guider when clouds rolled in) and in fact found a bug that would cause this shift in some situations. I fixed that issue and it is now in the beta software. See the fix here: invent.kde.org/education/kstars/-/merge_requests/525
I was able to replicate the original issue, and after the fix I imaged with this a couple nights and clouds rolled in a few times, and with the fix the position was maintained. I also put a hat (literally) on the guide-scope for several different intervals, and all was good.
Please let me know if still see issues, and/or if you see improvement with the fix.
Fantastic news! I've also noticed the problems reported in this thread. I am looking forward to testing these fixes. Doesn't look like it will be any time soon, though. Nothing but clouds this time of year.
@Ron Clanton: Jasem seems to release a new version about every 2 months. The last one, 3.5.7, was released in mid-January so I'd expect that these changes would come out in 3.5.8 which would likely be released in mid-March.
I'm not sure that it would consume too much time in capture - or perhaps it's time some people would be willing to invest for the sake of properly framed images. To grab some hard numbers, I used StellarSolverTester from stellarsolver-2.2 to test a random capture from last night (Helix Nebua). Using either of "1-Default" or "4-SmallScaleSolving" profiles, stellarsolvertester reported taking 1.678s to solve the image, on my rpi4.
In my view, that's quite acceptable, being not much longer than a frame download (0.73s), and it's less than 1% of my typical exposure duration (240s). I expected that stellarsolver would find a solution quickly since it isn't running blind: it has a very good hint of where the center is expected to be, and probably knows what pixel scale and FoV size are. Additionally, this solving could be asynchronous: optimistically start the next exposure, solve in the background, if the target is appropriately aligned do nothing. If it's obviously wrong, abort the exposure (like a guiding constraint) and realign. If it doesn't solve ... consult a checkbox to decide whether to abort and realign, or ignore it and try again later.