Sorry, but I use the driver with Kstars only and I have no skill about direct scripting.

Thank you.

What would be the sequence of operations using Kstars/Ekos to use the aux driver in Equatorial North mode please?
I keep seeing this with AltRate never 0
How far apart should the first, second and third etc sync's be in RA/DEC ?

09:53:05.081: [INFO] ReadScopeStatus - RA 20.812913 hours DEC -9.423441 degrees
09:53:06.168: [INFO] Tracking - Calculated Alt -15.151356 deg ; Az 156.548387 deg
09:53:06.169: [INFO] Target (AltAz): -15.151356 156.548387 Scope (AltAz) -15.100665 156.304250
09:53:06.169: [INFO] TimerHit - Tracking AltRate -3040 AzRate 14647 ; Pos diff (deg): Alt: -0.052828 Az: 0.240476

Gene

Hi Fabrizio,

Please be advised I added the following in the 'handshake' routine
bool CelestronAUX::Handshake()
...

LOG_INFO("Connection ready. Starting Processing.");
//ESN
SetApproximateMountAlignmentFromMountType(EQUATORIAL);
return true;
}

And in
bool CelestronAUX::updateLocation(double latitude, double longitude, double elevation)
{
//ESN
UpdateLocation(latitude, longitude, elevation);
SetApproximateMountAlignmentFromMountType(EQUATORIAL);

Matching up with equmod driver
handshake:
#ifdef WITH_ALIGN
// Set this according to mount type
SetApproximateMountAlignmentFromMountType(EQUATORIAL);
#endif

LOG_INFO("Successfully connected to EQMod Mount.");
return true;

And
#ifdef WITH_ALIGN
INDI::AlignmentSubsystem::AlignmentSubsystemForDrivers::UpdateLocation(latitude, longitude, elevation);
// Set this according to mount type
SetApproximateMountAlignmentFromMountType(EQUATORIAL);
#endif

Hi,

I am the first author of the driver.
First: Thanks all of you, brave souls, for testing the driver!
Just a reminder, since I have noticed some of this mentioned in few posts:

• <strong>Never</strong> use the driver with HC active (moving, alignment etc.). It is fine to use it as a serial interface. If you do, both HC and the driver will probably get confused and the movement will be unpredictable.
• We got a <strong>nasty</strong> bug in recent release (1.8.9) - the type for the position got changed to unsigned during refactoring. The effect is fast movement below encoder position 0 on Alt axis (If you have tracking on). It is already fixed in master. <strong>Please</strong> update your testing build with this fix.
• Remember that this is a <strong>beta</strong> level driver during development. <strong>Never</strong> operate it unattended without ability to stop the erratic motion. I do not want to have your damaged hardware on my conscience. If you test with OTA on the mount have your clutches not tighten - so if the tube bumps on something it will not get damaged.
• The initial code was intended to AltAz mount, so the EQ case is newer and less tested. Be extra careful. E.g. this recent bug is probably worse for EQ - since negative Alt is rare in operation. Negative Dec - not so much.
• My new development right now is located in this PR at github: github.com/indilib/indi-3rdparty/pull/348

Thanks again for testing and continuous improvements.

I have been testing with NextStar 6SE Alt/Az and everything works BUT after slewing to a target the scope hunts up and down sometimes 10 to 15 times before it settles. This is a problem when plate solving is taking multiple exposures to refine the solve.

Ken

Do you have values set for any backlash's? In EQ mode I found ALT backlash values (like 7or would cause it to hunt forever.

Where do you set backlash Karma? I can't see anywhere on the Indi Control Panel.

This is strange. It is supposed to be:
1. Fast GoTo to the position the object *was* at one minute ago
2. Slow GoTo to the final position
This is intended to cancel out any backlash by not changing direction on approach
It should never "hunt around". Are you sure you are not running alignment tool from EKOS in the "slew to target" mode?

Sorry for any confusion. In the Nexstar itself under Menu->Scope Setup->AntiBacklash

Yes Jochym I am using "slew to target" mode in the. Ekos alignment tool, I didn't know that was an issue. Normal GoTo's do not have the problem.

My understanding of the AUX driver is that it bypasses anything in the hand controller so the backlash settings wouldn't be relevant.

On my last session under stars, I had similar issue. There was bad alignment calculation that gives me average of ~400arcsec error on goto and solve new image. After running "slew to target" in ekos alignment tab, function was not able to get error small enough jumping around and finally gave up. There was one time when error was not decreasing but increasing with every one try.
I believe this behavior is related to alignment issue that developers are aware, and trying to resolve it. Lets just give them time.