Hehe I mentioned that the checkbox icon would be misleading in the device manager, I believe there are three possible states for each device : not available, available as remote, available. The icons used depends on the Linux UI, but the "available" state is marked with a checked icon (either a "V" or a "X"). In that situation the button "Start service" is active, and you can depress it to start the device INDI driver.

(sorry no access to a system for screenshots right now)

@knro I will of course, however I had planned to do proper documentation for the next release (adding support for the PHD2 protocol), as a few users had offered to test the driver first. Not the optimal choice, I'd admit.

-Eric

I understand. So thats why Canon EOS has an X too... I‘ll try again after work. So long..
Niki


Gesendet von iPhone mit Tapatalk

Ok. Connected succesfull. Seems to work so far. But still no appearence in the Ekos driver list.

But it seems that the guider is controllable from the laptop. Hopefully i am able to try today. I‘ll keep you updated.



Gesendet von iPhone mit Tapatalk

Excellent if the MGen is connected directly to the computer, you can probably increase the number of UI frames per second in the Remote UI panel to have a more comfortable session. Tell me how it goes!

-Eric

By the way, I don't think you have to use the Ekos profile editor to enable the MGen device. It is obviously easier to start everything with one click, and you can also rely on Ekos to start your INDI server automatically from the scheduler. But if all your equipment services are started from the device manager, they will be available for use in Ekos.

-Eric

First Setup Test „in the wild“ yesterday. Too bad it was not very succesful... Atm i have to start my setup with „Start indi“ in Ekos, and AFTERWARDS i have to start MGen in the devicemanager. The other way around produces a conflict with „indi instances“. Since i had problems with the eq6 controlling/plate solving anyway, i had to postpone mgen tests... Another try today...
Niki


Gesendet von iPhone mit Tapatalk

I think there is a way to fix "indidrivers.xml" by copying it to your personal folder and modify it. But this will probably be quite easily forgotten and may cause issues when updating packages afterwards. Better to wait for Jasem's fix to pop out from the ppa factory.

-Eric

Yeah we will release KStars in a few days with the changes, stay tuned.

Yeah we will release KStars in a few days with the changes, stay tuned.

Great! I‘ll keep my focus on the other probs in this case. Lots to learn for my i believe
Niki


Gesendet von iPhone mit Tapatalk

Hi,

(I'm just getting into into INDI/EKOS/KStars so please excuse my ignorance)

I'd be very interested in controlling/synchronizing the MGen's dithering (random displacement between exposures) feature with image capture in EKOS.
From reading this thread it looks like your work on MGen has been focussed on remote control and dithering is somewhat lower on your todo list.
I'm an experienced developer (but no INDI experience so far) and I'd be happy to help with hooking up dithering.
It seems to me MGen dithering would be integrated into EKOS in a way that is similar to the existing PHD2 integration where commands get sent to a PHD2 server process ( I guess the protocol is github.com/OpenPHDGuiding/phd2/wiki/SocketServerInterface ).
If that's the way to go, I could implement a server that understands that protocol and sends the command to the MGen based on the existing work for talking to MGen that you guys have already done...
If work on getting dithering synced is already underway, let me know if I can help...

Cheers,
Lars

Hey thanks for your interest in that driver. Indeed dithering is a very interesting feature, was in my list, and still is.

In order to keep a viable development, I started with the remote UI feature alone, in 2017. It made me discover the protocol and the documentation, without the feature creep sometimes I had to reverse-engineer the data to understand the doc, so that "basic" remote view was the right scope to work in first.

From where I am now, the second right thing to do is to provide a PHD2 API plug in the driver. I've been pondering whether to create an INDI client for this instead, but adding yet another interface is too cumbersome. Although that makes the driver more "intelligent" (see later), better to implement it inside the driver.

Because such a protocol requires the MGen control to be automated, and because the protocol is simply not designed to do that, I inserted a first and a half step to consolidate basic automated navigation. This is implemented (but not published) and allows clicking on buttons to do the following:
- star detection and selection, with feedback on whether one is found
- auto calibration in RA and DEC
- guiding start and stop

This most often works, but is not robust (it's nice to have this fire-and-forget mode even in remote UI though!). For instance, auto calibration needs to know the pier side to eventually reverse the feedback, that's still manual. Or sometimes there is latency and the navigation just stucks. Providing dx/dy is also implemented, but needs checking because sometimes results are just weird.

I also started implementing the PHD2 protocol with what I could find in Ekos. The issue here is that the protocol is nicely documented from the client point of view, but less so from the server. Now that 2.9.1 is out, I believe it will be easier to follow what Ekos is doing given the work done in the guiding panel. The primary objective here is to implement the strict minimum to work with Ekos.

So in other words, I'll push this to github for you to check. I will have little time to work on this until my fixed obs is finished, probably in spring, but we can discuss.



-Eric