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

Cool, thanks for the info. I'll need some time to get set up with my dev env around INDI before looking at getting productive but I got everything to build.

Personally, I think it might make sense to pursue the dithering independent from the overall automation (at least as a near-term increment). This wouldn't work for a completely automated setup. However, if just using KStars/EKSO for controlling alignemnt and capture, one would just get the guing going "manually" with the MGen handbox but control the subsequent image capture through INDI and just send the dither command between frames. (It would also be cool if one could get the guding stats while the guiding is running so that could be displayed during capture - however, I suspect that the protocol might not support you getting at the data while guiding is running)

Cheers,
Lars

Hi Lars,

there is a windows project called "astrophotography tool" (APT) which does just what you described. Guiding is det manuelly at the handbox or by means of a dedicated windows app. Once up and running the connection is closed and the APT software takes over and coordinates dithering inbetween frames.

APT shows a guinding graph so there must be some comunication with the MGEN guider. So it seems the protocol supports getting at the data while guiding is running.

Cheers
Stephan

Yes, as soon as a star is locked, the MGen protocol allows retrieval of dx/dy, in pixels.

-Eric

I've started to make a little progress on adding a new guiderinterface implementation for MGen to EKOS.
Still lots of work to do talk to the actual device but Eric's work will help a lot in figuring that out...

While working on getting my guiderinterface impl wired up, and controlling the state of the Guide UI, I noticed that a CCD is always being added to the Guide instance, which would re-enable the binningCombo that I wanted to keep disabled in the MGen case.
Now I obviously know next to nothing about the inner workings of kstars/EKOS so far as I've pretty much only looked at the external guider code so far.
Anyone care to explain where that CCD that is being added is coming from and whether that is expected in the case of not using the internal guider?

Cheers...
~lars

I think it's interesting for you to try the guider interface out, to understand better how the drivers work. But unfortunately, a guider is a device that provides a way to alter the movement of the mount, from the client perspective. Because MGen actively runs the guiding, it doesn't fit the purpose of that interface much...
If you are looking to implement an extension to the current driver, I suggest delving how the frames are sent to clients. Right now the remote UI is sending blobs that can be mistaken with the actual camera frame of a different ccd. Try to make that clearer to clients.

-Eric

You can try install indi-mgen driver from Alstronomy Linux DEB repository .

@oleg, thanks, that is a build of Eric's driver. It doesn't support synchronitzing the dither function as of yet as there is no interface to do that through INDI

Here's what I'm working on (see attachments)
- I've managed to add a new external guider implementation to the selection


- I got the implementation hooked up so that it is getting the dither signals when guiding is running during during capture


Now I need to get it to talk to the actual device and then work on writing back the drift stats to the guiding UI...

That all looks great!

I am not into programming or coding or something like this, but i have an MGen Device here. So if there is need of some testing, maybe i could help a bit. I just need clear instructions and syntax to do so.
Just tell me if i can help...

cheers, Niki

@voidpointer Excellent I shared what I did with the PHD2 basic server on my github repository: check branch "feature__mgen_navigation" in repository "github.com/TallFurryMan/indi". There are a few fixes in there, and a PHD2 protocol tester. The part that will be of interest is the way the device class and the PHD2 server are communicating: check the callbacks "engageSearchStar", "engageStartGuiding", "engageStopGuiding". Those are propagating to actual navigation inside the MGen UI. This is not really robust for now, but the protocol allow to verify is a star was detected, and to retrieve dx/dy. Along with information about the optical path, this can be translated to arcsecs. I think the two railways are about to be connected!

@the.cakemaker I reproduce the problem with the MGen device not showing up in the Ekos Profile Editor in KStars released 20180128. I thought this was fixed by @knro some time ago, because it is related to the MGen device listed under group "Aux" instead of "Auxiliary" in indidrivers.xml. To work around this issue, copy "/usr/share/kstars/indidrivers.xml" in your personal folder, in ".local/share/kstars". Command:In that copied file, look for "Lacerta MGen" and change the "group" attribute of the enclosing "devGroup" element from "Aux" to "Auxiliary". Restart KStars, and the device should appear in the Profile Editor.

-Eric

Hi!

Tryed to use the syntax but that does not work for me.
I also can not find the folder .local/share/kstars...

Niki

Edit: Found out lots about hidden directorys, just forget what i wrote...

Edit #II: Worked for me. Mgen is there now. Thanks for the Lesson and thanks for the help. Next Clear Sky i will test!