Now I'm wondering, when I committed the change roger posted later in this thread, if indeed I broke the changes you made, I will have to check into that.

What I have found, is calling all the entry points for equatorial co-ordinates, it appeared to be working, I calculating correct offsets for a goto etc, but when I left the mount tracking, turns out calls into the alignment system are actually turning it into a 'stationary' mount. I call in with updated ra/dec, and after it comes out of the transform, it's transformed to a spot that is stationary in alt/az co-ordinate space, ie the mount no longer appears to be tracking. But when I hacked up the driver to use alt/az inputs to the system, it works just fine, I just used libnova calls to transform current ra/dec values to alt/az values, now it's all working correctly. I'm going to re-do the hacks now to use ha/dec and see how that works out.

But, there has also been a lot of confusion on my part going thru all the different transform variations. What I've been looking at, is in all honesty, we shouldn't need to expose things like telescope direction vectors etc to the low level drivers. If we do a clean set of encapsulations into the base telescope class, it should be possible to hide all of that from a basic telescope driver, and bury all the the dealing with to/from telescope direction vectors etc into a couple of simple functions along this line:-

MountToSky
SkyToMount
Sync

If those are properly implemented in the base telescope class, then there is really no need for a mount driver to be aware of anything other than it's own co-ordinate space. On top of that, there are only really two variations of co-ordinates to deal with. In the first case, an alt/az or ha/dec style mount, is dealing with a co-ordinate space fixed relative to the mount, we can initialize with a hint as to orientation, but after it's got two sync points, even that is no longer necessary. Then another variation, is a mount that returns ra/dec values when queried, and it's in a co-ordinate space fixed relative to the sky. that can be buried into one intialization call, and the rest can be well hidden in the base telescope class, so that a driver never need deal with things like telescope direction vectors and transforms. It just says 'here is where I think I am, give me back a fixed pair of numbers to say where I really am'.

So I've once again got a hacked up variant of the synscan driver workign here, and i'm going to clean up the hacks again, then look at putting it all in the temma2 driver. But a thought that keeps running thru my mind, it's about the same amount of work to put it in the temma driver as it would be to put it in the base telescope class. If I bury all of the dealing with telescope direction vectors and such into the base telescope class, then implementing into more drivers becomes trivial, if any work at all. If it's done thru the NewRaDec, Sync and Goto hooks already in the base telescope, then any drivers using base telescope will magically inherit the alignment implementation, and it'll all 'just work'. It would sure help keep drivers simple because writing a driver for a new type of mount would not require understanding all the hoops and jumps necessary to go between equatorial, celestial, alt/az and telescope direction vectors. Just let the hooks already in place for sync, goto, and NewRaDec deal with it all transparently.

Hi Jerry,
I think I understand what you are getting at, and I agree. However for the best accuracy the subsystem needs to transform all coordinates into a common reference frame which is fixed in relation to the centre of mass of the earth. This is because in general the main sources of alignment errors (gravity, fabrication, refraction, etc) are fixed in relation to that as well. I need to think more about this, but I think it should be possible for the subsystem to just throw back the adjusted coordinate in the same reference frame provided it is fixed in the relation to the centre of mass.
I was about to start incorporating the position of the mount relative to the centre of mass into the calculations when I stopped work on this. This would probably be the time to do it. Any volunteers .

If you take a look at what I did in the last commit for the synscan driver, it addresses all of those issues, into a neatly encapsulated way.

I built up a couple of functions, SkyToTelescope, and TelescopeToSky. They are called with RA/DEC co-ordinates as they flow thru a normal telescope driver process. My functions switch the RA/DEC to HourAngle and Dec so we are working with 'fixed' co-ordinate space, then call into alignment routines. When results come back, they are converted back to RA/DEC. In essence, it becomes a fairly simple to use transform at that point, with all the complexity hidden. Call it with an RA/DEC that says 'I think I'm here now', and it comes back with a 'here is your corrected position' result.

In all honesty, I dont think it needs to be made any more complex that that, because the HA/DEC co-ordinate space is indeed fixed against the reference frames you mention. Assuming the telescope has not been moved since the alignment database was created, it should remain valid. As soon as things get moved, it's all invalid anyways.

