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.
Running Stellarmate 1.6.0 on a raspberry 4, fresh install, i have a ORION Skyscanner 100 for initial testing and hooked a raspberry driven webcam type of thing on it, connected it to the stellarmate as an "INDI Webcam" from the Ekos wizzard, i get an image.
Problem: Connected tge iEXOS100 the same way, usb mini b cable with an unsb A end and plugged it into the usb2 port of the raspberry, it gets connected as /dev/ttyUSB0
Default Setting for the ES iEXOS100 PMC-Eight, i onlz touched the Baud Rate to 115200, when ever i press buttons labeld "Connect" or similar, i get some activity in the INDI Control Panel LOG, and it normaly ends with:
[ERROR] Bad connection. Trying to reconnect.
[ERROR] check_pmc8_connection(): Error connecting. Check power and connection settings.
Power is not an issue, using the explore scientific way i get some movement out of the thing, so i guess thats fine, next guess, bad usb cable, next guess, write here and ask for ideas, iam a bit lost....
got it working for me, after talking to Alex Zarvis in the comment section of this video:
i managed to get hold of a windows machine, patched the firmware of the mount to the latest version using: 02d3287.netsolhost.com/pmc-eight/PMC-Eig...Kit%202021-08-08.zip
Then i downloaded a tool called "FT_PROG" and started digging in the EEPROM of the mount in order to invert something called "DTR" and now it works with Stellarmate