Thanks Fabrizio! Sounds like i've just been missing a step.

When you say HC here "using the Motion Control HC of Kstars".. could you just clarify what you mean by that? I may just be a bit daft but unsure where exactly I should be looking!

Cheers,
Jack

You have to (1) launch Kstars, (2) open Ekos, (3) start INDI, (4) connect to your scope. Now it should appear the mount tab in Ekos. (5) Open it and click on the (6) "Mount Control" button. At this point, the window of the "Mount Control" appears, a sort virtual hand control. To make the requested SYNC operations, put the RA/DE coordinates given by the other system into the RA/DE text boxes of Mount Control and click there on the "SYNC" button.

Fantastic thankyou, i'll give that a go tonight.

I had tried by right clicking on the main map at the location and hitting sync, but that wasn't doing the trick. Hopefully this does!

Thanks,
Jack

Ok, seemingly still no luck.

I ignored any external alignment (it's now daytime) and just tried to sync two approximate sky points within KStars as described. This started with the scope pointing approximately toward menkar, aligning that, then slewing it (using kstars) to the west approximately where Enif would be and doing a second sync.

The telescope pointer within kstars started due north on the horizon, then swung west when i slewed the scope west. However it has not taken into account either sync point.

I've attached the log for the quick test run. Also added a picture of the (i think) relevant sections cut out if thats easier. And finally have added the alignment section of the indi control panel, showing 3 sync points registered.. and the alignment subsystem active.. but not much else?

Edit: Just in case 2 points wasn't enough.. added another vague sync point at Apheratz.

Thanks for the pointers so far... hopefully I can get things sorted eventually!

Cheers,
Jack

Thanks Jack for the detailed info! Great job on that. I don't think using the driver should be THIS difficult.

@Fabrizo, if AUX already provides RA/DE (which I presume are final post-alignment processed coordinates), why isn't the driver is using these values as-is if no sync points are defined? Sorry if my question is stupid, I really need to dig deeper into this driver. I thought that we deal with encoders values like SkyWatcher when we're using AUX.

Hang on a minute. I think I have a breakthrough!

I had assumed that the alignment subsystem was active due to the green light to the left of it. However I decided to click on it anyway... and.... bam KStars was pointing roughly where it should be! Image attached of how it looks before and after (bold is apparently on?).

Have tried another quick test from scratch, but clicked that after connecting and before syncing.. and things are happening! (yay!)

Is this alignment subsystem not active by default? And just a step I was missing?! Hopefully this helps others if they have a similar issue!

Edit: Also the main difference in the logs.. is this "[INFO] ReadScopeStatus - TransformTelescopeToCelestial failed " is now missing. I case that helps diagnose things driver development wise. Also happy to provide more logs / testing etc to help you guys driver side if need be!

Jack

Great, Jack. Thanks for you testing. You are probably using version 0.7 of the driver. Here github.com/fabriziop/indi-3rdparty/tree/celestronaux_eqtrack you can find the source of the last version 0.8 (WIP), where the alignment subsystem is enabled by default and warning messages are given if some info is missing to the subsystem for working properly.

Fabrizio

Exactly! In this case the alignment conversion failed because the subsystem was disabled. Otherwise it manages correctly the zero sync point case.
In the last driver version, I have enabled by default the subsystem. The green light at the enable subsytem switch fooled me too.

Thanks Fabrizio, good to know it's sorted out in the next version.

I'm using the drivers through a stellarmate OS install, so won't touch the specific driver and wait for an update through that (and in the meantime enable the subsystem).

Happy to have an answer after a few days of testing though.. so thanks for the pointers! (Of course its now cloudy haha).

Cheers,
Jack

Hmmm why was it green then? This needs investigation.

CordWrap is the same, green light stays on all the time no matter what the state.

BTW I still have no issues to report using the driver in Alt/Az mode on my NexStar 6SE.

Ken

I believe that green light indicate that value (on/off/any) of param (align subsystem/cord wrap/any) is valid/fresh. Not state of param itself.