Maybe the joystick is not available at the moment the INDI drivers start and turns off again? I noticed that happens with the mount as well. It is not a plug and play system, it only tries once...?
Yes, I would like to contribute, I just do not trust myself. My first experiments ended with a damaged mount and I had to return it. I only tried to telnet and query the firmware version and still the mount stopped working. A discouraging experience. So, when I see something is not implemented by a more competent person, I am afraid there might be some good reason for that. I will try to get deeper into the INDI system, if I can, but I will surely always try to raise questions before trying to actually "fix" something that should not be played with for some good reason.
I really like the whole INDI system architecture, but I still wonder about some details of the implementation, such as the array-like implementation of switches and the reason for such implementation decisions (what happens if I try to switch on more then one option? etc.). I should probably get some time to study the documentation closer before trying to hack something (and break it).
I've tried using the joystick with the PMC8 every now and then. I think my observations were generally the same as yours. It seemed like it was one axis at a time only, and I would sometimes need to go and re-enable the joystick in the PMC8 driver (though oddly enough I don't think it was something I always needed to do). I can't really comment on the speeds. I was using it for minor corrections after a goto, so I didn't want the mount to move quickly anyway.
It bugged me a bit at the time, but I filed it away as something to look at later, as I had other priorities and I'm usually away from the mount when I'm using Indi anyway. But I might be willing to look into it when I get a break from work projects again in a week or so. Or test anything you come up with .
I'm a bit surprised telnetting into the PMC8 and querying it would have bricked the mount. I've done a lot of dumb things with mine and it keeps on ticking. On the other hand, it does take a little while to understand the Indi architecture. If it's any encouragement, I think the real reason why something is not implemented by a more competent person is not that it can't be done, but rather a shortage of competent people who are interested enough in using Indi to control the PMC8. I mean, I'm a lawyer for crying out loud--I shouldn't be allowed to touch the driver .
The problem might have been that I misunderstood the documentation and turned into the debugging mode where there are completely different commands with low-level effects on basic settings. But that is just another reason not to trust myself. Nobody really told me what happened, they just sent me a new mount.
I only tried the mount twice since I bought it and I have had problems with a proper polar alignment and with keeping it. I still need to learn. But I wished to be able to move the mount freely manually even without the goto, just to be on the safe side if I give up fighting in the fields and forests. I have read the higher speeds need to be turned on gradually (and I do not suppose the mount does it automatically, so I expect it to be the reason it is not implemented in the driver yet).
The ability to move both axes at once should not be a problem, though. Currently the driver denies the second movement, because the mount "is currently slewing". I suppose it is not desirable to start movements when the mount is slewing automatically to some target position. So, if it is possible to differentiate between the goto-slewing movement and the manual one, it could be enabled easily. I will have a look.
However, those are all just minor details one can live well without. I guess the most serious limitation of the driver is currently the lack of support for the INDI alignment subsystem...?
After a long search for the code where the driver integrates the joystick controller, I found (surprise! surprise!) that it's all just inherited from the default INDI::Telescope implementation. Finally, a lot of the undocumented settings make some sense to me, as well as the terms "angle" and "magnitude". On the other hand, most of the limitations seem to be based here. Since it is the work of Mutlaq personally, the reason is definitely NOT any lack of competence in this case... The "magnitude" plays no role - it just starts movement when above 90% (and stops when below 50%?). So, trying to program the joystick to work around the INDI system seems as crazy as just playing with the code of the method Telescope::processNSWE() myself. Or maybe is the whole idea of mine to control the speed by the magnitude of the joystick just for some reason bad?
I used joystick with EQMod driver and select "Slew Speed" by tapping the arrow keys up and down in the joystick itself... that made sense to me. I wasn't following exactly how you wanted to perform the speed control. I didn't check how the PMC8 driver offer in terms of slew speed property.
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?
Have you followed the steps to get the PMC8 working in serial (versus wifi) mode and also adjusted the usb<->serial converter cable to invert the DTR line? Sorry these extra steps are required but the way Linux and serial ports interact it seemed the easiest way to get the driver working in the INDI framework. The problem is when you open a serial port in Linux the default behavior interacts with the DTR line in such a way to make the PMC8 controller box reset. It is an unfortunate design decision - it would be nice if the PMC8 unit had a switch you could disable this behavior as it is only required when programming a new firmware in the unit.
Just FYI, it is also possible to connect over wifi *if* you get the INDI server on the same network as the PMC8. There's several different ways of doing this, though it's probably not any easier than connecting over serial.