No idea if it is related. But I noticed one issue of the indi driver, that is if the wheel reconnects, the driver will not see it anymore until the driver executable is restarted. This sometimes happens to me with bad cabling, when I accidentally touch the cable. Might even happen with a stronger wind gust. Though I do get errors then, that would stop the sequence...

Read More...

Not too much knowledge. What they use is so-called light propagation using FFT methods. Contrary to raytracing, that allows for diffraction effects. There used to be a (free) software called light pipes (IIRC) doing this. I just searched for it, and found that there is an implementation for Python in the package opticspy . Maybe that gives you a start.

Read More...

khobar wrote: My CEM25p, on the other hand, not only failed to do any flip (even though I'd set the HC to something like 20 minutes and Ekos to 6 minutes), it got totally confused after I tried to do the flip manually (send it home, slew to target again). I wonder if this has to do with bad GPS data for some reason? If opportunity presents, will try again tonight.

I'm compiling myself, from git, and create normal (RPM) packages. So I always have the older versions available, and switching is a matter of (tens of) seconds. I usually compile the latest version during the day, and run it at night. If there is an issue I just downgrade to previous, and run the night. Then next day have a look at what the issue is/was. INDI (and PHD2) run on an ASUS PN40, KStars/EKOS on my Laptop (both Linux, openSUSE Tumbleweed), connected via Gbit Ethernet.

Read More...

In principle it's not secret (though not published anywhere). But I do all my image processing stuff in IDL (Interactice Data Language), so as-is it's not really helpful to others. Last time I tried GDL wasn't able to run all needed stuff in there. It's anyhow only an ugly hack (comparable to some shell script) that likely only works for my camera, screen and data organization
As always, the difficult part is not the core math (Levenberg-Marquardt fit), but the effort to make it work on any image, and nicely display the results.

Read More...

Yes, this is what I currently do. I run an external program that watches for new files, analyzes some (preselected) stars by fitting a 2D moffat model and then plots FWHM and ellipticity. (It also aligns images and gives a live stack view). Ellipticity usually points at guiding errors and/or wind, FWHM obvious focus errors, but also seeing quality. I do get a very good correlation between the FWHM variations and seeing measurements using a DIMM (Differential Image Motion Monitor).

The latter is one reason I don't use the automatic monitoring by EKOS anymore. There is no real way to decide if the focus drifts or the seeing gets worse, unless you also include the temperature plot (unless of course your focus system has slip). So a general monitoring module definitely should also include the temperature (but I think that is already on the wishlist, is it?).

As for monitoring in EKOS: How much work would it be to grab the (full field) star selection and HFR fitting from the focus module, and put it into the FITS viewer? I know it even already has a 'HFR' slot in the statistics which is always -1. So it seems the evaluation part is (still) missing...

Read More...

Can you run astrometry.net locally on the command line? I also use a local install with python3, but never had issues with kstars/ekos using it.
There were some issues with the install if you compile it for python3 use - some scripts still used the wrong version and tried to run python2. But AFAIK that had been fixed in a recent update...

Read More...

Hi Hy!

Just playing with the new version. The plateaus are now gone, that's very nice. Attached are three runs, the first with a step of 30, the second and third with 20.
The derived focus positions were 45638 (step30), 45648 (step20 1) and 45608 (step20 2). That the last one is lower for sure is a (real) temperature effect, it's currently dropping at 2 degrees/hour. So that's nothing to worry about.

But the stop criterion is still a bit sharp - it will largely be affected by seeing. Especially the second and third run got a good frame and stopped, both times I'd say a bit too early. Not sure though how to catch that other than doing a polynomial fit including all points after also the fine scan went (clearly) through the minimum. The latter might suggest to wait even one exposure longer for both repeats to make sure it wasn't seeing bending it up (I think this happened in the second scan). And in that scenario it would also need a final move-out and then back in to the detected focus.

But the general shape of the curves looks promising to me

Cheers,

Pit