In the process of digging around, it seems like if I install a signal handler in my python script for the 'newSolution' event of the '/KStars/Ekos/Align' object of the DBUS 'org.kde.kstars ' connection, then the arguments passed with that signal should have what I was looking for.

Unfortunately, with all the deprecations to dbus-python and with my limited knowledge of python, I don't seem to be doing it correctly.

For experimentation purposes, I am using this catch-all signal handler"

def signal_handler(*args, **kwargs):
    global results
    for i, arg in enumerate(args):
        print("arg:%d        %s" % (i, str(arg)))
    print('kwargs:')
    print(kwargs)
    print('---end----')

bus = dbus.SessionBus()
bus.add_signal_receiver(signal_handler,
                            signal_name='newSolution',
                            bus_name='org.kde.kstars',
                            dbus_interface='org.kde.kstars.Ekos.Align',
                            path='/KStars/Ekos/Align',
                            interface_keyword='interface',
                            member_keyword='member',
                            path_keyword='path',
                            message_keyword='msg')

Thanks for that input.

As an interim kludge, I melded the DBUS interactions with PyIndi to get the blob data.

I suppose the truly DBUS way would be to just let KStars/EKOS (controlled by a DBUS python script) write the FITS or SER data to files as they normally would then - if needed by the script - read the data back in from disk.

Read More...

Is there a way to trigger the Capture and Solve alignment operation using PyIndi or does my python script have to rely on DBUS interactions? If so, please elucidate elaborately!

Pardon my confusion, but it seems like PyIndi is great for device manipulation, but only deals with the INDI part of KStars/EKOS/INDI... namely there is no way with PyIndi to interact with the KStars Planetarium GUI or the EKOS GUI tabs such as Alignment, Auto-Focus, or Scheduler. Is that right?

As an add-on question: how does one get a BLOB back from the CCD without using PyIndi? I know how to do it with PyIndi, but using DBUS-based iINDI interface methods getBLOBFile or getBLOBData after a CCD capture return empty elements.

Read More...

After triggering a capture and solve method in my DBUS-based python script using an ekos/align interface along the following lines:

...
align_object = bus.get_object("org.kde.kstars", # Connection name
                                "/KStars/Ekos/Align" # Object's path
                                )
...
align_iface = dbus.Interface(align_object, 'org.kde.kstars.Ekos.Align')
...
align_iface.captureAndSolve()

    emit newSolverResults(orientation, ra, dec, pixscale);
    QJsonObject solution =
    {
        {"camera", m_Camera->getDeviceName()},
        {"ra", SolverRAOut->text()},
        {"de", SolverDecOut->text()},
        {"dRA", m_TargetDiffRA},
        {"dDE", m_TargetDiffDE},
        {"targetDiff", m_TargetDiffTotal},
        {"pix", pixscale},
        {"PA", solverPA},
        {"fov", FOVOut->text()},
    };

So, I think I solved my problem by using the DBUS interface into the Ekos Align module to set the Target Coords.

Roughly:

...
bus = dbus.SessionBus()
align_object = bus.get_object("org.kde.kstars", # Connection name
                                "/KStars/Ekos/Align" # Object's path
                                )
...
# after slewing
...
align_iface.setTargetCoords(target_RA_value, target_DEC_value)

I must be missing something, but this even happens with the most recent vega.py script included in the pyindi-client GitHub source.

I used the vega.py as an example and started the indiserver using the EKOS Simulators profile in the GUI rather than with the suggested command-line "indiserver telescope_simulator ccd_simulator" invocation.

After the vega.py script is run and successfully completes, if I run from the GUI the Alignment module (selecting any of "Sync", "Slew to Target" or "Nothing"), the Solution RA/DEC Coordinates and Telescope RA/DEC Coordinates are correct, but the Target RA/DEC Coordinates, as reported in the log and indicated in the "Err" field, are not updated.

For example (from the Alignment module log):
2023-11-23T12:54:23 Solution coordinates: RA (18h 37m 07s) DEC (38° 46' 58") Telescope Coordinates: RA (18h 37m 07s) DEC (38° 47' 00") Target Coordinates: RA(23h 56m 00s) DEC(180° 00' 00")

However, when queried within the pyindi-client script, the Target property value IS correct:
Telescope target RA/DEC is now: (18.615648986,38.78368896)

Is the problem that I am trying to mix GUI and command-line interactions within the same running instance of the indiserver? Do I need to do an extra step within the pyindi-client script for that to work properly?

Thanks for any help.

Read More...

Jasem,

I see that the DomePro2 driver is listed in the Dome drop-down menu on the Profile editor screen, but I don't see any mention of it, documentation, or any thing elsewhere. Is there a link to information about the driver?

Thanks for any information.

Read More...

I implemented a simple change to the asi_wheel.cpp file that allows one to use the existing "Tools->Devices->Custom Drivers..." mechanism in conjunction with creating symbolic links back to the standard driver (indi_asi_wheel).

I will create and submit a PR later today and hopefully you will find it benign enough to accept it into the source base.

Read More...

OK, thanks.

I'll play around with the asi_wheel driver for my own purposes and see what I learn.

Read More...

Not a problem - I appreciate your help.

Basically any driver that shows up in the pull-down menu on the Custom Driver screen can be aliased as you described.

However, the code explicitly suppresses from that drop-down drivers marked by mdpd="true" in those XML files you mentioned (in this case indi_asi.xml).

Read More...

I am not actually trying to use two filter wheels at the same time. I basically have one with color-related filters attached to my color camera and one with mono-related filters attached to my mono camera, so depending on what camera I am using on a night I need to distinguish between the color or mono filter wheel.

However, to answer your specific question, I just plugged them both in at the same time and one shows up as "ASI EFW 0" and the other shows up as "ASI EFW 1".

Read More...

Well, let me update: I still thank you, but it actually did not work. It only works in some cases. Apparently MDPD drivers cannot be aliased. I am not 100% sure what a MDPD driver is, but I am guessing it is one supplied as an object file rather than as source. Anyhow, the 'ASI EFW' driver is supplied by ZWO and it tagged as MDPD so it cannot be aliased and I cannot do what I had hoped to do using aliases.

That is where things currently stand.

Can anyone confirm what an MDPD driver is and why it cannot be aliased?

Read More...