×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Plate solving issue in EKOS

  • Posts: 2876
  • Thank you received: 809
Plate solving, I believe, is really like an art form. There are so many variables to tweak and play with until it gets optimized. Particularly, you should play with which index files are installed, the downsampling and binning, the exposure time, and even what areas of the sky you plate solve. Two settings which can either make it solve MUCH faster or prevent a solve entirely are the scale and position settings. Once you get those two settings right, you shouldn't change them unless you change cameras or add a Barlow or a reducer. The other ones I mentioned, you should adjust often to "taste."

I find that on my laptop, plate solves take one or two seconds typically when its optimized well (but every now and then it takes longer on certain areas of the sky). On the raspberry pi, maybe about 10 - 15 seconds? But it has been awhile since I tried plate solving on the pi, so I don't remember the exact time.
The following user(s) said Thank You: Jose Corazon, Alan Mason
5 years 11 months ago #25181

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182

That is very helpful, Rob!

I would be ecstatic if I could get 10-15s on a Pi3.

Currently I am using a 1600mm FL 8" RC reflector, scale is set to FOV, ~37'x22', I have ALL index files for the solver installed and my times are around 10-15 s with a Zotac 332pico mini-PC running Ubuntu mate natively (not emulated). I am binning 2x2 for plate solving only, now consider going to 3x3 or even 4x4 for plate solving, if that is possible. Not sure about the effect of 'down-sampling' or what it means. Can you enlighten us on that?

Best

Jo
Last edit: 5 years 11 months ago by Jose Corazon. Reason: fixing typos
5 years 11 months ago #25183

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 15

Thanks Rob. Will try to play with those setting u recommended later.
5 years 11 months ago #25184

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
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.
5 years 11 months ago #25186

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 15

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.
5 years 11 months ago #25188

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
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.
5 years 11 months ago #25190

Please Log in or Create an account to join the conversation.

  • Posts: 424
  • Thank you received: 66
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?
5 years 11 months ago #25191

Please Log in or Create an account to join the conversation.

  • Posts: 321
  • Thank you received: 19
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
Skywatcher EQ6-R | Lacerta 10" Carbon-Newton | Lacerta MFoc Motorfocus | Moravian G2 8300 Color | Canon EOS 5DMarkIIIa | Lodestar X2 guiding cam | KSTARS 3.4.3. on my outdoor-Laptop with KDE-Neon/Plasma | KSTARS 3.4.3. on Remote-IMac with Catalina | KSTARS 3.4.3 on Remote-Macbook Air with Catalina
5 years 11 months ago #25249

Please Log in or Create an account to join the conversation.

I don't suppose you have logs for last night run?
5 years 11 months ago #25252

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:Plate solving issue in EKOS

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
5 years 11 months ago #25253

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 15

Replied by Tom on topic Re:Plate solving issue in EKOS

Maybe One more solution to this.... Always build a mount model first before start everything. More accurate GOTO, better pointing accuracy. IMHO.
5 years 11 months ago #25254

Please Log in or Create an account to join the conversation.

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.
5 years 11 months ago #25255

Please Log in or Create an account to join the conversation.

Time to create page: 0.457 seconds