Honestly, didn't understand the question

Sorry I wasn't clear. But I assume that you wanted to move the dome from its home position to somewhere past SOUTH (not at south, but PAST it). So if the home was 90 degrees, it would have to rotate clockwise to past 180, say 185 or 190. If home > 180, then it would have to rotate counter clock wise to 175 or 170 degrees. This is what I understood from calibration by going past south.

I also got other good news, I contacted Ferran Casarramona (author of INDI MaxDomeII driver) and he will send in a dome-slit synchronization algorithm that we can use later on. Will keep you updated.

Yeah, that's right, we need just to go past the sensor which tells to the dome controller "Hey, you just passed over the South point, synchronize your position!"

The good news is really good - it is better to use production-ready bicycle than produce our own

Ok, I'll put this on hold until the slaving stuff are taken care of. But I'm curious about one thing, if the dome is initially not synchronized, how can you command to go to an absolute position near south?

Oh yeah... Actually you are right - you have to make a circle in order to ensure that you have got past South point...

Ok, well, I didn't put the calibration procedure there because I'm not sure how to do that, maybe you need to move the dome until it passes south then start using it in INDI? At any rate, the driver is ready with slaving option, you need to set parameters in meters, I'm not sure if the calculation works or not, you have to test and see.

These are the instructions as I received from Ferran:

Oh, that's cool! The only parameter which is absent in MaximDL is shutter width (I don't see it there). All the rest is the same, so theoretically it should be right. About calibration... In pseudo-code I think it looks something like this:

dome_position_2 = dome_position_1
dome_position_1 = dome_position_1 + 179 degrees
move_dome(dome_position_1)
dome_position_1 = dome_position_1 + 2 degrees
move_dome(dome_position_1)
move_dome(dome_position_2)

I hope you understand the trick, I thought it in this way because dome can move in both directions, but we want it to move all 360 degrees only in one direction

Ok, here we go

1) Relative Position and Absolute Position are not working as expected - I give a value, but from log I can see that a very strange value is sent instead (difference between current and new one is very small). Basically, right now it's nearly not moving, just few centidegrees. Several times I saw that the last number in d#azi**** command was missing. As far as I can understand the strange values can be related to correction algorithm
2) Autosync threshold is the level of acceptable positioning error, yes?
3) There is an interesting moment with sync... After powering up the dome it replies on the d#getazim requests with d#azi****, and not d#azr****. I found the explanation - sync. After syncing ithe dome, it switches to d#azr**** format. The pseudo-code I described btw is working as expected
4) Measurements tab. As I could see it's impossible to put negative numbers for displacements (in MaximDL it is possible), but actually I need to set negative numbers in my configuration

Regarding the procedure, why can't we do:

dome_position_1 = dome_position_1 + 185 degrees

Doesn't that guarantee it will hit the south sensor?

For a simple reason - it will do 175 degrees move The dome is capable to move in CW and CCW directions, but it's not the user who decides in which direction to move, the dome decides by itself (smart bastard! )

Hmmm ok, well, test the updated driver when you can

I got today a whole bunch of terrible paper work, so most probably I will be back at testing only next week, in the second half