I see no need to change the refresh function for the legacy move star, or move star + calc. I'm only advocating this for the plate solve method.
My reason for that is I have not experienced much in the way of a graceful recovery from bad frames. I've found bad frames either cause significant time-out delay with little information as to what is taking place while it is trying to process it. Or worse case scenario, it gets hung up in the process and never takes a new clean frame, requiring me to abort and redo the entire process, if I'm lucky it will let me. If I'm not lucky I have to restart the drivers.
INDI/KStars on Raspberry Pi 4, 4gb
Raspbian Buster with AstroPi3 script configuration
Skywatcher HEQ5 Pro Mount
Canon 600D Camera
Orion SSAG/ASI120mm @280mm Guide Scope
Waveshare Stepper Motor Board - DIY Focuser
Adafruit GPS Module
Generic Bluetooth Joystick.
Startech 7 port powered USB Hub.
The plate solve refresh has a huge advantage for small sensors with large focal length, leading to very narrow FOV. I only have less than 0,5° FOV and have to setup and align my EQ6 every time i want to work with it. Normally my initial polar alignment ist 1-2° away. In this case the "Move Star" method is nearly useless as the triangle does not fit in the sensor window. And: I need to make large correction to the alignment screws and the "move star" refresh often looses the star as it moves out of the window.
Plate solve PA would be a great help for users like me - regardless of the refresh cycle duration.
I normally do PA near Polaris. And the plate solving of the first 3 images (and slew to target, sync) work perfectly even for my small FOV and even in regions with only a few stars like around Polaris. ONLY the refresh does not work and the main problem is that there is no meaningful error message.
To reproduce it you can use the following simulator settings:
Focal length: 1000 mm
Sensor dimensions: 11,3 mm x 11,3 mm
Resolution: 3008x3008 px
Binning 2x2 (to reduce the amount of data and the size of the captured image)
Pointing the scope to polaris and start Polar Align with 20° or 30° delta to east or west.
This should be enough info to reproduce the problem.
Exposure time varies from 2 to 10 s - the result is always the same: Normal platesolving works. First 3 images during PA solve perfectly.
Refreah phase: Plate solve failed, no entry in the solver list, no meaningful error message.
Tested on a RPi4 with 2 GB RAM and on a windows PC coupled to INDI running on the RPI4.
I ran the simulator using your specs and had no issues. See this movie.
I tried it pointed right at Polaris, as in the movie attached, and 5 degrees east of Polaris. In both cases it succeeded.
Did the simulator fail for you? Note: you do not enter sensor dimension in the simulator/INDI control panel, so I simply divided 11.3 mm / 3008 px to get a 3.75u pixel size.
Please try and replicate it on your simulator, and send me the specifics of how you set it up.
I used my mac laptop running an Ubuntu VM.
It's best for me if you can re-create this issue with the simulator, if possible.
Can you compile and run code? If so, I can show you how to, e.g. save the refresh images as fits files.
Actually, when I increased the "refresh" setting to 11 seconds, plate solving failed with msg saying timeout: 10s. So in my video, the failure in less than 1 second is misleading. Plate solving was forced to stop because the refresh was set to 2s in my video.
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
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).
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.
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).