Hi Jasem,
You say "start by slewing to a nearby star about 20 degrees away". I don't know how to do that. I assume that one would use the buttons on the virtual hand controller ( I do not have the physical hand controller connected) but this results in wild results. There is a comment in the code indicating that coordinate handling is not complete for these controls. The goto functions also give strange motions apparently because the driver does not have enough alignment info yet. I'm interested in helping but I have a big learning curve to climb.

It is a big loss if the author of the Alignment module is not active now. I would love more details about the implementation. Reading and learning from code makes a hard task much harder.

Read More...

So looking at celestronaux.cpp,

bool CelestronAUX::slewTo(INDI_HO_AXIS axis, uint32_t steps, bool fast)
{
    // Stop first.
    trackByRate(axis, 0);
    AUXCommand command(fast ? MC_GOTO_FAST : MC_GOTO_SLOW, APP, axis == AXIS_AZ ? AZM : ALT);
    m_AxisStatus[axis] = SLEWING;
    command.setData(steps, 3);
    sendAUXCommand(command);
    readAUXResponse(command);
    return true;
};

My long tern goal is to learn to help rather than ask for help, My short term goal is to get Ekos to control my CGX mount. I'm brand new to astrophotography so I'm learning everything at once. So part of what I see as problems may just be my bad expectations about how the system should behave. There is clearly an interaction between Ekos tabs and Celestron_aux driver. The driver depends on the alignment module and the aux code which is what actually talks to the mount.

So here is my immediate question. I can "sync" the mount to a location, say Polaris, so the mount knows its current position (encoder values) map to this particular (RA,DEC). I can save this config as the parking position and the mount will reliably slew to this spot on Park. Cool. Now with no other alignment done, I think I could use Kstars to select and 'goto' another (RA,DEC). My expectation is
1. Kstars says to the controller 'goto RA2, DEC2.
2. The controller knows it is at RA1, Dec1 so, to go to RA2 DEC2 it computes the change in RA and DEC to get to RA2,DEC2.
3. The controller says to the mount, thru aux command, to rotate RA by delta-RA and DEC by delta-DEC.
4. The mount knows how many encoder steps per delta-angle so it happily applies the delta-RA and delta-DEC.
Of course the position is close, but not the real location because the single synced position is only roughly aligned manually during setup.

The observed behavior when I try this is mixed. Some times the motion is reasonable but maybe East-West is reversed? Other times, I abort the motions because the scope is going to hit the mount. So which components know what when? The alignment module is keeping track of encoder values, so maybe the mount isn't as smart as I expect and the aux command to the mount is goto RA-endoder value and DEC-encoder instead of apply a delta-angle. Reading the code, or docs (!) can educate my expectations. Or you can spoon feed me! I expect your going to tell me I have to do the entire alignment procedure first, but why?

My second immediate question is why can't I use the manual slew controls to move the mount. What does a buttons labeled N,S,E,W mean when I have a mount that moves in RA,DEC? Using the buttons doesn't move in a way that makes sense.


Thanks!

Read More...

I am reading the code trying to reverse engineer the algorithms used. Reading code sucks. I find docs on how to use it but not how it works.

Thanks!

Read More...

I am finding frequent use of %.f as the number format specifier for numeric values. I don't think that is a valid specifier. The dot '.' starts the precision field and the docs I am finding indicate that an integer value must follow the dot. An example of this is in libindi-3rdparty/indi-celestronaux/celstronaux.cpp. and in libindi ccd_simulator.cpp

The INDI standard, docs.indilib.org/protocol/INDI.pdf, is annoyingly vague about this, saying only "A numberFormat shall be any string that includes exactly one printf-style format specification appropriate for C-type double
or one INDI style "m" to specify sexagesimal...". I am sure there are some printf implementations for which this is valid but I don't think it is standard. I know Java doesn't understand the intent of "%.f".

I am slowing relearning C/C++ and INDI lib, being motivated by problems I am having with the indi_celestron_aux driver. Maybe I'm all wet but what's up with this number format specifier?

Read More...

I don't see mount module documentation with the Ekos doc at docs.kde.org. In particular:
On INDI Control Panel for Celestron AUX mount
1. What does "On Set": Track, Slew, or Sync mean?
2. What does "Home": AZ/RA, AL?DE, All do?
3 On Motion Control Tab What are the effects of Motion N/S, Motion E/W and Reverse.

On Mount Control, for GEM mount, I presume up/down arrows are for DE and left/right for RA. That seems to be the case for my Celestron CGX mount, However when I slew with one axis, I see both RA and DE values changing.

Read More...

Thank you! That is really helpful. That information needs to be on the Kstars repo Readme. I'm up and running from my local build (after ~7 hours of build time)

Read More...

Thank you for replying. Talking about this helps. (This sounds like therapy).

I have a RPi4-4G running StellarMateOS version 1.7.5 based on Debian 11 (bullseye).
I am able to build INDI and Indi-3rdparty on the Pi. I am not able to build Kstars

These dependencies listed for Debian build are not found.
cfitsio-dev
kio-dev
kdoctools-dev

I did find this package.
added libkf5doctools-dev

cmake fails on "Could not find a package configuration file provided by StellarSolver". I haven't found an obvious package to satisfy this dependency. How to get by this?

Thanks again!

Read More...

I want to do indi development. After building indi and indi-3rdparty from source on Raspberry PI, Kstars fails to launch with kstars: symbol lookup error: kstars: undefined symbol: timestamp. Maybe kstars does not dynamically link the new library version?

Read More...

It seems that there is good compatibility between Ekos and Star-Watcher mounts using the EqMod driver based on feedback here www.indilib.org/forum/mounts/13191-what-...full-automation.html. How about iOptron mounts? Do they use the EqMod driver as well? (I don't see an iOptron-specific driver amongst the 3rd-party drivers).

Read More...

I can build indi on my mac. When trying to run cmake for indi-3rdparty, it fails because it can not find INDI include directory. For linux, the remedy is

sudo apt-get -y install libindi-dev

Using the manual control buttons, Up/Down changes Axis-2 Declination only as indicated by encoder values and Left/Right changes Axis-1 RA. However, the Eq Coordinates shown on driver's main control screen and on KStars map both change simultaneously in some way that is mysterious at the moment. Is this a configuration issue or a bug?

I am using a direct connection to the USB port on the CGX mount and not going through the hand controller, it that matters.

Read More...