Hey All,

Quick one (a problem I had a long time ago, which fixed itself.. but now picking things up again i'm having).

My KStars direction / movement is inverted when using ekos to control the mount. My guess is something to do with the southern hemisphere, mount is celestron wifi ALTAZ.

To simplify things in terms of logs, I did a quick connect, and a couple of seconds of *UPWARD* movement. The mount itself moves correctly upward. Logs attached.

Mount location seems to set correctly (KStars location also set to Sydney, Australia).
[2022-06-03T13:54:30.356 AEST INFO ][ org.kde.kstars.indi] - Celestron WiFi : "[INFO] Observer location updated: Latitude -33:54:59.0 (-33.92) Longitude 151:16:59.0 (151.28) "

However in diving into things, it seems the problem is the encoder direction might be inverted? As (see below) the AL output is decreasing rather than increasing.

[2022-06-03T13:55:21.398 AEST DEBG ][ org.kde.kstars.indi] - Celestron WiFi : "[ALIGNMENT] Axis2 encoder 16749335 -> AL 0.5983° "
[2022-06-03T13:55:22.500 AEST DEBG ][ org.kde.kstars.indi] - Celestron WiFi : "[ALIGNMENT] Axis2 encoder 16747967 -> AL 0.6276° "
[2022-06-03T13:55:23.603 AEST DEBG ][ org.kde.kstars.indi] - Celestron WiFi : "[ALIGNMENT] Axis2 encoder 16748597 -> AL 0.6141° "
[2022-06-03T13:55:24.713 AEST DEBG ][ org.kde.kstars.indi] - Celestron WiFi : "[ALIGNMENT] Axis2 encoder 65600 -> AL 358.5924° "
[2022-06-03T13:55:25.808 AEST DEBG ][ org.kde.kstars.indi] - Celestron WiFi : "[ALIGNMENT] Axis2 encoder 168330 -> AL 356.3880° "
[2022-06-03T13:55:26.911 AEST DEBG ][ org.kde.kstars.indi] - Celestron WiFi : "[ALIGNMENT] Axis2 encoder 231990 -> AL 355.0220° "

Am I just completely down the wrong path here? The actual conversion from encoder numbers to AL seems to be correct from my calculation, so is it either that isNorthHemisphere() isn't firing correctly (I haven't found where that sits exactly yet), or does this model of mount have the encoder output reversed?

J

tl:dr:
- From cold power on from a fresh install of the StellarMate beta stream, it slews to the correct target... sort of...
- If it tries to slew more than about 15-degrees clockwise of center on the RA, it abruptly stops motion on that axis.
- If I run alignment in an external app, then switch back to KStars/Ekos/StellarMate, it no long hits the stop... but it also does not slew to the correct location.

My SD card died, so I had to grab a new one and get it up and running again so I could get logs.
I got tired of setting my stuff up in the in the cold, so I'm testing by roughly polar aligning my mount and checking positions using SkySafari.

In order to get past the short artificial stop rotating east on the RA, I disconnected/stopped indi/ekos, and ran a scope alignment with SkySafari.
In the process, the StellarMate seemed to crash during that time, so I powered it off and on again before I could connected to it and start Ekos/Indi.
For good measure, I mash the 'sync gps' button in the StellarMate app; location in the CGEM-II looks almost right... except is show 240.xx degrees longitude instead of -119.yy (I'm not sure if that's normal).
Upon connecting, KStars shows the scope position somewhere in the south; way below the horizon (at 259P/Garradd).
So, I select Polaris and Sync the scope location.

In the _after_align.log...
I try to go to Merak (sort of near zenith), but it hits a hard stop (if I had my scope attached to the mount, it might have bumped the tripod).
So, then I send it to Pollux, and it kind of gets in the neighborhood.
It tell it to park, and it goes 90-degrees clockwise of the home position for both axes.

So, then I power the mount off and on again, and close/re-open kstars (_no_align.log)
It comes up with the cgem-ii pointing at Polaris this time, and correctly slews to Pollux and Vega... but hits an the artificial stop slewing to Merak (about 15-ish degrees past center on the RA).

I should receive a Celestron CGX mount in a couple of weeks and I would be finally able to test this in the observatory to correct any issues in the driver.

Same issue as Rob. There's a phantom "hard stop" just past the meridian. There's no deceleration, just an instant stop (like it hit something) and even the virtual hand controller won't move past it.

If I align on a star in the west, the hard stop is just east of the meridian, and if I align on a star in the east, the hard stop is just west of the meridian. Wish I could figure out where the logs are, I'd upload them, lol.

Environment: RaspberryPi4-4GB (32bitOS)

Self-made USB serial driver
www.cloudynights.com/topic/812944-homebr...-for-aux-port/page-5 (works on Windows)

Like the SkyWatcher-ALTAZ driver, it does not work with a USB connection.

It got worse in 1.9.6.

-Cable is not recognized. (Previously it was recognized, but I couldn't connect.)



Attach the log.
I want you to improve as soon as possible. .....

Hi,

I'm experiencing the same problem reported by Jack in his post above, www.indilib.org/forum/development/8246-i...html?start=252#83334.

My KStars direction / movement is inverted when using ekos to control the mount. Like Jack I'm in the southern hemisphere. My setup is a CPC925 on an equatorial wedge, using Astroberry to control the equipment. Mount location is set correctly (KStars location also set to Kyneton, Australia).

In addition to what Jack has noted in his post, I've found the following:
- after syncing to three stars I can successfully do a goto to those stars from Kstars.
- doing a goto to an un-synced star, after the above three star alignment, sees the telescope move in the wrong drection, as noted by Jack.
- after attempting to go to an 'un-synced' star, if I then do a goto back to a synced star, the location marker for the telescope in Kstars is no longer showing at the location of the synced star on Kstars even though the telescope has correctly returned to the poistion of the synced star.
- after syncing to a star, if I use plate solving to get more accurate positioning of the star, the initial plate solving result shows th ealignment is close, but then as it tries to move closer to the target star, it ends up moving further away.

I'll try and capture some of this behaviour in logs next clear night.

Any assistance in understanding and resolving this problem would be greatly appreciated.

Alistair

Please open a new topic for this. Need to close this thread as development of the driver is complete. Now just need to fix bugs and make fine improvements.