Just tested the new 'unattended flip' switch in the mount's driver.
Didn't do a real meridian flip but when pressing the button on the Ekos INDI control panel, the mount correctly reflects the change (see attachment)
Thanks again Hans.
Installed the latest build and tested the new geographic coordinates setting.
Now both Lat and Long now have s.f precision.
Ekos was set as 'Mount updates Kstars' with time and location checked but this setting should not affect the behavior.
Also used the [-180, +180] notation for Long.
Thanks Hans for taking care of that!
knro wrote: What do you suggest? I'm all open for it. KStars IS a complex project. Maybe create a list of simple tasks to get started?
thanks Eric for explaining. So if i understood correctly, the Storage/Library module will act as an information gateway for other external plugins or internal modules.
Then a software like the one I wrote ( a FITS image catalogue written in PyQT) could be a plugin for this new module for example?
Does the Storage and pipeline model would also work for a remote observatory? I.e. if the remote computer where Ekos (Capture and Storage modules) is installed differs from the one used locally for image processing.
from Eric's chart is not clear to me where Ekos ends. I mean if 'frame DB index' is meant to be part of Ekos or an external software? I will eventually post on that thread for clarification.
knro wrote: Right, that would take some work to add this feature. Perhaps part of Eric proposed pipeline: invent.kde.org/education/kstars/-/issues/50#note_154483 .
Many of us would like to help implementing new features but Ekos has a steep learning curve, partly because of its internal API and partly because it's C++.
I think we do need more active developers at KStars side to implement such features.
During an image session, Ekos now records many useful details about the image itself like HFR, SNR and Eccentricity.
Hy's great new Analyse module helps assessing the quality of the image session both in real time and after the session is ended.
But the information is not linked to the image itself: when the best frames need to be selected for processing, an external tool like PI's subframeselector has to be used for this purpose.
It would be nice to have these parameters stored in the image metadata as custom (non standard) FITS keyowrds, then any FITS reader or a simple script or a client like AstroDom could read those metadata and help sorting and filtering best frames before any processing is made.
thanks Hans for taking the time to fix this!
I will test as soon as the PR is merged and build (i cannot build on my remote system where the mount is)