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.

Hi all,
there is a more complete version of the driver at github.com/fabriziop/indi-3rdparty/tree/celestronaux_eqtrack .

After some tests I have seen that for correct equatorial pointing the Alignment Subsystem needs two sync points at least. If you have only one point, the GOTOs seem to slew in AltAz mode, even if the mount type selection is set to equatorial. So, when you are slewing toward the second sync point remember that GOTOs works in AltAz, while Mount Control box arrows obviously no.

Another trick comes from longitude/latitude non set in INDI panel > Celestron AUX > System Management. I added an error message for this case.

Any test is welcome, thanks in advance.

Hello, I'm new here. I just posted a question regarding this topic, but I can't find it. So in short again... I bought the Stellarmate Plus for my Celestron Evolution Edge 8HD with an azimutal mount. I was told that Stellarmate works with this kind of mounting but the autoguide won't at the moment. As I was also told that you are all working on it, can you tell me if it will be supported?
Thanks a lot and best regards!

About autoguide, as I told two message above, I am doing a sort of blind developing, since my scope (a CPC) is of site. Now, I am concentrated on equatorial mount functionality. I don't promise nothing, but I'll take a look to autoguide to complete the driver.

Hey Fabrizio, thanks for your answer at first and of course for your work! As you are concentrated on the equitorial mount, it is right, that StellarMate is working with the Azimutal mount isn't it? Just as mentioned autoguide is missing at the moment...
Thank you for your help!