×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

AX-GTi error messages on start of Ekos

  • Posts: 21
  • Thank you received: 0
Well, sadly I guess I've messed everything up. I'm still at the point where I cannot run Ekos with the Canon driver. I tried removing stuff that I thought I had added, and the Stellarmate Software Updater says I'm completely up to date (v1.7.1, channel stable) but the update_indi_drivers command is failing differently now and I don't know how to fix it after all this messing about short of blowing the whole Stellarmate installation away and reloading the whole OS which would lose all my NFS setting and other stuff that I currently care about but that's probably what I need to do.

stellarmate@stellarmate:~ $ update_indi_drivers
Hit:1 raspbian.raspberrypi.org/raspbian buster InRelease
Hit:2 archive.raspberrypi.org/debian buster InRelease
Hit:3 ppa.stellarmate.com/repos/apt/stable buster InRelease
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
build-essential is already the newest version (12.6).
git is already the newest version (1:2.20.1-2+deb10u3).
libboost-dev is already the newest version (1.67.0.1+b1).
libboost-regex-dev is already the newest version (1.67.0.1+b1).
libcfitsio-dev is already the newest version (3.450-3).
libcurl4-gnutls-dev is already the newest version (7.64.0-4+deb10u2).
libdc1394-22-dev is already the newest version (2.2.5-1).
libfftw3-dev is already the newest version (3.3.8-2).
libftdi-dev is already the newest version (0.20-4).
libftdi1-dev is already the newest version (1.4-1+b2).
libgps-dev is already the newest version (3.17-7+b1).
libgsl-dev is already the newest version (2.5+dfsg-6).
libjpeg-dev is already the newest version (1:1.5.2-2+deb10u1).
liblimesuite-dev is already the newest version (18.06.0+dfsg-1+b1).
libnova-dev is already the newest version (0.16-4).
libtiff-dev is already the newest version (4.1.0+git191117-2~deb10u4).
libusb-1.0-0-dev is already the newest version (2:1.0.22-2).
zlib1g-dev is already the newest version (1:1.2.11.dfsg-1+deb10u1).
cmake is already the newest version (3.16.3-3~bpo10+1).
librtlsdr-dev is already the newest version (0.6-1+rpt1).
libgphoto2-dev is already the newest version (2.5.29-stable~202205251835).
libraw-dev is already the newest version (0.20.0-stable~202201171501).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Cloning into 'indi-3rdparty'...
remote: Enumerating objects: 2803, done.
remote: Counting objects: 100% (2803/2803), done.
remote: Compressing objects: 100% (2032/2032), done.
remote: Total 2803 (delta 1014), reused 1707 (delta 665), pack-reused 0
Receiving objects: 100% (2803/2803), 116.39 MiB | 5.75 MiB/s, done.
Resolving deltas: 100% (1014/1014), done.
Checking out files: 100% (2756/2756), done.
-- The CXX compiler identification is GNU 8.3.0
-- The C compiler identification is GNU 8.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Performing Test COMPATIBLE_FORTIFY_SOURCE
-- Performing Test COMPATIBLE_FORTIFY_SOURCE - Success
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29")
-- Checking for module 'libavcodec>=57.64.101'
-- Found libavcodec, version 58.35.100
-- Checking for module 'libavdevice>=57.1.100'
-- Found libavdevice, version 58.5.100
-- Checking for module 'libavformat>=57.56.100'
-- Found libavformat, version 58.20.100
-- Checking for module 'libavutil>=55.34.100'
-- Found libavutil, version 56.22.100
-- Checking for module 'libswscale>=4.2.100'
-- Found libswscale, version 5.3.100
-- Found FFMPEG: /usr/lib/arm-linux-gnueabihf/libavcodec.so;/usr/lib/arm-linux-gnueabihf/libavdevice.so;/usr/lib/arm-linux-gnueabihf/libavformat.so;/usr/lib/arm-linux-gnueabihf/libavutil.so;/usr/lib/arm-linux-gnueabihf/libswscale.so, /usr/include/arm-linux-gnueabihf
-- Since FFMPEG was found, INDI Webcam Driver can be built
-- Found USB1: /usr/lib/arm-linux-gnueabihf/libusb-1.0.so (found version "1.0.22")
-- Performing Test USB1_HAS_LIBUSB_ERROR_NAME
-- Performing Test USB1_HAS_LIBUSB_ERROR_NAME - Success
-- Found CURL: /usr/lib/arm-linux-gnueabihf/libcurl.so (found version "7.64.0")
CMake Error at cmake_modules/FindINDI.cmake:285 (message):
Could not find INDI include directory
Call Stack (most recent call first):
libapogee/CMakeLists.txt:26 (find_package)


