I am still trying to get the build system back together. However, just to clarify. When I did the initial implementation I made a decision to leave the one and two sync point alignment stuff up in the drivers. I think now that that was the wrong decision as it is obviously causing confusion.

So at the moment the default alignment stuff is only used in the driver. Bear with me. I hope to be building stuff sometime tomorrow.

Roger

Ok, that was the trick. I now use standard sync when there is only one sync point and starts using the alignment subsystem when there are at least two points. I just made quick tests using the simulator and everything seems ok now: both plugins in both hemispheres (this was because I added erroneous code while trying to solve initialization issue). So the alignment subsystem may be used for equatorial mounts simply by using the HA/Dec telescope coordinate system (which was indeed what we were waiting). Obviously this will require more testing.
A point I noticed is that the plugin uses ln_get_julian_sys, but the driver manages its own lst/julian date based on the updateTime from kstars. There is a 6 seconds difference on my machine in the usual case where everything runs on the same hardware (I don't know why, kstars init, opengl pipeline,... ?). I wonder which source of time should we use when writing drivers? I also noticed a GPS device appears, it could be used to compute lst, maybe the reason why it is there.

Still not got my build system working.

However, to clarify, my initial idea for the alignment subsystem was that it would be agnostic to the mount type. So it would just treat an equatorial mount as a very poorly levelled altaz. So the basic transformations would be to and from a rotating celestial coordinate reference frame and a non rotating telescope reference frame defined by the axis encoders. The only time that the mount type would be used would be to generate dummy sync points when there were not enough sync points in the database to do the standard alignment transformations. I have got a suspicion that I got half way through moving the code to do this from the example drivers back into the alignment subsystem before I gave up due to lack of interest.

I was not sure if the telescope reference frame should be fixed or rotating when using the Alignment subsystem. Actually this is just a convention. Eqmod Align uses the rotating option yielding a telescope (Ra,Dec) -> Celestial (Ra,Dec) transform when tracking, and the inverse transform in gotos. As an equatorial mount is supposed to track in RA at celestial rate, the telescope (Ra,Dec) remains constant when tracking, and the align system would show a moving celestial (Ra,Dec) over time, corresponding to the alignment errors of the mount. But I also wonder if alignment may not be used when tracking too as you did in the skywatcherAPIMount driver for altaz mount: I want this celestial (Ra,Dec) in the next second, give me the corresponding (HA,Dec) so I adjust Ra,Dec tracking speed accordingly. In that case the code would be almost the same for both altaz and equatorial mount, only the TelescopeDirectionVectorFrom/To functions would differ. Is this right ?
I think I will try that based on your driver.

I am out most of the day today. So I will not get a chance to look at this until later. I got things compiling last night. Forcing my poor old brain to go back to this has reminded me of a couple of comments I saw in the change log of a program way back in the early 1970's when I started in the computer industry. It went something like this.

25/12/1971 - First Release
25/12/1972 - When I first wrote this code only two people understood it, god and myself... Now god only knows!

HAHA.

I started working on integrating the alignment system into the synscan driver last month, and had to set it aside because life got busy again. Hoping to get back into it again before to long. What I found was, when I set things to equatorial, it wasn't working out, lots of errors. But, when I left it in default alt/az, then just did alt/az conversions in my code before letting calls go thru to the alignment module, it all seemed to be working.

I think the issue I was having is essentially the same as mentioned earlier, when only one sync point was set, I was getting all sorts of errors. I dont think it occurred to me to get 3 or more sync points in before actually letting the calls pass thru.

OK guys I finally got my head round it. The initialisation code in BasicMathPlugin.cpp is fundamentally broken for the equatorial case. Jazeem, you were on the right track. But you totally confused me with your comment on your checkin about using the Hour Angle in the alignment subsystem. Coordinate transformation in the alignment subsystem is always done in the local horizontal reference frame of the observer. It is the responsibility of the driver to convert the returned TelescopeDirectionVector to something that is useful to the mounts axis driver mechanisms. There are functions defined in TelescopeDirectionVectorSupportFunctions.h for this purpose. Jean-Luc is using TelescopeDirectionVectorFromLocalHourAngleDeclination and LocalHourAngleDeclinationFromTelescopeDirectionVector in the eqmod driver, this seems correct to me.

I have attached a modified file. It would be great if you guys could check it out and let me know how you get on.

Roger

I've been tied up with company over the holidays, but, I will check this out over the next day or two. I was having issues using the alignment subsystem trying to integrate it into the synscan driver as per the document in the alignment stuff. I'll try again over the next few days.

I wouldn't say it was a 'lack of interest', so much as a 'lack of time'. Shortly after you started that, we went thru some big changes here, first we dealt with paliative parents for a few months, twice, then we ended up moving for my wife's new job, again twice. That burned up two years where there just wasn't time for any of this stuff around here.

So, I re-read this, and tried something on a lark. Instead of trying to set an equatorial mount type, I just left it in the 'agnostic' or default whatever it chose. Then do NOT call into the transforms until I've set two sync points. VOILA, it suddenly 'just worked', or at least the numbers appear to 'make sense'. I'm now syncing using the eq transforms ( TelescopeDirectionVectorFromEquatorialCoordinates ) but not making calls to transform the ra/dec telescope values till there are at least two sync points in the database, then printing the 'before and after' values. By carefully setting sync points 'a little bit off', I can see the before and after numbers actually look sane now.

I think where I got befuddled the first time around, I was calling into the transformations, expecting them to fail if the subsystem couldn't resolve, and was getting what amounted to garbage back when only one or no sync points were in. But, if I treat it as 'mount is correct' until a two star alignment is complete, ie, at least two sync points, now I'm getting what appears to be properly corrected data back. FWIW, I did plug in your updated basic math module you posted the other day before I started this today.

I've got a whole bunch of cleanup and 'kludge removal' to do in this driver now, and then I'll commit a new synscan variant that works with the normally configured handset, and includes the alignment stuff. My end goal with this then, using the handset, we should be able to get functionality equivalent to using eqmod.

Again, for me, using the syncan is just my test case, to make sure I've got it all working and understood. My takahashi mount is still in storage, but it's due to come out of storage in a few weeks, and I want to get the alignment stuff working in the temma driver once it comes out.

Hi Jerry,

My whinge about lack of interest was certainly not directed at you. It just seemed that apart from you nobody else was interested in using the code in a driver. I have also had other stuff going on. I had a number surgical procedures performed, which seem to have left me with a neurological problem that the experts tell me should be temporary. Unfortunately it has left me unable to sustain concentration for any long period of time. This makes coding a bit difficult. So I am feeling at bit dull and slow.

The code I was referring to in the drivers probably should stay there for the time being as it deals with the case of when the transform calls return an error. The main reason that error returns are made is that the sync database is empty.

What could really do with testing is this special case code in the math plugins to handle when there is one sync point and when there are two sync points. Of course more general testing of the accuracy of the plugins would be desirable as well.

I hope things have settled down for you now.

Happy New Year

Roger

I struggled with the implementation some time back, kind of gave up as there was a lot of other stuff to do as well. Now that I have it working correctly, I am in the process of cleaning up the code, and getting rid of a LOT of hacks and kludges I had in there for testing various things.

As I see it, I have two 'special cases' to figure out. First is using the synscan mount, which does not have the ability to send a 'sync' to the hand controller. What I did for now, is just send the first two sync points into the database, then start using the transforms when there are 3 or more sync points in there. That is working well, but with this setup, the first two syncs appears to have no effect, ie nothing changes in terms of what the client is seeing in RA/Dec returns. Once I'm finished cleaning things up here, I can work on those two special cases.

The other situation will be when I start integrating this into the temma2 driver for my tak mount. It's a slightly different case, because with that one, it IS possible to sync the mount, is actually necessary to provide it with one sync point to get started. For that case, the first sync will go into the mount, and the database. But once the mount is synced once, no more sync points should be pushed thru to the mount, that'll effect the model in a very bad way because database and mount will end up out of sync with each other.

Right now, I'm just leaving it run with the basic math plugin, and I expect to be done the cleanup later today, then I can really start to exercise things here.

Since this thread was originally about EQMod, I've started a new thread about Synscan driver. I have just committed a set of changes which incorporate the alignment subsystem into the synscan driver, and it appears to be working quite well on what testing I can do here on the bench without getting a telescope under the stars. That's not likely to happen tonite, altho the forecast is 'clear', it's going to be foggy, the fog is already starting to form. It was 'clear' last nite too, but, only when you got up above the fog layer.

Such is life at times.