The real caveat to the way I did this, there is an underlying assumption on all items using the same (system) clock for time reference. I'm really not sure if there is a correct way to handle the case of different devices using different time sources. Personally, I think that's an overall design flaw. Using the example of mounts snooping a gps to get time, that creates wide discrepancies at times, because many functions within indi itself, use system time for calculations. My own opinion is, if you want to use a gps as the time base, that's what NTPD is for, it will keep a system clock synced to a gps, with very high accuracy if the gps has a pps output.

The way I did it in the synscan driver, by isolating a couple of functions, that could easily be moved into base telescope, and done in such a way, underlying drivers have no need to concern themselves with what the alignment system does, it's all magic once enabled.

I come back to this thread after leaving it suddenly one month ago, a sad event has occupied me for the end of the year, and then work has resumed.
I fully agree with you, alignment could be implemented in the Telescope base class. The way Roger implemented it by simply inheriting from his class clearly shows it.
I think the Sync method may lie in the base class as long as you may get the current Telescope coordinates (pure virtual method?), the driver Sync method could still be called through a standard sync option (which then won't affect the alignment model). Concerning NewRaDec, the base class may apply the alignment before setting the Ra/Dec property, and I'm not sure if the driver has to be aware of this: in which case would a mount driver use aligned coordinates rather than its own coordinates? The case for Goto seems straightforward, simply apply the transform before calling the goto driver method. Did I miss something ?
You only consider the case of equatorial mount, I wonder what is the situation for alt/az mount where the alignment subsystem is used for tracking. And I also wonder if the alignment subsystem may be used in guiding equatorial mounts, as it is supposed to capture the axes drifts.
By the way I've modified indi-eqmod to allow the use of eqmod and Roger subsystem alignment methods in parallel: they get the same sync sequence, and you could switch between them in the options tab. Before committing I wonder if this actually would have any interest.

While making basic tests after updating (so the BasicMathPlugin Roger has posted in this thread has been commited), I tried to call the transformations whatever the number of sync points is. I got the following issue:
- on startup with both plugins, the scope points to a zenith mirrored position (as if the pole was on south). The home position in EQMod is RA=LST+6h00 (East) and DEC = 90.00 and the TDV gives (0.0, 0.0 , 1.0). So I wonder if plugins should not be initialized with home position info in addition to the mount type. Maybe I missed that point. Here is some debug info:- When a plugin is reinitialized, the mounttype setting is lost

I found similar things, but, what I found was, once I have two points in the database, the math all seems to work correctly. My work-around was fairly strait forward, dont use any of the transforms till two points have been set. This strategy seemed to work correctly for me in both the synscan and temma driver cases, but, they are both equatorial, so I'm not considering some of the tracking details you think of, ie, not trying to use the transform results to adjust tracking on the fly. I will also admit to not testing it with southern lattitudes yet either.

I've also found, different mounts need different handling of sync processing around startup. In the synscan case, when it powers up, it initializes itself to the park position as that is set in the hand controller, and there is no way to sync it onto a different point to reset the position. But, the startup position is essentially fixed, and as long as the telescope has not had the clutches released and turned, a stored database of sync points should be valid from one session to the next when using the default park position. There are issues using the syncan controller with a different stored park position, which I have yet to spend the time and work out the solution.

The temma mount, is a completely different beast. When powered on, the temma controller has no knowledge of where it's pointed until the first sync is set, but, it does start tracking at power up. That presents an issue, because if there is a significant time delay between powering on the mount, and starting the driver, the mount will have moved some distance, and syncing on the stored park position will now have the mount offset by some distance. The simple solution to that, after starting, one needs to slew the mount, then sync it again based on a plate solution. To be technically correct, it needs to be a two step process, ie sloew to a predetemined spot in ha/dec space, solve, sync, then repeat, so that your initial sync into the mount always comes from the same point in mount co-ordinates. After doing that, a stored database should be correct.

I'm currently set up with the temma mount in the office, so I can do some more testing and code refinements for that one, but, time is at a premium over the next couple of weeks, I wont be able to do much / anything for the next couple of weeks.