-- Configuring incomplete, errors occurred!
See also "/home/stellarmate/Projects/build/indi-3rdparty/CMakeFiles/CMakeOutput.log".
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target 'install'. Stop.
-- Found FFMPEG: /usr/lib/arm-linux-gnueabihf/libavcodec.so;/usr/lib/arm-linux-gnueabihf/libavdevice.so;/usr/lib/arm-linux-gnueabihf/libavformat.so;/usr/lib/arm-linux-gnueabihf/libavutil.so;/usr/lib/arm-linux-gnueabihf/libswscale.so, /usr/include/arm-linux-gnueabihf
-- Since FFMPEG was found, INDI Webcam Driver can be built
CMake Error at cmake_modules/FindINDI.cmake:285 (message):
Could not find INDI include directory
Call Stack (most recent call first):
indi-eqmod/CMakeLists.txt:10 (find_package)


-- Configuring incomplete, errors occurred!
See also "/home/stellarmate/Projects/build/indi-3rdparty/CMakeFiles/CMakeOutput.log".
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target 'install'. Stop.
stellarmate@stellarmate:~ $
1 year 8 months ago #84203

Please Log in or Create an account to join the conversation.

send support email to This email address is being protected from spambots. You need JavaScript enabled to view it.
1 year 8 months ago #84204

Please Log in or Create an account to join the conversation.

  • Posts: 28
  • Thank you received: 0
Hi Jasem
From my angle I've reached the end of the line with Star Discovery mount and indi.
The SkyWatcherAltAzSimple code does not have an option for disabling the aux. encoders (seems skywatcher api it uses is about 10 years old and the telescope model does not have an option).
The AzGti mount does report on the aux. encoders but does not seem to have an option to disable (so struggle to work out how you would carry out an initial align)!
The official Skywatcher synscan pro app does have an option and the default setting is disabled!
I would agree that without some major investment in time attempting to support this mount is not practical.

Don't worry I still think Indi and Ekos are great and will continue to use them on my main setup, but not with my AltAz mount

Regards
Paul
1 year 8 months ago #84253

Please Log in or Create an account to join the conversation.

I see that EQMod mount supports reading and toggling AUX encoders, but such option does not exists on the SkyWatcher Alt-Az driver. AUX encoders are NOT used in the Alt-Az driver at all, so how would toggling them on/off would have any benefit?
1 year 8 months ago #84255

Please Log in or Create an account to join the conversation.

  • Posts: 28
  • Thank you received: 0
Hi Jaseem
Yes found it
if (mount->HasAuxEncoders())
{
if (AuxEncoderSP && strcmp(name, AuxEncoderSP->name) == 0)
{
IUUpdateSwitch(AuxEncoderSP, states, names, n);
if (AuxEncoderSP->sp[1].s == ISS_ON)
{
AuxEncoderSP->s = IPS_OK;
LOG_DEBUG("Turning auxiliary encoders on.");
mount->TurnRAEncoder(true);
mount->TurnDEEncoder(true);
}
else
{
AuxEncoderSP->s = IPS_IDLE;
LOG_DEBUG("Turning auxiliary encoders off.");
mount->TurnRAEncoder(false);
mount->TurnDEEncoder(false);
}
IDSetSwitch(AuxEncoderSP, nullptr);
}
}

My mount does have aux encoders (as does the AZGti), and as I say the Synscan app supports this for my mount and turns them off.
The issue is
1 switch on mount
2 connect in Ekos
3 Issue goto star
4 But the mount will not actually point at the star, so using either the arrows key of slip the clutches point at star
5 Sync
But the mount slews back to position at step 2, it remembered this I tried 'clear model' but still creeps back to position at 2.

As I say don't worry there aren't many people using an Alt/Az mount in Alt/Az mode for imaging...
Thanks
Paul
1 year 8 months ago #84257

Please Log in or Create an account to join the conversation.

I'm using AZ-GTi with Canon camera and it works fine. I use plate-solving in Ekos and it centers the target just fine. I don't see how AUX encoders are involved at all in this. The driver is not utilizing them, so why should they matter? What I can confirm is that I can plate-solve and center objects just fine in AZ-GTi WiFi.
1 year 8 months ago #84258

Please Log in or Create an account to join the conversation.

  • Posts: 28
  • Thank you received: 0
