Not RaspberryPI-related only: here on a intel VM, 2GB ram configured, Ubuntu 20.04 and KStars 3.6.0 from ppa, same behaviour: all-simulators profile, three error assestment solves went perfect (4 sec exposure, less than 1 sec each), adjust plate solves (same refhresh 4 seconds, tried also with 6 seconds) all fail.

Matteo

Would you be willing to Zoom with me, so that I can try and replicate your setup on my Ubuntu VM?
Please PM me on this forum with your contact info. I am available for the next few hours.

Hy

Udo,

Thanks so much for all the screenshots. I copied all of your settings, and YES! I was just now able to replicate the problem.
Thanks for being so helpful.

I have not yet tried to debug the code, but I did find that when I unchecked "Use Scale", then consistently the issue went away for me.
Perhaps the code is feeding a bad scale to StellarSolver? Don't know yet. Will look into it.

In my experience, StellarSolver solving issues are often related to "Use Position" and "Use Scale".

If you (or others) wanted to try this workaround, simply uncheck that checkbox (see image below).
Hy

"Use Position" and "Use Scale" what are their scope???
If one or either are disabled which problem they can introduces????

Continuing to look at it, it seems like the issue is with the "aw" scale (arcminute width) in "Use Scale".
When I go back to "app" (arcseconds-per-pixel), things seem to work for me.
I needed to hand enter the correct arcseconds-per-pixel value, choose "app", and check "use scale".
Then things worked ok. E.g. see the values I used in the image below, which worked for the settings Udo gave me.
Of course, I'll try and find the code issues to fix "aw" as well, but knowing this work-around will allow folks to have a
working setup with the existing release instead of waiting for a new release.

Note, I got the arcseconds-per-pixel values by dividing the field of view (39' = 39*60 = 2340" ) by the number of pixels
(3008/2 = 1504, divided by 2 since we're binning 2x2) so 2340/1504= 1.56 arcseconds/pixel, so I put in a range of 1.4 to 1.7.
(If instead I use aw with a range of 36 to 42, it fails)

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.