AFAIK Ekos doesn't need to send any mount information to PHD2 because it will read it from the camera and mount specified in PHD. That covers the pier side, declination, guide focal length, guide camera and pixel size. It should have all it needs to be able to do a good calibration and allow for changes in pier side and declination so it shouldn't need to keep doing calibrations. The Ekos guide controller can force addional calibrations but they may not be needed.
I'm not sure how PHD handles a pier side change on a mount driver that doesn't report the pier side. The way I'd resolve that is get a driver that does report the pier side, even if I had to write it myself. Reading the PHD help could give an answer, there are a number of ways that they could implement this. At worst redoing the calibration after every slew.
Dither is handled by the guide application offseting the guide star position and using the normal guide commands to drive the guide star to the new position. My guide system has a pixel size of 1.68 arc seconds so a 2 pixel dither will need a little under 0.5 seconds of guiding at 50% rate. For PHD Ekos will send a dither command at a time of it's choosing and will then wait until it's guide accuracy criteria have been reached.
Why are so many calibrations needed?
The correction for declination should be able to be calculated.
The correction for pier side can be determined by doing calibrations on both sides of the pier and once the effect of a pier side change has been determined this can be applied to future calibrations. It should be no more than reversing the Ra correction direction, the Dec correction direction, or both.
Even for a portable set up all that should be needed is a calibration at the start of the evening to determine the camera rotation.
I seem to be talking to myself here.
After a couple of days trying things, none of which had any effect, I gave up and edited my copy of the sources so the defaults are what I want. This works.
BTW the guide simulator was even more puzzling, The change to the simulator properties seemed to work as far as the Indi display was concerned and acquiring an image using the indi Server worked but getting an image using the guide module of KStars didn't because the image height requested was too large. I had changed the height from 1024 to 960 to match my sensor. The driver used 960 but seems to have been sent a frame height of 1024. Setting the height to 960 in the code fixed this as well.
It looks as if neither the .xml nor the .default configuration files are used, the initial data is what is set in the code and the configuration files seem to be ignored.
Could I be looking in the wrong place? I'm looking in the hidden .indi directory in my home directory for CCD Simulator_config.xml and CCD Simulator_config.xml.default.
From what I can see when Ekos/Indi is started the simulators will always load their configuration from the .default file, even when there is an xml file with an updated configuration. I've seen this with the CCD Simulator and guide simulator. I'm trying to set the simulators to match my hardware and it's causing all sorts of errors in Ekos because properties don't match.
Should the simulators prefer to load from their XML file, only using the .default file if there is no .xml file present? I can have a go at fixing this if that's what should happen.
Yes it's quite simple to transform between the altitude and azimuth coordinate system of your mount to the hour angle declination system, all that's needed is to rotate by the latitude. That can be done using the sine and cosine rules or using matrices to manage the coordinate rotation. Once you have the hour angle, time and longitude it's easy to convert hour angle to right ascension.
This won't compensate for mount alignment errors but all that's needed is to eliminate those. No need to involve software at all if you don't want to.
THis is the problem with using someone else's communcation protocol, you are restricted to what they supply, in some cases you need to be compatible with their bugs.
I think it's better to define your own protocol, that way you have control over what is defined and implemented.
I've always defined a protocol as follows:
Every command starts with a single character, followed by a parameter if required and a terminator character.
This always causes a response consisting of the same command character with optional data and a terminator.
The terminator character must never appear in the data.
This works well with a Arduino, the library functions provide all the support needed.
Backlash would be:
send 'b#' return 'b500#' current backlash is 500.
send B600#'' return 'B600#' set backlash to 600.
Curious why it's better to have the data left shifted, I can't think of any good reason.
The INDI mount drivers need position information from the mount, in your case altitude and azimuth. This gets translated to sky positions and the driver also converts sky positions to altitude and azimuth positions to which the hardware can be driven. The mount hardware also needs to move both axes at the rates required to track objects in the sky. This all requires accurate positions - within an arc minute or better and accurate speed control - to within an arc second a second or better.
Your hardware seems to use DC motors and it isn't clear how you get position data from it. Some mounts have digital encoders on the mount shafts but high resolution encoders are expensive. A lot of commercial mounts have encoders on the DC motors and these are used, with clever motor control software to get positions and control the tracking rate. Does your hardware have this? You mentioned Closed loop PWM and PID but I'm not sure I can see position sensors.
An alternative is to use stepper motors and this is what most home grown systems use. The motors operate by counting steps so position and step rate fall out naturally.
The basic INDI telescope driver does not concern itself with any of this, it assumes that there is lower level software that will provide position, usually as Ra and Dec, move to a Ra and Dec position and do tracking.
There is however an IND alignment subsystem that is intended to manage this conversion and the calibration needed to handle conversions between astronomical positions and rates and mount axis positions and rates. This may be what you need. I don't think this is trivial though, there's quite a lot needed to get from motors to something tht can be used.
Hope this helps, it's difficut to know what level you are at with all this.
Downloaded and tried ASTAP on Windows and RP14.
It seems impressively fast, on the PC especially.
It seems better with real images than with the INDI simulator, however increasing the simulator image size helps. I wasn't getting solves with 1280x1024 but setting 2560x2048 gave good solves in 4 to 5 seconds.
BTW the default location in Ekos is incorrect, it's installed to opt/astap. The star database goes into the same directory. You need to set this in Ekos. I found the settings window difficult to find, it's behind the button with the pencil icon on the align tab.
I also found that trying to use ASTAP to solve without installing it did nothing, not even the image acquisition. Ideally I'd have expected a message in the status window saying why nothing happened but I'm not that bothered. Obviously not a refelection on Han's program it can hardly be expected to work when it's not been installed.
I'll download and try it when I've sorted out my broadband download limits, I'm currently paying a fortune for 50Gb a month, and a bigger fortune per Gb over that.
Don't think it's compulosory to use it.
In int CCDSim::DrawCcdFrame(INDI::CCDChip * targetChip)
The centre of the image is calculated and several offsets can be applied beore the GSC data is retrieved. Modifying this could help. Maybe there is already something that will help, there's already what looks like PEC offset, guide camera offset, polar align offset and declination drift.
A couple of things I've found that helps with builds:
Adding a Tool Argument of -j6 to the cmake options in the QtCreator build allows it to use multiple cores for the cmake part of the build
And something that maybe useful if we don't have kdesudo is to set sudo to run make with no password. This allows it to be added as a QtCreator build process.
in a terminal run "sudo visudo -f /etc/sudoers.d/<file-name>"
add the line "<user> ALL=(ALL) NOPASSWD:/usr/bin/make" to the file, then exit and save - ^X
<file-name> is a suitable file, I used chris-nopasswd and <user> is the user name
now adding sudo make -j8 install to the Qt build will work. This also uses all the cores and builds are a lot faster.