Hy, I'm very sorry I was working and haven't seen your msg until now. Reading on I discovered you found parameters to replicate it anyway Super!

Hello Hy,

great news from you With the checkbox removed it works for me - at least with the simulator Looks like the solver is a little slower without the checkbox, but not significantly. With 2x2 binning it still is under 10s - that should work for me. And: During refresh the internal solver is much faster - under 1s. But i do not know what heppens in "real life" when i really adjust my mount and get blurred, shaky images. Of course we have clouds here for the next days... But there are silver linings.....

Of course it would be nice if the problem can be fixed in the code. Maybe the following line of code is the problem:

parameters.search_radius = parameters.search_radius * 2;

This doubles the search radius. Maybe the scale has to be doubled too? Regardless of this: I do not understand why the search radius has to be doubled at all. By default it is quite large - much larger than needed for adjustments done by the mount screws during polar alignment. I think the default search radius is set to 30°, doubled is 60° - this is mechanically not needed. I know no mount that can be adjusted more than a few degrees - and the initial position is already know from the third image captured during PA before the refresh cycles start.

And still an issue if running on a slow cpu and/or with a slow solver: The timeout fixed to 10s. This really should be a tunable setting in the options. Even if more than 10s is quite slow and makes the refresh cycles difficult. Should be to the user if he/she/it has enough patience If really needed for some reason the factor that currently doubles the search radius is another candidate for user configurable settings. Should be not difficult to add those settings?

But again: Thank you very much for your support. Looks like this very nice feature can be made working for me - and this will help a lot.

Ciao, Udo

Udo et al,

I found the problem and the fix is making its way through the system right now. If you're curious, it's a 2-line change here: invent.kde.org/education/kstars/-/merge_requests/734/diffs

Assuming all goes well with the submission, it should be available in the next nightly, but you can easily work-around the issue in the current release by switching to "app" as the "use Scale" option and put in the correct arcseconds-per-pixel value, as I showed above. No need to slow things down by unchecking "use Scale".

If there is a shaky/blurry image in refresh, just let it time out, and wait for the next result. That's the reason for the 10s timeout. As you saw, you should be solving pretty quickly in refresh, which tries to remember the last successful index file. Let me know if this turns out to be a problem.

Hy

Thanks. Great you have found a solution.

Maybe i have an idea: There are algorithms in EKOS that can detect if stars are round or elliptical. Maybe the refresh phase can use this to decide if calling the solver makes sense? If the stars are not round (enough) a new image should be captured instead of calling the solver with a potential timeout. Maybe there are other/better ways to check if the image is "worth" calling the solver? Just a suggestion for further improvement in the next releases? If stars are smeared due to movement while adjusting the mount this should be detectable somehow. Maybe even the HFR values or MEAN/MEDIAN or SNR could be used (aka the changes to the previous image) to find out?

Ciao, Udo

It is the solver itself that determines all these things (shape, SNR, HFR, etc)--at least the first half of the solver, which detects stars and then feeds the star detections to the plate solve code. All this is inside of the StellarSolver library. In any case, in my experience, even if we could do that, determining that the image has star trails etc wouldn't be that reliable and so occasionally waiting 10s for the solver to timeout is likely a better solution.

Hy

I just tried a real life polar alignment with the plate solving method using your suggested 'workaround', by setting an arcsecond-per-pixel value, instead of the arcminute width and the PA, and plate solving performed without any problem. I had "Refresh solver failed" errors before but not this time. Furthermore, the errors get updated correctly contrary to before where the errors would not always get updated and often not displayed.

Thanks.

William Optics GTF81 on Avalon M-Zero OBS
ZWO ASI1600MM Pro
ZWO ASI290MM (guide)
ODroid N2 running Ubuntu Mate 20.04 LTS
KStars 3.6.0 Beta

Here too it is working. Seems to me that also "Auto update" can be left checked: if unit is "app", found that changing binning updates Low and High scales with the correct numbers.

Hi, is this issue confirmed or solved? I'm also having the same problem. The plate solve simply fails and the move move start method isn't helping as the triangle is often too large for the image.

Have you tried the suggested solution/settings from the previous messages (previous page)?

Ciao, Udo

Hi Thanks for replying.

I noticed that there had been an update pushed out yesterday which included code changes as described above for the plate solving method. I've updated just now and will retry when the weather clears up.

Thanks!

I had the same issue as the most of you guys. But after I set the gain to the maximum, shortened the exposure time, and set ASTAP as the plate-solver, the alignment went much faster and stable.

Lucian

Could someone help me to find the Stellar Solver settings? I cannot find these in the Configure KStars Dialog.

I am running Kstars 3.6.5 on Stellarmate OS on Raspberry Pi.