Sorry I wasn't more clear in my response. In Ekos, the GPG RA guider is the same as Predictive PEC in PHD2. And no, Ekos does not have anything like PHD2's Guiding Assistant, unfortunately.
Wow, that's one ugly looking graph. I would actually start by disabling guiding output, and just let it graph the tracking error with no guiding commands being sent, just to see what the mount is doing all on its own. That will tell you if those large spikes are a result of something mechanical in the mount, or the guider going crazy.
I can't find any place in the code that would change the port to /dev/ttyUSB0 in case of failure. So that one is a mystery to me.
If you want to recompile the indi_gphoto_ccd driver, you can change the commands that it sends to match the serial relay board that you are using. If you want to try that, in file gphoto_driver.cpp, at line 649 is the command to close the shutter, and line 1223 is the command to open the shutter.
INDI supports a few different types of relay controls for external shutter release.
DSUSB is a special device made by Shoestring Astronomy. In the Nikon INDI control panel, you would just set the port to "dsusb" and it will look for that special device plugged into a USB port. If it finds it, all is good in the world, and it should "just work".
The KMTronic relay boards present themselves to the system as a USB-to-serial adapter, and it listens for special commands to open and close the relay.
If you put anything other than "dsusb" into the port field in the INDI control panel, it will assume it is a serial port (such as /dev/ttyUSB0) and will attempt to open it as such. If it's a Nikon camera, it will send the special KMTronic commands over the serial port to open or close the shutter. It will also toggle the RTS line on the serial port to open and close the shutter. So if you attach a USB-to-serial adapter that isn't a KMTronic relay board, you would have to wire up a relay to the serial port's RTS line to control the shutter.
If you have some type of relay control board that expects commands over the serial port, and those commands aren't the same ones that KMTronic uses, it probably won't be usable with INDI.
I don't have an iOptron mount, but rather a Sky-Watcher (EQ6-R Pro), that I use with the mount's built-in PEC. I trained it on Windows using PEMPro. I think I saw somewhere that some models of iOptron mounts don't allow guiding and PEC at the same time (which is incredibly stupid if that is the case). But if that isn't the case with your mount, then there would be no other reason why you couldn't use it with Ekos and PHD2.
BTW, the new internal guider in Ekos has the same Predictive PEC ability that PHD2 has, so that's one more reason to use Ekos guiding instead of PHD2. And yes, you can use PHD2's (and Ekos) predictive PEC in addition to the mount's built-in PEC. They complement each other. They even say so on the PHD2 website in the documentation for the Predictive PEC algorithm.
Yes, there is an API for KStars and Ekos. It uses DBus. Here's the Ekos DBus API reference: api.kde.org/appscomplete-api/kstars-apid...osDBusInterface.html
But to solve your problem of failed guiding aborting your image capture sequence, I believe the usual approach is to put the sequence into the scheduler, and tell the scheduler to keep looping the sequence. Then if the sequence fails because of guiding failure, it will be restarted.
Hope this helps!
That motor should be fine. In the default 32x microstepping configuration, it might move a little slow. If that turns out to be the case, you can change the DIP switches on the Waveshare HAT to a lower microstepping factor, to speed things up. You will need to modify the #define MICROSTEPPING at the top of the source code file to match the DIP switches, and rebuild the driver. But it will work as is, maybe just a little slow.
Sorry Kurt, I didn't see your problem report until just now.
The driver won't start because of a permissions issue. The driver needs access to the GPIO device, which usually requires root access. The easy fix is to run indiserver as root. On at least some systems, you can add your user to the "gpio" group, which will negate the need to run as root. That seems to work on Raspbian, but not Ubuntu or Armbian.
I will try to get the driver added to 3rdParty one of these days...
I don't think that will work, because it isn't sending any guide pulses to the mount to record. Unless I'm misunderstanding.
What I think will work is to use GPG guiding for several worm cycles. That should be enough for it to characterize the PE of your mount. Then in the settings, change the guide aggressiveness to 0. Change the GPG control gain to 1. I think that will disable guide output for errors, but will continue to output what it learned via GPG. Then record the PEC in the mount. I don't know for sure if that will work or not, just a thought.