I found possible reason for the problem with absolute position by reading the Windows driver source and there was a mysterious negation of the azimuth encoder delta value, which would explain the symptoms. The sequence would have been such that for example when you start from the home sensor position (let's say at azimuth 0) and set absolute position target as azimuth 30. The driver would calculate that "ok, need to move 30 degrees clock-wise" and would send appropriate command and dome would move to roughly the right place. However the missing negation of the encoder delta value would mean that the driver would think that the dome actually moved 30 degrees counter clockwise to azimuth 330 and would then conclude that it needed to do a refining move (it does that to correct for over/undershooting the wanted position, which happens sometimes even with the inertia table) of 60 degrees clockwise. Then the dome would move to azimuth 90 degrees but the counter value would still go the opposite direction and the driver would think the dome is at 270 degrees and so on...

I pushed the fix which does this negation which hopefully finally would fix this. If possible, please test that if you start by homing (after which the encoder delta is 0 and position should show correctly in any case) and then moving for example 10 degrees clock-wise and check if the absolute position reported by the driver behaves correctly or exactly the wrong way.

Read More...