KStars 2.9.5 is out!

KStars v2.9.5 is now available for Windows, MacOS, and Linux.

Autofocus module users would be happy to learn that the HFR value is now responsive to changing seeing conditions. Previously, the first successful autofocus operation would set the HFR Threshold value of which subsequent measurements are compared against during the in-sequence-focusing step.

However, this method suffers from two issues:

1. Seeing could change during the night.
2. HFR value could be different for different filters.

These issues can lead to interesting artifacts under the right conditions, most notably repeatedly running a complete autofocus run after each subsequent exposure thereby losing precious observation time in a futile attempt to bring the HFR value down.

In KStars 2.9.5, we introduce an experimental adaptive HFR Thresholding algorithm that selects the median HFR value filter-wise. It still has to be seen whether this is an overall better approach, so go out and test this!

Ekos Scheduler module has received major patches from Eric Dejouhanet to improve its reliability and fix some corner cases. More patches are in the pipeline to make the scheduler rock solid in various complex scenarios.

A quite illusive and annoying time-zone related bug was fixed when using INDI GPS devices. Now KStars correctly accounts for the UTC offset. Another related issue is related to preventing race conditions between multiple devices that may send time information, such as mounts and GPS devices, so now you can explicitly select which device to receive the location and time information from.

Finally, Align module FOV now default to zero on startup. Previously, FOV as calculated from the telescope focal length & camera pixel size was used to derive other values passed to the solver. However, it turns out that the FOV for real optical trains can be different. Using focal reduces, coma correctors, and even filter wheels or spacers can alter this value, sometimes quite significantly to the unsuspecting user.

Therefore, relying alone on the calculated FOV might actually cause astrometry.net to fail since the actual FOV might fall beyond the field of view threshold boundary. With this addition, the first solver run would take a little bit longer but it would also produce a quite accurate effective FOV. You can think of the effective FOV as the real FOV that your combination of your camera, telescope, and whatever sits in between (aka optical train) ends up producing.

This effective FOV is then saved for each Profile-Telescope-Camera combination for future use. This is all done behind the scenes to make user experience much more pleasant and bullet proof when using the Ekos Alignment module.

Clear skies!