So today I encountered an issue with INDI EQMod driver while using Ekos Align module. EQMod was set to "Nearest Point" Alignment Mode and Ekos Align module initially worked after a few iterations to go to my target (SH2 190). In about 2 hours, Ekos capture module initiated a commanded meridian flip, but once the flip was completed and the solver started again, it wasn't able to get the mount to move to to the target coordinates.

So the alignment stuff is over my head, and I don't know how they work exactly so I figured I'd share this here in case Jean-Luc or anyone else can share some insight. You have to read the attached files from bottom-up. The EQMod file contains time stamp in UTC while the Ekos Align module is in local time.

Now from what I could gather is that prior to meridian flip, it had the following coords:
So the "current" RA/DE is from encoders, while the Goto RA/DE is after the alignment math is applied to them and what gets reported to the client (I'm not sure if this assumption is correct). This is why Ekos in the meridian flip asked the mount to to RA=2.6043 DE=61.5481, because this is the current RA/DE of the mount as received by Ekos.

Now after the meridian flip was complete, Ekos took an image and found the solution:
And EQMod is getting synced to the solution coordinates, so back in EQMod driver:
However, again we see here telescope RA/DEC being different from what is reported by KStars/Ekos.. again I'm assuming those are the pure encoders coordinates without the alignment model transformation. So after commanding the sync, Ekos commands EQMod to go then to the target coordinates, and EQMod tries to go there:

However, back in Ekos, we wait until mount is finished slewing, then we solve again:
But it looks like the mount didn't move much! The solution coordinates are the same as before, and what is weird now is that the telescope coordinates were updated to values quite different from target coordinates, even though we asked the mount to go to target RA (02h 36m 17s) DEC ( 61° 32' 53"). Despite this sync then slew cycle, the mount is stuck at RA (02h 33m 46s) DEC ( 54° 54' 36") and the solver runs out of iteration before it bails.

Any idea what is going on?

Hi Jasem,
I looked quickly at the logs and it seems that when adding point 4 (the sync point from the solver after the flip), it is not used in the following goto. In the previous syncs we can see the immediate use of the newly added point in the log (Align: current point is 3). Actually it seems to always use point 3 when performing the Goto alignment but uses point 4, 5, .. when computing telescope alignment during the goto. There should be an error when computing distances in goto align or when retrieving the nearest.
I will try to have a look next week if I can reproduce the problem.

Jean-Luc.

Just a scwag (sure calculated wild assed guess), and I haven't looked carefully at the numbers, but I'm going to guess that even after dropping the new point, the old point (but on the other side of the flip) was still closer to target than the new one, so, it was used to calculate the goto.

I've never looked at the code inside eqmod, but, if doing 'nearest', it should probably exclude points on the other side of the meridan for the nearest point choice, and reduce the 'nearest' to 'nearest on this side of meridian'.

I've thought to that and wanted to debug the computations to be sure. By the way the Pointset::ComputeDistances function already has a parameter to filter the points, but it has not been implemented. I will look at how Ascom Eqmod deals with this (is this an option? I think they also consider same quadrant).

The reason I was thinking of this as the cause, I've seen similar before. A system I used to use would keep not align points at all, just solve a plate at current position, then calculate a correction, then slew the mount for the correction. I saw times when the mount was poorly aligned, and we were very close to the meridian, ie less than a degree from it, the sequence of events would go like this.

- Slew to desired target, on east side of meridian.
- After the slew, calculate correction and goto to corrected co-ordinates (other side of meridian)
- Mount would flip during the slew.
- After the slew, calculate correction again, and goto to corrected co-ordinates
- Mount would flip back.

When the mount was not perfectly polar aligned (normal case when on the road), there would be a bit of a grey zone between the true meridian, and the mount meridian, into which it was impossible to slew correctly with a correction added if the mount was doing meridian math for us.

The simple solution, take the opportunity to go get a hot chocolate from the van and wait for the target to drift thru the grey area. Since we were normally on the road at star parties or other such places when we used that setup, the 'take a break' solution was good enough at the time.

Let me know if you need any further info. I retried today with the same issue and have to restart capture post-meridian flip so it would be great if you can find out what's going on. I was wondering too if it is possible to use INDI Alignment subsystem for EQMod? Obviously it would need testing, but once that done all other mount drivers can then utilize the alignment layer in INDI, which is not used now by any driver.

I started to use the INDI Alignment subsystem in place of the current eqmod alignment system. I get two issues when I add one sync point: alignment is incorrect, and the RA coordinate moves constantly with time when mount is tracking. So I think I misunderstood the use of some transform functions in the Alignment subsystem.
I also believe that it would be great if we can use the INDI Alignment subsystem for mount drivers and will try to further investigate in that direction rather than in correcting the current eqmod system. Furthermore it may help in supporting both EQ and AZ modes.
By the way, if some people are interested in helping, I may commit the changes to use the INDI Alignment subsystem, knowing that the current eqmod system is still built by default (and should work as before).

Yes, I'm willing to test anything here! I also informed Roger James (Author the Alignment subsystem) about this thread, so hopefully he can join the discussion and clear any issues!

Hi Jasem,
Thanks for the ping. I had not looked at the alignment code for a long time until a couple of days ago when I got an email from Pawel Joachim who is trying to use it in a driver he is writing. It had pretty much assumed that interest in it had died off. I am still struggling to get my build system back together after I had archived it. I regard the code as still beta due to the lack of rigorous testing.

I suggest that people look at the tutorial (number 7 I think) to see what is going on. The sample code there can be run as a simulator.

The only testing I did was on an altaz mount.

I will help where I can.

Roger

Hi Jean Luc,

There may be a problem with the default mount alignment not being set. It defaults to zenith (altaz). I will try to look at it later today.

Roger

Hi Roger,
I just managed the mount alignment to be EQUATORIAL in updateLocation, I now get Nan values after the first sync. I am looking at the Initialize function in BasicMathPlugin when number of Sync point is 1. Another point is that I also use the SVD plugin as the built-in plugin puts the scope at azimuth 180 when scope points to the pole.
I just commit the changes, in order to use the INDI Alignment subsystem, just compile indi-eqmod with the WITH_ALIGN flag set:
Jean-Luc.

I've made another commit.
I think I corrected the Nan values in BasicMathPlugins: when number of points is 1, the dummy vector was not used when computing DummyActualDirectionCosine2 but the sync point, resulting in a column of zeroes in the matrices. I also now use HA,Dec as the telescope coordinate system together with the TelescopeDirectionVectorFrom/ToLocalHourAngleDeclination (so RA does not constantly move any more).
Actually the system is working if you use the SVD Plugin and are in the North Hemisphere. In the South hemisphere the HA/Dec telescope coordinate system does not work as is, I should look more precisely at the values and the transform to TDV. Concerning the Builtin plugin, it rotates the TDV around Y axis but the result is still at the opposite of the zenith. Strangely the SVD plugin does not make this rotation as it appears that the database or the position in the database is not set when calling TransformTelescopeToCelestial.