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!

Hi there.

Two days CS was good for some testruns.
MGen is appearing now, after the workaround you told me about.
I can work with it with the remote window and thats (almost) everything i wanted.
Thank you so much!
I was a little afraid, that the guiding-signals of the MGen would maybe somehow "interferre" with the KStars/Ekos/Indy-system, but thats absolutely not the case.
So at the moment i use KStars for problem free slewing to my target of choice and focussing. And then i use the MGen for guiding AND dithering, and because of that for the capture-control too. Since i work with the SD Card anyway, this is good for me.
The guiding implementation of voidpointer would be the "luxury-version" for me

so long
Niki

Currently that's what I do too: I set the MGen up on a star, calibrate, then have all my exposures autoguided while I go to sleep. But yeah doing this limits my night to a single object. And meridian flip, aha.

@voidpointer have you got any progress on your side? I'll try to find some time to work on the PHD2 part, there could be a few good nights to test next week. And I also want to delve a bit in kstars.

-Eric

@TallFurryMan

So do you expose via MGen (dithering) or via kstars?
And is the Meridian flip automated with your setup or do you do it manually?
I bought a extension for my tripod, so the telescope would not hit the tripod so soon, what sometimes saves me the flip. I did not do that do often because the few times i tried it with the handbox flip function, ended on completely wrong coordinates.
Is there a flip function somewhere integrated in kstars?

Cheers
Niki


Gesendet von iPhone mit Tapatalk

I own an Atik camera, so there's no possibility of exposure control from the MGen through its shutter cable. This would be needed for dithering. I did not check if the protocol provided information on a running exposure, in order to start and stop an exposure on an external camera, but I'm not sure it would be interesting to embed this into the INDI/Ekos architecture, more oriented towards centralized control. However, if the general trend is to move towards more "intelligent" INDI drivers, able to manage a data value chain, this would be a fine addition.

About meridian flip, yes, it is integrated to Ekos, but only when you use the Scheduler and the tracking module. Or when you slew to a target manually, of course.

Because the current implementation does not allow to stop and restart guiding automatically, guiding is engaged manually once for all until the user pauses it. Thus the tracking modules of the Ekos scheduler cannot be used in the scheduler with the MGen, the user has to align first and keep that until the end of the sequence. If the tracking modules were used, it would most certainly make the MGen loose the guide star. Those modules manage meridian flip, so again a compatibility issue there.

However this analysis shows that the first feature to implement today is automated stop/start/calibration of the MGen guider in the INDI driver. This is what I started in the branch mentioned above. Second feature is connecting that automation to Ekos. My own idea was to use the PHD2 protocol, but I'm interested in what @voidpointer is doing.

-Eric