I'm running Ekos as a remote client of indiserver on an LAN. Even if I only register the camera and Astrometry with Ekos, Ekos nevertheless loads all drivers that indiserver has on offer. This is a *good* thing since my mount driver (Sitech) is not in the Indi core. But even with drivers in the core, my focuser for instance, Ekos loads it if it is running on indiserver whether it is contained in my Ekos profile or not.

So there is a somewhat loose connection between the Ekos profile and what Ekos loads from the indiserver.

If Ludovic got the plate solver working in the June Indi update, then this whole problem is moot (but curious nonetheless).

Thanks.

Read More...

In the case where the Ekos profile is set to "remote". Drivers include a camera and the Astrometry auxiliary driver.
Running Kstars under gnu debugger, setSolverMode runs when an Ekos profile is loaded.

mode == SOLVER_REMOTE is true but m_RemoteParserDevice is null.

so remoteParser.reset is called which should result in a new value for parser and m_RemoteParserDevice

but it does not. So setAstrometryDevice will fail and further down, parser may not get connected to the CCD camera.

which may be related to the problem that solve-field never receives the camera blob when "capture and solve" is requested in the alignment module.

Does this make any sense?

Read More...

Looking through the GDB lens (I haven't got the hang of kdevelop yet), running Kstars, the program gets to the function "Align::setSolverMode" with argument "1".

First the symbol "sender()" doesn't exist, so the button group doesn't get checked. Is that why the solver fields are grayed out?

Then, when "setAstrometryDevice" is called, m_RemoteParserDevice is a null pointer which triggers the "Cannot set solver to remote. The Ekos equipment profile must include the astrometry Auxiliary driver." message.

Backtrace seems to indicate that "activeProfile" has not been set properly. I haven't been able to read its contents yet.

Still working on it.

Read More...

I'm sure that's true. That's where I need to go. Thank you. But, now that I have seen the KDE guidelines for error messages (community.kde.org/Guidelines_and_HOWTOs/...Using_Error_Messages), I'm wondering what is blocking messages from qCDebug or qCInfo from the console.

Read More...

I would like to trace where the inclusion of the remote astrometry driver is getting dropped. How can I get output from cerr or stderr included with Kstars output to standard error?

Read More...

How can one read output to standard error? It seems that kstars is directing it away from the console. And I would like to insert some temporary markers to trace where my astrometry driver inclusion is getting dropped. Thanks.

Read More...

I'm not quite sure how to edit a signature. Sorry to make you ask.

On remote:
INDI Library: 2.0.2
Code 2.0.2-tgz. Protocol 1.7.
Linux spica 6.1.0-7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-2 (2023-04-08) x86_64 GNU/Linux
Command: indiserver indi-asi/indi_asi_ccd indi-core/drivers/auxiliary/indi_astrometry
Attached: ZWO ASI294MM
Note: solve-field works fine from command line. indiserver messages acknowledge connection from client and configuration astrometry options are read from client.

On client:
Kstars Version 3.6.4 Stable
Build 2023-05-28T20:04:17Z
INDI Library: 2.0.2
Code v2.01-22-g8588609d7. Protocol 1.7.
Linux debian 6.3.0-asahi-00538-g3965d153b13f #16 SMP Thu May 18 18:48:19 CEST 2023 aarch64 GNU/Linux
From Kstars messages:
.ekos:...Connection to remote INDI server ... is successful
.indi: Received new device Astrometry
.ekos: "Astrometry" Version: "1.0" Interface: 32768 is connected.
.ekos.align: "Cannot set solver to remote. The Ekos equipment profile must include the astrometry Auxiliary driver."
.ekos: "Astrometry" is connected and ready.


So somehow m_RemoteAstrometry in remoteastrometryparser.cpp is getting a null pointer. And I don't see why (yet).

Read More...

Yikes! sorry. I should have said that Nou was correct.

I was working with an installation of INDI from September 2022 and updating to the current build solved that problem.

And agreed: INDI should be built before Kstars.

Read More...

The log message continues "The Ekos equipment profile must include the astrometry Auxiliary driver."

But the Profile Editor does show Astrometry in the Aux 1 field of "Select Devices".

Astrometry is running under indiserver on the remote as is the camera. When Ekos starts, the control panel shows Astrometry to be connected, the solver tab displays in the Ekos window. However, under the configure tab, the log entry after "Remote devices established" shows only that the camera is online and does show an entry for Astrometry.

I did not have this problem in previous versions.

Any ideas?

Thanks.

Read More...

Having run "cmake -DCMAKE_INSTALL_PREFIX=/us ~/Projects/kstars/kstars-3.6.4" I get the curious message:

The following OPTIONAL packages have not been found:

* INDI
*ERFA
*LibXISF

INDI does exist on the system, also compiled from source following directions on github.com/indilib

Debian binary kstars did find INDI, but my version couldn't see the astrometry device so I tried installing the most recent kstars.

How can I help kstars find INDI?

Thanks.

Sorry for the noise.

Read More...

Argh! My mistake. I had not properly re-installed and old installation interfered. Sorry for the noise.

Read More...

In file included from /home/mark/Projects/indi-3rdparty/indi-asi/asi_base.cpp:23:
/home/mark/Projects/indi-3rdparty/indi-asi/asi_base.h:76:83: error: ‘FITSRecord’ is not a member of ‘INDI’
76 | virtual void addFITSKeywords(INDI::CCDChip *targetChip, std::vector<INDI::FITSRecord> &fitsKeywords) override;
| ^~~~~~~~~~
/home/mark/Projects/indi-3rdparty/indi-asi/asi_base.h:76:83: error: ‘FITSRecord’ is not a member of ‘INDI’
/home/mark/Projects/indi-3rdparty/indi-asi/asi_base.h:76:93: error: template argument 1 is invalid
76 | virtual void addFITSKeywords(INDI::CCDChip *targetChip, std::vector<INDI::FITSRecord> &fitsKeywords) override;
| ^
/home/mark/Projects/indi-3rdparty/indi-asi/asi_base.h:76:93: error: template argument 2 is invalid

When set to "remote" plate solving fails for me.

Basically, as one may see from the log, the data in the file /tmp/ccdsolver.fits, is sent to solve-field for solution. However, no data gets there. The file is empty. So the solver fails.

Jasem's note for the solver in astrometrydriver.h says that the CCD driver the solver listens to is set in the options. However, in my case, the driver is in fact set to the desired camera driver and still the blob does not get written to /tmp/ccdsolver.fits.

solve-field on the remote computer is fully functional; it just doesn't work on an empty file.

The image to be solved is properly displayed in the Ekos solver module window on the client machine.

How can this be fixed? Thanks.