Ok, I think it is actually using my primary camera instead of the guide camera ...
Maybe? There is no Gain selector in the guiding tab, so I have no idea which Gain it is using to make it match to the ones in the Dark Library.
When I do the polar alignment, now in 3.6.1 it asks me to select the drive train. If I use the normal one (Canon on the primary, ZWO ASI120 as a guide camera on the secondary) it uses the Canon for the astrometric solution (that would be ok) and the Polar alignment (not ok, I don't want to waste several shutter actuation on polar aligning my mount, I rather use the ZWO for this).
Would the solutions from another optical train that uses the same mount be kept when one switches from one drive train to another?
I'm trying to use the Dark Library for my guider camera (ZWO ASI120 mini). But
- On Ekos 3.5.9, if I activate the 'dark' (subtraction) option in the guide tab, then once I make a capture KStars gives a segmentation fault.
- On Ekos 3.6.1 the Dark Library has this 'Optical train' option. If I select my normal train, then the darks are taken for the main camera. If I take it for a dummy train with the guider camera as primary, then I can take darks, but those darks cannot be used on my normal optical train in the Guide tab (it just does not find any valid dark). If I select the dummy train with the guider as primary and guide camera, I can use those darks, but sometimes it crashes Kstars as in Ekos 3.5.9
With all these random segmentation faults that I see lately, I'm starting to wonder if making a 'monolithic' software to control everything is the best approach. Wouldn't it be better to have one thread for the Ekos machinery, rock solid and trying to make it resiliet to errors, and then individual modules running in other threads? If one of those crashes, not the end of the world. If ekos crashes., then the guiding, tracking, etc everything is lost and it just sucks.,
Any update on this? Can WSL access to devices?
I just bought myself a MeLe Quieter2Q and I plan to test both NINA and EKOS on it. If EKOS/Indi works decently over WSL I might even consider keeping just the Windows on it.
I proceeded and adjusted the spring tension of my AZ GTi and play of the gears. I managed to basically get very very minimal backlash in both axes (particularly the RA axis, where the reverse RA calibration points are right on top of the forward RA points, quite amazing). Also managed to get decent guiding in RA y great guiding in DEC (with occasional runaways) after having struggled for long time with crazy bad guiding performance (5 arcsecs and more RMS). Running 3.37 controller firmware. Axes are a bit more stiff now, and not homogeneously smooth, unfortunately (with some harder points), but hopefully smooth enough.
What I am concerned now is how jumpy it is the RA axes. With the DEC axes, I manage to balance out jumpyness/oscillations and runaways by adjusting the aggressiveness down. However, with the RA axis I don't manage to reduce those jumps. Also, if the positive oscillations seem to have a 'double peak', which I'm not sure where it comes from.
Do you have any suggestions on what I could check to improve that axis?
PS. The polar alignment procedure is amazing. I have never been able to achieve such a deadly precise PA that quickly in my life !!!.
I have a couple of small projects for which I was hoping to use INDI, a web-based interface and the pyindi-client, however, the steps to install pyindi-client through pip don't seem to work
ERROR: Command errored out with exit status 1: command: /Users/mnievas/Software/miniconda/bin/python -c 'import sys, setuptools, tokenize; sys.argv = '"'"'/private/var/folders/vq/2m6tm08x0fj5jpyhkzm4gxww0000gp/T/pip-install-_uyrwhhh/pyindi-client/setup.py'"'"'; __file__='"'"'/private/var/folders/vq/2m6tm08x0fj5jpyhkzm4gxww0000gp/T/pip-install-_uyrwhhh/pyindi-client/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /private/var/folders/vq/2m6tm08x0fj5jpyhkzm4gxww0000gp/T/pip-install-_uyrwhhh/pyindi-client/pip-egg-info cwd: /private/var/folders/vq/2m6tm08x0fj5jpyhkzm4gxww0000gp/T/pip-install-_uyrwhhh/pyindi-client/ Complete output (3 lines): Unable to find libindiclient.a in ['/usr/lib/darwin', '/usr/lib', '/usr/lib64', '/lib', '/lib64', '/usr/local/lib'] Please specify a path where to find libindiclient.a in the setup.py script Exiting ----------------------------------------
I am lately reading a bit about voice assistants and found mycroft around and inmediately thought it could be a nice thing to have one (or several) of these voice assistant systems hooked to INDI. Imagine something like...
Hey mycroft, begin 2 star alignment
Alexa, move eqmod to Andromeda Galaxy
Ok google, take a 30 seconds ISO 5000 exposure.
Hey mycroft, start brewing coffee.
For some actions, if you use it with a RPI or stellarmate + usb mic / mini speakers it could even remove partially the need of a phone/tablet/computer. And it is cool anyways
I'm right now traveling and have no way to test it because I don't have the RPI 4 with me. I will check it in a few weeks.
Thank you, I will have a look.
In the meanwhile, gdb prints these last lines
org.kde.kstars.ekos.align: "Idle." [Detaching after fork from child process 11826] org.kde.kstars.ekos.align: "Detected Astrometry.net version 0.78" org.kde.kstars.ekos: "CCD Simulator is online." Thread 19 "kstars" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xa08390d0 (LWP 11822)] 0xb6fc41dc in strlen () from /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (gdb)
I recompiled making sure that there were no missing packages (not even the optional) during compilation, but the segmentation still pops up as soon as the Ekos window is created.
I have the following packages installed.
ii qml-module-qtquick-controls:armhf 5.11.3-2 armhf Qt 5 Quick Controls QML module ii qml-module-qtquick-layouts:armhf 5.11.3-4 armhf Qt 5 Quick Layouts QML module ii qml-module-qtquick-window2:armhf 5.11.3-4 armhf Qt 5 window 2 QML module ii qml-module-qtquick2:armhf 5.11.3-4 armhf Qt 5 Qt Quick 2 QML module
I just finished compiling indi and kstars in Raspbian Buster. Kstars works fine until I start Ekos, which triggers a segfault. Has anyone experienced the same? This is the log I get in the terminal...
libEGL warning: DRI2: failed to authenticate org.kde.kstars: Welcome to KStars 3.3.7 org.kde.kstars: Build: 2019-10-13T17:07:12Z org.kde.kstars: OS: "debian" org.kde.kstars: API: "arm-little_endian-ilp32-eabi-hardfloat" org.kde.kstars: Arch: "arm" org.kde.kstars: Kernel Type: "linux" org.kde.kstars: Kernel Version: "4.19.73-v7l+" org.kde.kstars: Qt Version: 5.11.3 org.kde.kstars: Processing "unnamedstars.dat" , HTMesh Level 3 org.kde.kstars: Sky Mesh Size: 512 org.kde.kstars: Loaded DSO catalog file: "unnamedstars.dat" org.kde.kstars: "Star HD20,794 not found." org.kde.kstars: "Star HD98,230 not found." File opened: "/usr/share/kstars/ngcic.dat" org.kde.kstars: Loading NGC/IC objects File opened: "/home/pi/.local/share/kstars/comets.dat" org.kde.kstars: "Object named NGC 6050A not found" static bool LibSecretKeyring::findPassword(const QString&, const QString&, QKeychain::JobPrivate*) ** Message: 18:49:34.679: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files glibc >= 2.1 detected. Using GNU extension sincos() File opened: "/home/pi/.local/share/kstars/comets.dat" File opened: "/home/pi/.local/share/kstars/asteroids.dat" org.kde.kstars.ekos: "Starting INDI services..." org.kde.kstars.ekos: "INDI services started on port 7624." org.kde.kstars.ekos: Ekos received a new device: Focuser Simulator org.kde.kstars.ekos: Ekos received a new device: CCD Simulator org.kde.kstars.ekos: Ekos received a new device: Telescope Simulator org.kde.kstars.ekos.focus: "Idle." org.kde.kstars.ekos: "Focuser Simulator focuser is online." org.kde.kstars.ekos.align: "Idle." org.kde.kstars.ekos.align: "Detected Astrometry.net version 0.78" org.kde.kstars.ekos: "CCD Simulator is online." Segmentation fault
Or even, more refined and cool, if we know how the stars trail, estimate the polar alignment error and just adjust the tracking speed in both axes to compensate it, so only the field rotation remains. For short focal lengths I think it will remove the need for a super accurate polar alignment or guiding