The camera has a wide field of view and there may be uncertainty on a satellite's orbital position or timing. The point of the observation is to collect data to confirm or improve the satellite orbit parameters.

Read More...

Paul,

Rest assured there are reasons to point to a location and stop. I might want to wait for a satellite (or several) to cross through this field of view before repositioning. I intend to integrate this INDI mount implementation with sattoolssattools , which works in this fashion.

I guess I can get my functionality through the "Set" button on HorizontalCoordsNP, but I had assumed that the functionality would be same (respecting the TRACK/SLEW/SYNC buttons) coming from KStars. Coming from KStars is more convenient for casual observing through, as I can look in the sky, know the star, and click on it. Instead of the interim step of manually figuring out what the coordinates are and then typing them in to Ekos, or slewing and then having to manually disable tracking.

Read More...

I'm developing the driver primarily for satellite observation and tracking, so the GoTo a star and sit is a convenience.

Probably more deeply though is the desire to restore function to the "SLEW" and "SYNC" buttons in "On Set" which currently have no function with how kstars overrides their status.

Users who always want to track after goto can leave the "Track" button set!

Read More...

I am currently developing a new mount driver that integrates the Alignment subsystem. I've successfully enabled the "Alignment Subsystem Active" by default when starting Ekos and connecting to the driver with the following code:

// Set alignment system to be active by default
getSwitch("ALIGNMENT_SUBSYSTEM_ACTIVE")[0].setState(ISS_ON);

However, I'm facing a challenge with automatically loading the alignment database from local storage when the driver starts. My goal is to have the alignment points loaded without requiring manual UI interaction each time.

Here's what I've tried so far, but these attempts haven't worked:
getSwitch("ALIGNMENT_POINTSET_ACTION")[LOAD_DATABASE].setState(ISS_ON);
getSwitch("ALIGNMENT_POINTSET_COMMIT")[0].setState(ISS_ON);

I confirmed that SaveAlignmentConfigProperties(fp) properly saves the properties to driverName_alignment_database.xml, and I can manually load the alignment points through the user interface.

Is there a specific or preferred method to automatically load the alignment database upon the driver's command?

Any guidance or suggestions on how to achieve this would be greatly appreciated.

Read More...

I'm currently developing a mount driver for INDI and encountering an unexpected behavior with KStars. When using the 'Slew telescope to the focused object' button in the main KStars planetarium view, my mount correctly performs a GoTo operation but always switches to "Track" mode regardless of the chosen ON_COORD_SET option (Track/Slew/Sync).

This behavior differs from manually entering coordinates in Ekos's RA/Dec field, where the mount performs as expected (GoTo and then either tracks or stops based on the selected ON_COORD_SET option).

After thoroughly reviewing my code and ensuring my implementation of the INDI::Telescope class doesn't inadvertently alter the ON_COORD_SET / CoordSP state, I suspect that KStars might be influencing this behavior. However, tracing the logic within the KStars codebase hasn't led me to a clear conclusion.

Questions:

  1. Is this the expected behavior when using the 'Slew telescope to focused object' button in KStars?
  2. How can I achieve a scenario where I select an object in the KStars planetarium view, command the mount to slew to it, but without automatically engaging the tracking mode?
Any insights or pointers towards what might be causing this behavior or how to control it would be greatly appreciated.

Read More...

Merry Christmas! Alignment simply doesn't perform the correct transformations either from mount to sky or sky to mount, after syncing it with 4 points. My observation site is fairly constrained, so I'm not able to do a full east/west sync point or north/south sync point.

To accelerate testing, I created a function to inject sync points, and set it up as follows:

1. 0 degrees altitude, 90 degrees azimuth (due east)
2. 45 degrees altitude, 90 degrees azimuth (east-up)
3. 60 degrees altitude 45 degrees azimuth (north-east, up)
4. 0 degrees altitude, 180 degrees azimuth (due south)

Neither the nearest plugin, or the built-in can consistently map the sky or mount coordinates against its physical location, but the SVD algorithm seems to do well (with limited testing).

Read More...

Jasem,

