Thanks for your efforts, Hans!
It's good to realise that INDILib improves more and more!grin.png
Two years ago i implemented the correct lx200 command strings inside the 3rdparty driver of Sykwalker. It's very pleasing to see their correct implementation in the lx200 core driver now.
By the way: I'm excited that KStars 3.5.7 together with INDIlib 1.9.3 is working rock steady meanwhile at our observatory.
More than two years ago I reported
of some defective implementations in the lx200 core driver. I stumbled upon it writing the driver for the AOK Skywalker mount which is hundred percent lx200-compatible. Nobody seemed to be interested then!
I still think the driver needs an overhaul, as there are other commands with the same flaw. May I have hope to reactivate the discussion with this thread ?
I'm glad to give some experiences back to the community. As I stated before I didn't yet publish my "Rollogo"-Driver due to the lack of a good documentation. But I think with your background You should have no problem to understand the relative simple approach of the driver. Which, by the way, works very stable and reliable for more then two years now.
I will leave a private message in www.indilib.org/support/community.html for You.
Sorry! I personally used this possibility for SX-Wheels (not MDPD) successfully, and was not aware of the restrictions with MDPD-drivers. I remember however that it is/was? possible to tweak such drivers with custom XML-files (/usr/share/indi). Perhaps somebody has done it this way and can help?
It can be done with 'Custom Drivers'! (Tools/Devices/Custom Drivers ...)
You can create as many aliases for a driver as you want. Name one 'ASI Color' and another 'ASI Monochrome'. After a restart of KStars you can create two profiles with the respective alias driver name. Start each one seperately and save the configuration. Now you can choose between mono-profile and color-profile with the correct filternames in the slots.
Sorry folks, I was away for two weeks and couldn't reach the forum meanwhile. I wrote the little patch to save the binning value for guiding.
The idea was to handle the "guider binning" independently from the "indi control panel" parameters if - and only if - the camera has a guider head! This way - I thought - it is possible to use the camera either directly as an imaging camera with the "native" binning (set in "indi control panel") or as the "guiding" camera with the binning settings in "ekos guider tab". In the case of the presence of a "guider head" this value is corresponding to the binning value set in the "guider head" tab of the "indi control pannel".
So what happened to Kevin is exactly that: Because the "simulator camera" has a "guider head" the value of the binning set in there overwrote the binning in the ""ekos guider tab". Of course the flaw of the patch was, that it didn't reset the value to the guider head value immediately. In addition there wasn't (and still isn't!) any information about this feature.
IMHO the question is now the following: Should the feature of a "guider head" be preserved or should it be abandoned?
I'm looking forward to hear your views.
You are right: Mode 'SEPMultistar' always uses 'Autostar'. I was able to write a small patch that corrects the display of the 'Autostar'-checkbox. It is now checked and greyed out if the guider is in 'SEPMultistar' mode. I hope it will be merged in the new version of KStars.