Luzik, doing as you say my mount dips 5 degrees in Altitude, slews to 90 degrees in azimuth and then goes up 5 degrees to the requested position.
All correct and the position shown on the Hand Controller and Kstars is also correct.

After connecting to your mount are you doing a sync at AZ 000:00:00, ALT 00:00:00 ?

I am using the 0.8 version of the driver.

Ken

The trick in my bug report is not to sync to default/initial mount position. .. or maybe it is my bad because this is mandatory ?
In other software it is normal, that you point first star do first sync, second star, second sync .... without any sync to alt 0 az 0

Luzik, even if I do exactly as you do the mount still maintains the 20 degrees after slewing, doesn't go up to 40.

How are you moving to the 20 degrees altitude, with the hand controller or the Ekos Mount Controller?

When you switch on the mount the encoders are at 0,0 (north on the horizon) as shown on the Hand Controller BUT Kstars shows the azimuth at 180 degrees. This is why I set the values 0,0 on the Ekos mount controller and do a sync. I still haven't got my head around the code sufficiently to change this.

Oh that odd, so @Fabrizio maybe will help diagnose that. I can provide more debug logs if needed. I believe that this issue is source of the alignment problem with both alt/az + gem mounts.
Thank you Kenkelso for testing !
My hand controller is not connected to the mount. My evolution have builtin wifi interface. Maybe later I will try with wires.

Yes mine too, but from my experience with other alignment software I know that I can totally ignore that init coordinates. Now I do understand why you syncing to that point

I’m no expert here, but I’m wondering if we should try to have a standard that we’re testing against? Earlier in the thread there is a process that Fabrizio has asked to follow. I replied with a post that confirms the steps. This is the process that should be successful, but so far not on all mounts.

If you’re going to try a different approach, at least try the default first.its great that we have more people testing.

Thoughts?

The original driver developer wrote:

// libnova indexes Az from south while Celestron controllers index from north
// Never mix two controllers/drivers they will never agree perfectly.
// Furthermore the celestron hand controller resets the position encoders
// on alignment and this will mess-up all orientation in the driver.
// Here we are not attempting to make the driver agree with the hand
// controller (That would involve adding 180deg here to the azimuth -
// this way the celestron nexstar driver and this would agree in some
// situations but not in other - better not to attepmpt impossible!).

I do follow this guide, just my known position is AZ 0 ALT 20.

It should be good as any other on sky. Next sync point do not have any sense because all is contaminated with that false first.

I believe that after first sync move is calculated from alt 0 not from my synced point but can't find a clue where to search it in drive source

You can use get_hrz_from_equ and get_equ_from_hrz functions in indicom, they don't have the azimuth issue.

The driver comment above is referred to motor encoder reading in ReadScopeStatus method.

Current code

More Celestron compliant code

Hi Fabrizio: I notice that your code fragment is from the main 3rdParty branch, I am playing with your 0.8 version from your fork and see that the ReadScopeStatus method has been changed quite a bit.
Anyway I patched is like this:

double Az = double(GetAZ()) / STEPS_PER_DEGREE;
double Alt = double(GetALT()) / STEPS_PER_DEGREE;

Az += 180.;
if (Az > 30.)
Az -= 360.;

ln_equ_posn RaDec = RaDecFromAltAz(Alt, Az);

Which caused havoc, sure enough when the driver connects KStars shows the scope pointing north but GoTos from there go to an indeterminate point for which I cannot at the moment work out the logic of.

I don't personally have a problem with the driver thinking the scope is pointing South on connection as it's simple to punch in 0,0 co-ordinates and do a sync. It's not worth a lot of effort to change the behaviour and for me the driver is looking very good.

Ken

Hello, what's the status for this driver now? Also, any ideas if guiding would be supported fully?

The pointing for equatorial mounts was added to the driver. Since my scope is offsite, I can't do real tests. Therefore, I rely on the tests made by the friends of this thread.
About guiding, I can take a look at it. The same apply for testing.