I am currently developing an Alt/Az driver for a "dumb" Alt/Az mount that does not have any built-in capabilities — it just takes position commands and feeds back encoder position. To enhance its functionality, I have been integrating the Alignment subsystem into the driver. During this process, I encountered some unexpected results with the TelescopeAltAzToSky and SkyToTelescopeAltAz transformations, which led me to finding this thread about Nearest Math Plugin.

After your mention of looking for AltAz testers, I decided to switch the Math plugin to the SVD (Singular Value Decomposition) Math Plugin. This change resulted in the transformations aligning with my expectations.

Perhaps there might be a bug in the Nearest Math plugin? To provide more context, my use case involves a significant misalignment scenario. Specifically, I have adjusted my mount to have its hardstop pointing west, effectively rotating the mount by in azimuth 90 degrees. It's possible that this substantial misalignment might be contributing to the issues I observed.

Additionally, I noticed that the Inbuilt Math Plugin also struggles with accurate transformations under these conditions, so perhaps its a common failure mode, or the code isn't meant to address very large misalignments.

Let me know if there are any tests I can do to provide insight.

Read More...

Jasem,

I'm most certainly using the correct TTY address and port (127.0.0.1, 3040, the defaults used in the distribution code). The problem exists even when I just attempt to compile the current release of code with no modifications.

My problem may lie in mixing INDI development environment (installed to /opt/local) and APT distribution environment (installed to /usr/bin), but I have not been able to find clear instructions on how to properly prepare a development environment, to include uninstalling or otherwise negating the standard installation environment via "apt-get install ind-ifull"

Read More...

I did some previous development on indi_paramount_telescope and am working on some further enhancements.

Unfortunately, my efforts are stalled by an inability for my newly compiled driver to establish a TCP connection to TheSkyX.

The existing driver (from the linux distribution) works fine. I can connect to TheSky TCP port manually with telnet and get commands.

My new driver refuses to connect, and I can't figure out what is preventing it. I'm getting a TTY_WRITE_ERROR via indibase.

Any suggestions for debugging this?

Read More...

Screen shots of my configuration are as follows. I did not include individual screenshots of all the device configuration, but please advise if any of those details may matter.

My Options->Ekos is "Defaults"

In these recent problematic sessions the "Optical Trains" GUI pops up automatically, but I had to open it manually from the CCD Ekos tab (which is configured to "Primary" in the optical trains). I've played around with options within optical trains including the "Guide via" option, but had never needed this detail before, so I've left it blank.

When the schedule starts, the exact message is:
"Ekos detected an instance of INDI server running. Do you wish to shut down the existing instance before starting a new one?""

I'm often left with multiple instances of the main kstars window (/usr/bin/kstars process) running regardless of which option I choose on this dialog.

Let me know if additional information is helpful.

Read More...

When starting an evening of imaging with Ekos, I load a schedule of ~6 mosaic targets, and hit "Start scheduler." At this point, I'm asked if I want to kill the previous Ekos/Indi session which is already running. If I kill it or not, now my GUI usually just shows the Ekos "Setup" and "Scheduler" tabs, although it appears to be communicating with the other devices (mount, camera, guide camera, PHD2) in the background.

Other times, these devices will remain, but it is the Ekos Scheduler that goes blank, and after finishing the current step in the Ekos sequence queue, it will not proceed to the next one, as there is no next one any more.

I usually have things configured to run INDI locally, and to start/connect to all drivers upon launch. I use this time to get rough alignment with my target, perform a preliminary focus, and get guiding going. Then I start the Ekos scheduler, and the previously mentioned problem happens.

While this happened once or twice over the summer, this week it is happening EVERY SESSION, and I've usually not been able to complete a night of imaging due to the problem. I have have found some work-around by starting INDI and the drivers from the command line, and connecting to it from Ekos as a "remote" INDI instance on localhost, but still some aspects aren't reported in the GUI (like imaging/sequence progress).

What is happening here? Is there any option to fix without nuking my configuration, deleting everything, and restarting/reconfiguring everything from scratch? It seems like its an errant config option somewhere, but I've yet to find it.

Kstars 3.6.7 Stable
Build: 2023-09-30T20:07:56Z
INDI Library: 2.0.4
Ubuntu 22.04.3 LTS

Read More...

It turns out there was a bug in the INDI Paramount driver, which would have affected even internal guiding with Ekos. I've updated the code to fix the bug: github.com/indilib/indi/issues/1456

Read More...