You may not want *all* of the index files to be installed because then that is more for it to look through. Upload a few images to nova.astrometry.net and see which ones it uses to solve your images. You can also use the rule of thumb that you need the index files with sky marks from 10% of your frame size to 100% of your frame size. You don't need the smaller or larger ones outside that range. But more index files is not always better.

I always get the recommended index file for my setup. Just I do not understand why the first attempt of plate solve manage to solve the star field. But when it try to resolve the same field again, it will take much more longer time to do it. Weird. As I mentioned before, it solve faster before the major kstars update.

remember that kstars is not doing the actual solving, astrometry.net is doing the solving. So any change in the behavior could be due to some change in the kstars code or it could also be due to updates in the astrometry.net code as well.

Speaking of recommended files. I was checking mine and it doesn’t show recommended anymore - version 2.9.3 on Mac. I also don’t get warnings the thé solving is limited by lacking files so I assume it’s ok. But what happened to the recommended flags?

Yesterday was really frustrating. And i habe some quite funny issues. I don‘t know why bit i did not manage to hit my targets anymore, since it worked so well the other time.
Maybe it has to do with thebfact, that my eq „hit“ the tripod without my notice for quite a time?
Yesterday i starzed new several times. I put the eq to face weights straight down and the newton to Polaris, what always is my park position.
Then i tryed to solve and sync. But the solver times out... several timess... so i tryed jupiter because it was so easy to test with. I take apreview pic and jupiter is right in the middle. But the red crosshair icon says the eq points to somewhere else... ??? So i solve. That works and the white rectangle is right over jupiter. So i think „OK“ now we are aligned good. So i move to m66. And now it‘s getting strange. The crosshair points WAY far away from the point i chose. So i solve with „solve and track“. Solving works and the white rectangle points somewhere in the middle between the red crosshair and the target... and it says „...not accurate, slewing, solving, andsoon“ but it moves just around a bit, far far away from the target.

I got totally confused and had to stop my session with perfect clear skyes.

And when i said park, it moved to strangest positions yesterday, almost cutting my cables...

Is there a way to set my eq-6r to „zero“ or „null“ so i can start from scratch?

How can it be that i say „go jupiter“ take picture with OBVIOUSLY Jupiter on the screen, and the crosshair says nonono, your somewhere else, totally?

I even started the „mount model process“ but the system was not able to solve the pictures.

Atm i am really desperate,maybe someone knows help.

Cheers, Niki


Gesendet von iPhone mit Tapatalk

I don't suppose you have logs for last night run?

This is one of the most frustrating aspects of the setup. Basically the platesolver is the gate to your automated observation session: if it doesn't work, you waste the whole night.

You probably already know that, the objective of platesolving is both to simply center a target in your field of view in several iterations, and to refine the precision with which your mount can center the target in that area of the sky in the future.

That second point is made possible by the use of sync points, which are equivalence points between RA/DEC coordinates and gear positions obtained by successfully platesolving particular locations. For instance, if you solve the extremities of a 30-degrees triangle in an area of the sky, you can be pretty sure that any location inside that triangle will be slewed to almost perfectly at the first attempt.

Now all your successful solves are generating sync points. Without considering any other issues, if something gets in the way of slewing, and there is an incoherence between a RA/DEC coordinate and a gear position, the whole optimization model jumps out of the window because there's no such thing as a "wrong" equivalence point in the algorithm.

The rule, at least for me, is that any issue related to platesolving has to be taken care of with a cleanup of the alignment model in the mount tab, and eventually parking because it's a visual clue. The platesolving procedure is far too expensive for the observation session to hope it will eventually work again after something weird happened.

Some points I wrote down:
- Don't solve near the pole at the beginning, prefer lower declinations first, because the RA gear equivalence is most precise at the equator, and least precise at the pole.
- Adjust the radius of search of the solver from experience on the quality of the uncorrected goto of your mount, and also given the initial offset of your parking position vs. pole. Considering the mount is facing the pole when unparked, any offset there is shifting the expected field of view around. Of course, a greater radius increases the solve time.
- Allow sufficient exposure for the solver to have a choice of star sources. Quite a different case from focusing.
- Verify the optical characteristics of the scope are correct, and that they match the available catalog indexes of you are solving locally or remotely (vs. online).
- Train yourself to the use of the solver by doing star hopping sessions where you successively sync-solve locations towards a particular object.

-Eric

Maybe One more solution to this.... Always build a mount model first before start everything. More accurate GOTO, better pointing accuracy. IMHO.

That's not possible with most mounts. With EQMod, I always start from scratch and very rarely that I get problems with plate solving probably because I know all the parameters to get it working well. For my QSI583wsg now I use 5 seconds exposure 4x4 binned. Sometimes the seeing is really awful and I just check "Dark" to use dark frames to enhance the image.

Hi Jasem!

No sorry, i did not make logs because i believe that its not a software issue...
I think i make a fault here. But i do not know where.
I have the thesis, that it has got to do with the fact, that the EQ hit the tripod, and so the mechanics believe in another position, than the software. And so, solving is getting hard because it differs to much...
thats why i explained it so accurate

cheers, niki

Hi!

Very interresting aspcets Eric.

So how do i clean up my whole setup? I was to angry yesterday and had to stop and go to bed... No rational decisions able anymore...

I tryed to set new parking position too in the night, so this will not be good anymore too.

So how to start today?

As usual? Weights down, Telescope straight to polaris? And then?

Start indi. But how to "clear or clean" the system to start from scratch?

@ Jasem. What do you mean "thats not possible with most mounts" What is not possible? Build a mount model? Because until yesterday, i never made a mount model at all. Should i?

The precise question for today is: How do i clean everything up to start from scratch?

cheers
Niki

Welcome to the club of automated scope owners whom still go to sleep at 1am because there remains that oh so small issue that gets in the way of automation after ten minutes of processing

Start your session as usual. Make sure your scope is parked, pointing the pole. Connect Ekos to indi, go to the eqmod mount panel, locate the relevant button and clear the sync points written in the mount, that's one first location for these settings. Then go to the Ekos mount panel, and clear the alignment model, that's the second location for the same effect (or so I believe). Then go to the Ekos alignment panel, and clear any locations solved already. Then you're good to go.

As an validation test from there (usable tonight, April 19 22pm Europe local time in the northern hemisphere:
- Slew to Kochab (UMi). Check the location of the eqmod cursor on the sky map. Sync-solve (don't slew to target), and check where the eqmod cursor moves.
- Slew to Dubhe (UMa). Same process, sync-solve and observe.
- Iterate to Denebola, Regulus, Procyon to make sure everything is OK.

As a test, you can reset everything, and try to slew to Procyon directly, and sync-solve. This will be a more difficult operation for your setup.

-Eric