Testet the Flat-Worflow yesterday. Funny behaviour. First the system set the exposuretime slower and slower, but it then suddenly it went from, say 0,075ms to 74,5 Seconds. Must be kind if a comma-fault?

Another problem, despite the incoming clouds, occured later last night.

Because i remembered that i used the polar alignment tool some time ago, two months or so, i had some thoughts.

I remembered that when i used that tool, that i had to use the mount-adjustment knobs REALLY MUCH, to get the polar-alignment done.

I had this all the time in my mind, because i was sure to have done the polar alignment with the polarscope on the mount right.

So after some problems yesterday, i decided to clear the mount model, go in park, shut down kstars and begin from scratch.

So i looked through my polarscope and, as i expected, it was WAY FAR from polaris. I mean polaris was not even NEAR the scope...

I found polaris then and wanted to do a new polaralignment but then clouds came in...

How can that be?
Should i just NOT make a polaralignment with kstars and instead trust my polarscope-alignment?

Questions over questions...

Cheers Niki





Gesendet von iPhone mit Tapatalk

Haven't used Ekos polar alignment yet, but my opinion is that there should be no alignment points recorded while processing the adjustment. In that situation, the mount model defeats the purpose of the polar alignment as we do want to adjust the physical orientation of the mount. For instance, when using synscan, you always go through a park/shutdown between iterations. But again, did not try Ekos on this, someone else may comment.

About flats, I'll agree the algorithm is not that stable and could be improved. Think of it as a bunch of points on a exposure/mean ADU graph, with the algorithm trying to fit a (linear?) curve to determine the next exposure. Experiment with the tolerance to relax the constraint.

-Eric

Hmmm. Good point with the mount model „disturbing“ the polar alignment.

I think i will try today to first polar align via scope, then clear the mount model do the ekos polar alignment.

And after that, i think i additionally try the polar alignment function of my mgen then.

I did BEFORE all of that two 3 star alignments yesterday, and i always needed 3 iterations per alignment star. Also i first, and most of the time anyway, have to use the online plate solving, because the offline version times out most of the time. Though i have ALL the files downloaded.
Seems to me, that this has something to do with my big misalignment.

Because after clearing the mount model yesterday, and after making new scope-alignment, the offline solver did his job now in seconds...

By the way... No full support of the mgen as guidingsystem in kstars yet? Is someone working on that?

Cheers, niki




Gesendet von iPhone mit Tapatalk

This is an interesting discussion of the mount model tool. May I ask some NOOB questions, as I have not used this before:

1.) is it suitable for a EQ6-R mount?
2.) Are the alignment corrections stored in the mount? I can only see save buttons for saving the alignment list?
3.) Do I lose the setting when powering off the mount?
4.) I guess this has nothing to do with polar alignment and the polar alignment module (other than maybe disturbing when the trained model is inaccurate)?
5.) Does this basically replace the usual manual alignment procedure done when powering on the mount with the handset?

Thanks for helping a newbie,

Amin

Generic 3-star alignment is used to get an overall correction over the whole hemisphere. Because the corrections occur in sky patches, you may still get incorrect precision on particular positions. Atmosphere refraction is always a problem, and will be in the case of the eclipse as the altitude is quite low. You should probably use three or more sync stars close to the target area.

If the offline version times out, it means it is not looking at the right area. You specify a maximum angle for the search, and the time needed for a match increases non linearly as the engine goes away from the expected position. First, when testing don't align near the pole because of the lower precision in the coordinate/gear relation. Second, use the most narrow search angle your setup allows, this will make the engine fail quickly when something is wrong with the orientation of the mount: if you expect your mount to point within 5 degrees of the target in any direction without correction, use that value. Third, remove as many index files as you can: you want the engine to only search catalogs matching your optical setup. Fourth, adjust the timeout to your configuration and computer capabilities: while testing, the engine should fail to find a match in the catalogs, not abort the search because it's long. The online engine searches the whole sky for a match to answer your request, you only need to adjust the centering of a target that is already roughly there.

That's only because the mount was pointing close to the target. Maybe having too many sync points in an sky patch is causing issues with the interpolation? Maybe a better way would be to sync evenly spaced locations, then never do a target align again? I didn't touch the subject, I don't have a fixed setup.

I am not, unfortunately, and I have doubts this feature can ever be robust enough. There's a branch on my github with code to automate guide star selection, calibration and start/stop, plus a preliminary PHD2 network interface. But this bases on blind navigation scenarii, and I felt the Ekos scheduler needed more love for the time being

-Eric

I spoke to the guys from teleskop-austria.at which are also the guys behind Lacerta just a few weeks ago about mgen support for INDI. they said some French guys in Graz are working on this, but they have no further info on how far they are. The will let tell me when they have something ready. I will let you know.

Thanks for the hint of clearing the indices, my thinking was the more the better, so I downloaded them all.

As for time out of the offline solving, Where is the setting for that? I actually have sometimes the problem, that it does not timeout offline and I have to stop it manually. I believe the setting in the options is only for online solving, isn't it?

Check "/etc/astrometry.cfg".

-Eric

This is stored internally on MacOS I believe. I checked for the file, it does not exist.

Attached is a screenshot. I just tried, but it did not take long enough to fail to reach the timeout I will try again tonight, I am pretty sure, it took more than 3 minutes when I aborted it.

Ah sorry. You can probably override the timeout with "--cpulimit <seconds>" on the command line, knowing that this is actually cpu activity time, not system time.

Looking at the code, the configuration file is there on osx:So probably that's basically where the app was installed.



-Eric

You talked to Tommy? Where are you from? I know him from his shop, all of my setup is bought at Teleskop-Austria.

I asked him some time ago, and he said no indi/ekos support yet. Maybe somebody works on it.

Cheers
Niki


Gesendet von iPhone mit Tapatalk

1. I use a EQ6-R and it works afaik.
2. I have no idea...
3. I have no idea too, but i think so.
4. I do not understand that question?
5. Do you use the Handbox alignment although you use kstars?
6. How did you connect the computer to the mount when using kstars?
I am a newbie too...

Cheers
Niki


Gesendet von iPhone mit Tapatalk