Hi Jasem
Agreed.
The aux. encoder position must be stored in the mount?
What I need this setup for is, I'm going to a dark site in Sept and want to create a mosaic of the Milky Way. So the plan was to quick setup, and use Ekos mosaic to action.
OK I will experiment with plate solving (I assume the index files will fit in a 32GB card)?
Thanks Paul
1 year 8 months ago #84259

Please Log in or Create an account to join the conversation.

From what I read, AUX encoders can be used to improve tracking. At any rate, use plate solving and it will be OK. The index files can be in 32GB SD card.
1 year 8 months ago #84260

Please Log in or Create an account to join the conversation.

  • Posts: 21
  • Thank you received: 0
I will send a support request on my AZ-GTi/Stellarmate/Canon camera setup but I think it's unlikely to improve much. I'm using it 100% over VNC to my home Google mesh network. The connection is pretty reliable. The AZ-GTi and Canon communicate with Stellarmate over USB - I have the AZ-GTi USB dongle. The connections to that hardware is reliable. That said this camera/mount/computer setup has never worked well. Possibly it's me not finding the right step-by-step instructions, or misunderstanding what I have read, but it's never tracked correctly using Ekos and KStars. As I say, targets are out-of-frame in 20-30 minutes using KStars but stays in frame for 2-3 hours using SynScan. I haven't used Stellarmate in months as it seemed pointless until Paul resurrected this thread but from memory attempting to duplicate SynScan's 3 star alignment in KStars has never been accurate, and sadly Stellarmate has never correctly plate solved a single shot for me on the Raspberry Pi, but plate solving works fine on the same shots when I do it on my Linux machine.

I'm going to attempt to save any special configurations I added, such as NFS mount instructions and a couple of batch files, and then just load the OS from scratch on a new memory card.

Like Paul I pretty much consider the AZ-GTi to be a bust. I'm glad it works for Jasem but it certainly doesn't work here for me. I don't plan on buying any new hardware. If I did it wouldn't be SkyWatcher hardware. The couple of support requests I made with them on this mount resulted in F-U responses saying they don't support astrophotography on the AZ-GTi. It's a fun little mount with SynScan though.
1 year 8 months ago #84266

Please Log in or Create an account to join the conversation.

I've only tested for a a few minutes, maybe up to 10 or 15 minutes and I couldn't see any significant drift. Maybe it does gets much more after 2 or 3 hours. I'm not sure what can be done.. maybe actually making use of AUX encoders IS the reason why synscan app can keep such good tracking performance over a long period of time?
1 year 8 months ago #84279

Please Log in or Create an account to join the conversation.

  • Posts: 28
  • Thank you received: 0
Hi Jasem

First the aux. encoders are used for "Freedom Find" (look it up). This allows the scope clutches to be released and the mount moved retaining the scope's position (by another set of encoders on the shaft). This will STOP the aligning processes and so needs to be turned off.

I use Synscan Pro app for my AtlAz and my AZEQ5-GT in EQ mode, in both cases I use the app to turn off the aux. encoders and get great tracking (and sub arc second guiding).

As you know in Indi/Ekos the AZGTi has 2 drivers, one in AltAz mode which is a very old integrated driver called (skywatcherAltAzSimple), this driver look very much like the ASCOM definitions and does not support aux. encoders.

The AZGTi in EQ mode uses the eqmod driver and is completely different (added as third party).
Now I believe this is the driver you use and so cannot be compared it to the AltAzSimple driver.
Now you say you mount works so I checked the driver and found this code and this would explain why your system works.

In eqmodbase.cpp

if (mount->HasAuxEncoders())
{
defineProperty(AuxEncoderSP);
defineProperty(AuxEncoderNP);
LOG_INFO("Mount has auxiliary encoders. Turning them off.");
mount->TurnRAEncoder(false);
mount->TurnDEEncoder(false);
}

So there are 2 options add a comment in Ekos to say AltAz mounts with "Freedom find" are not supported, or add this comment and develop a new driver in the same approach as the eqmod format.

I know how complicated the maths is to track on AltAz mount, because in this type of mount the target and observation position with the time determines the speed and direction of the motors. Unlike in EQ the tracking value is a constant.

Paul
1 year 8 months ago #84285

Please Log in or Create an account to join the conversation.

I added AUX encoder detection to SkyWatcher Alt-Az and they are getting turned off by default. However, I remain skeptical that this would have any effect. Please test it and report back.
1 year 8 months ago #84289

Please Log in or Create an account to join the conversation.

Time to create page: 1.085 seconds