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

Ciao, Udo

Read More...

Hello,

i am not sure if this is the right place but i have some suggestions for EKOS.

Sometimes i use my 8" Newton visually and use the Guidescope with attached camera to target objects by plate solving. This works quite well if main scope and guidescope are perfectly aligned. I normally do this manually by targeting a bright star but this is not very exact.
Maybe someone can build a function into EKOS to help with this process? First take an image with the main scope/camera, plate solve and determine the center of view. Then start exposures with the guidescope and plate solve and display the difference between center on main and guide scope in a loop. I would then be able to adjust the position of my guidescope until both scopes are pointing to the same direction.

Maybe a nice addition that could help avoid one problem if guiding through guidescopes:
When autoguiding through a guidescope some setups suffer from e.g. tubus flexing or other effects that shift the axis of main and guide scope during the session. This has - at least for longer exposures - some effect on the guiding precision that cannot be measured through RMS. If the axis of main and guide scope shift you can get elliptical stars even if guiding works with perfecly low RMS.
But: Currently there is no easy way to exactly detect this shifting. Using plate solving with main and guide camera this could be easily checked. Just make exposures with both cameras e.g. near the pole, plate solve and measure the distance between the center of view. Then slew to another position and do it again. Compare both differences and you have a measure for the shift due to mechanical tubus flexing etc.

Both functions could be added by "only" building a nice user interface. The background functionality needed is already in the code (slew, plate solve etc.).

What do others mean? I think this are not really important improvements but they should be quite easy to implement and nice little features for someone.

Ciao, Udo

Read More...

You can have multiple jobs with the same object/name.
I have tried this and it works for me. But i had to be sure to disable all job constraints (e.g. Twilight). You can check which constrains/settings are active by clicking on a job in the scheduler queue. If the status is idle normally some constraint is not met. Altitude? Twilight? Something like this.

Ciao, Udo

Read More...

Not really an issue, but a little more work. You should be able to add the same job over and over again to run your demo for a sufficient amount of time.

You have to uncheck the automatic sort option "Sort jobs by altitude and priority" in the Ekos->Scheduler Settings to prevent EKOS from sorting. Restarting EKOS/K-Stars is required for this change to be effective.

The schedulers .esl file is simple text. Each single job is between <Job> and </Job> Tags. You can edit this file with a texteditor and just copy the jobs there. Loading such a modified job takes some time when a huge number of jobs is included. But you should be able to generate a schedule that runs at least for an hour or so.

Ciao, Udo

Read More...

The invalid Job has "Repeat until completed" marked. If this is the case for the first job, this could be the problem. Set the checkmark to "Sequence completion" or "1 runs".

If you plan to repeat multiple jobs over and over again i think you have to add them multiple times to the scheduler as it is not possible to repeat the complete schedule as far as i know.

Ciao, Udo

Read More...

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

Read More...

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

Read More...

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

I will try again tomorrow and add screenshots of my solver settings.
What hardware/CPU did you use?

Ciao, Udo

Read More...