Or maybe a logarithmic scale would be more adequate than linear?
Of course, the condition "if (mag < 0.5)" at the beginning would probably change into "if (mag < minThreshold)" and later "if (mag > 0.9)" into "if (mag > minThreshold)". Is it a bad idea? I hope it could work well for nSlewRate=4, as currently provided by the PMC8 driver. I am not sure about all the 9 speeds available in ExploreStars, if ever implemented by the PMC8 driver. It would need testing in practice and it would probably depend on the particular joystick. My DIY thumb-joystick would probably not offer really exact control of too many speeds, but maybe I would not mind. So, maybe it would raise desire for even more configurability of the joystick settings - such as a toggle between the current "digital" control with a preset speed, and this kind of "analog" control with variable speed.
So, I have not found anything useful using logs, so I just wrote a simple python script that turns on the "USEJOYSTICK" switch and put it into /etc/rc.local. Stupid workaround, but it works (with a slight delay after bootup).
I have tried testing my thumb joystick, fighting with its random deviations, which make everything more complicated. I am thinking of several methods how to control the speed without additional buttons. But for casual visual observations, it seems I would be happy enough just using the highest speed currently available. Higher speeds are not supported (and I do not dare to implement them now) and lower speeds do not currently seem to be necessary (the iExos-100 is not that much robust and stable for such delicate fine-tuning anyway, and for astrophotography a remote control by a computer seems more useful than manual joystick).
I was just a bit surprised yesterday: after slewing to some position in the sky using SkySafari, I started KStars at the Astroberry desktop and at that moment the mount driver got reset, thinking it is pointing to the NCP. Any idea why?
So what was the exact sequence of events? I'm assuming you booted up Astroberry, and it auto-started indiserver with the PMC8 and SkySafari drivers, and then you connected to it and started slewing in SkySafari?
Assuming that's the case, the only thing that immediately comes to mind is that perhaps when you started Ekos in KStars, you used a local profile instead of remote profile, which killed the background indiserver instance and started a new one. If that were the case, the mount may have seen this as a client disconnect, which, depending on which firmware you have installed, causes the mount to enter into a safe mode and kill the tracking. But then that still doesn't make sense, as the mount should still have told the driver its position again when it connected to the new indiserver instance. At least that's my recollection of how the original firmware worked.
Was it just the Astroberry desktop showing the wrong position, or SkySafari too? How is the mount connected to the Astroberry? Serial connection? Not that I can think of any difference between wifi and serial, but just trying to get a full picture.
I didn't start Ekos. I just started KStars. But I have to admit I am completely confused of how it is configured. Does it always start its own instance of INDI server by default? Where can I turn it off? I always just use the device manager to manually connect to the running INDI server at localhost - I wonder whether that cannot just happen automatically on start? The documentation just describes how to connect and change the modes manually, but I cannot see any setting for automatic connection/setup.
I had a closer look at my DIY thumb joystick and not only its resolution is very poor, but it has terrible dead zones at the edges of its range. Maybe it is rather problem of the Arduino controller and its A/D converter. Anyway, the only plausible solution to use the range of values would probably be to divide it into three zones. The outer would incrementally increase the slew rate (let's say in 0.5s intervals?), the medial would just keep the movement and the inner one would incrementally decrease the speed until it stops completely. The Arduino could emulate the speed change commands as button presses. However, it does not seem to be of any use with the current speed limits and the automatic go-to system is the only way to control large scale slews at the moment.
I found no closer description of the "ramp up" process of slew speed in the documentation. May be one could find inspiration in the ASCOM source code? At the first look it seems to define 5 speeds: 0 (stop), 0.6x (guide), 5x (center), 50x (move) and 600x (slew 2.5deg/s). (The base being the sidereal rate.) Does anyone have any experience with the ASCOM implementation and how it actually behaves?