Hello,
i have made some screenshots to show my setup. Maybe it helps in reproducing the error. Done on my RPI4 with 2 GB RAM. I have uploaded them as a ZIP-Archive.

I create a new profile containing only the telescope simulator and the ccd simulator. Main telescope set to my 200PDS with 1000 mm focal length (actual 1009 mm resulting from plate solving).

ccd_config.jpg shows the setup of ccd simulator, simulating my Omegon 533 OSC camera.

site.jpg shows the Site Management for the telescope simulator.

plate_solve_config1/2/3/4.jpg show the configuration of the plate solver. This time i tried the "Local Astrometry". I have downloaded ALL index files 2Mass and Tycho2/Gaia - just to be sure nothing is missing....

As the first plate solver run takes more time I pointed the simulator to Polaris and did a simple Plate Solve with Action "Nothing".
The result can be seen in plate_solve_nothing.jpg. Takes little over 60 sec on my Raspi. I used 2x2 Binning, Gain 100 and 6 seconds exposure to show a little more stars in the simulation.

Then i started the Polar Alignment. Direction East, 20°. Plate solver needs little more than 4 seconds now. The Result of the first 3 alignment images is shown in polar_align_1.jpg.

I changed the Refresh rate (=exposure) to 6 sec and choose "Plate Solve". Then i hit the Refresh Button. Result is shown in polar_align_2.jpg - after more than 80 seconds i got multiple timeouts from the plate solver. Then i stopped the process....

I again pointed the simulator to Polaris and tried another solver. This time i switched to the internal solver and cleared the log area.

Again PA with 20° to East. First solve attempt took 49,64s. Mount slews. Second solve took 6.08s. Mount slews. Third solve took 4.72s. All fine. Again hit the Refresh button and the solver timed out. See polar_align_internal.jpg.

Maybe this is due to the modified settings for the plate solver during refresh? This maybe can lead to the first solve attempt taking much longer than the hardcoded 10s?

To avoid local plate solving on my "slow" RPi4 i changed to the online solver but this currently takes more than 10s and therefore is useless for the Refresh phase.

Next try with local ASTAP. First solve attempt with Action "Nothing" took 13.69s. I started Polar Alignment with this Solver. Again the first 3 images are solved without problems in less than 2s. But after Refresh a window showing the ASTAP progress pops up and shows polar_align_astap.jpg. Again: "Refresh solver timed out: 10.0s"

OK - back to the internal solver. Reducing number of stars by changing the exposure time to 2s and binning to 3x3 to hopefully speed up the solver. First "Capture&Solve" with Action "Nothing" took 6.9s. Looks good. See polar_align_internal_1a.jpg

Starting PA with 20° East again. No problems with the first 3 images. Solver solved in 4-5s. Should be fast enough for the Refresh phase. See polar_align_internal_2a.jpg

Hitting "Refresh" and i get "Refresh solver failed: 5.5s". See polar_align_internal_3a.jpg

Conclusion:

If the solver takes more than 10s, the Refresh phase does not work because of the hardcoded 10s limit in the refresh phase.

But: If the solver is "fast enough" i does not work because of unknown reasons... At least for me (and some others?). Less than 6 seconds should be enough - but for some reason the solver did not produce a solution.

I did another test on Merak in Ursa Majoris with the internal solver and 20° West, 2s exposure and 3x3 binning. The result is identical. "Refresh solver failed: 5.1s". And with Polaris with solver profile "Small scale solving". No success. And with "Single Thread Solving". Dito.

Then i reduced the field and search radius of the plate solver (Min Degree Width 0.1, Max Degree Width 1, Search radius 5) and tried again on Solaris with 30° East, 3x3 Binning, 2s exp. Same result: "Refresh solver failed: x.xs".

First step in a possible solution should be to add additional options in the solver settings to make it possible to change the hardcoded 10s interval - as it simply is not enough on slow machines like a RPi4 with small Memory (and not enough for the online solver).

Ciao, Udo

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