Is your Microtouch focuser connected by USB? And if so, how did you get INDI to recognize it?
When I try to connect INDI to my USB Microtouch focuser, it only shows me the options for Serial and Ethernet.

Hy,

Thanks for all your work on this. I tried to switch back to the internal guider from PHD2 the other night, but was halted by DEC backlash issues during calibration. I took my scope down and have chased this to tune it up a bit, but I also wonder whether there shouldn't be an option to disable reverse DEC moves during calibration. This still allows the calibration angles to be set, but avoids getting stuck by DEC backlash. Forward calibrations would work normally, and reverse motion on RA would still function the same. Not doing a DEC offset back to original position would force the user to re-solve (if desired), but that seems minor. This could open more doors for folks with DEC backlash.

Now that I think of it, I'm not sure there's an equivalent option as in PHD2 to set or disable one/both DEC guide direction(s). Do we have that? That feature would be desired too (so some folks could intentionally misalign PA, forcing DEC motions to be unidirectional. Anyway, just a couple of thoughts to possibly make this handle some bad cases slightly better.

Cheers, Doug

I am just wondering if the setting "Minimum move" in GPG RA settings dialog is really in arc-seconds or in pixels. I have tried to calculate the value guided by this page: www.myastroscience.com/minmoveinphd and the result should be in pixels, not arc-seconds.
In pixels I am getting value 0,09, in arc-seconds it is 0,6 (0,09*guider image scale). Which one is correct?

The GPG min-move setting unit is arc-seconds as documented in the menu.
I double-checked the code, that is correct.

 

Thank you Hy, in that case I will use value 0,6.

Let me start of by saying that I love this feature. I have a SW AZEQ6 that has horrible PE and this manages to tame it.

Now from my understanding the corrections made by GPG aren't persistent. That is, for each new imaging session I start, GPG has to re-learn what my mounts PE is before it can make corrections. For me that means at least 30mins of sitting around waiting until GPG does it's thing.

So I was wondering if it was possible for the corrections to somehow be saved and reloaded each session. That way I'm not having to waste precious imaging time.

Rene

Rene,

You won't get an argument from me on that. I agree that would be very nice, and notice the same every time I image. In fact, once I got this code ported to KStars, that was one of the first questions I emailed Edgar Klenske--the author of this algorithm & code.

Edgar was very helpful throughout my work on this, but he told me that storing and re-using a model would be very tricky to do, it's not just simply storing some numbers and recovering them. I put experimenting with this on my todo-someday list, but may never get to it. Edgar knows what he's talking about, so I trust his estimate, and I really don't understand the guts of his algorithm.

Just checking, though. Of course, you can re-use the Major Period estimate. Once you think your system has done a good job estimating it (or you've looked up) your mount's worm-gear period, there's no reason to re-estimate that every time. Make sure you then uncheck "Estimate Period", and use your known good value for Major Period (e.g. taken from the end of a successful guiding session, or from some publication of your mount's worm-gear period). The default (see Num Periods for Inference") is to completely trust the new estimate after 2 periods, so if your mount period was 8 minutes (and I believe that's about as long as they get, though I'm not sure), then you should be running pretty well after 15 minutes or so, and less for mounts with shorter worm-gear periods, if you don't also have to estimate the mount's period.

Hy

I don't know all the details about this algorithm, but when I compare it to PPEC, the tricky part is that mount needs to know the exact location of the worm gear to be able to "reuse" already recorded correction curve. And this is not possible with "cheap" mounts without encoders. AZEQ6 and also EQ6-R have only "index" on the RA worm, se the capability of resusing is limited. Recorded curve can be reused in case that the mount was parked and unparked at the end of one and beginning of second imaging sessins, and you haven't moved with the position of the RA worm. If you only loose RA axis, it will not move the RA worm, so you could be fine to reuse recorded curve.

Agreed, however, it's possible that one could save the learned corrections (assuming that it was not affected by RA and DEC) and "learn" where the worm gear is. By just trying to learn one thing (the position) instead of the entire correction (many parameters), it's possible that could be done much more quickly.

I have read that this can be done by changing offset manually, but instead of searching for the correct value it is much faster to learn the curve from scratch. This can be applied to EQmod ASCOM driver implementation

I've a double about how the internal guiding parameters and the new GPG RA guider configuration. We have two set of main parameters and I don't understand how they are related. For example if I want to reduce the intensity of the response to a guide deviation, which one should I change?. I know that if I've GPG disabled, I can increase the proportional gain to get a stronger response to deviation. But with GPG enable, should I change proportional gain or prediction/control gain on GPG? Both?

Could it be posible to know the equations that relate both set of parameters? Thanks in advance

 
 

Sorry I haven't cleaned this up yet, and thanks for your question. My intention is to make this more obvious.

GPG, when enabled, completely controls the response to RA error (but not the DEC error). So, RA Proportional Gain, RA Integral Gain and RA Minimum Pulse from that Control Tab are ignored when GPG is used (the DEC values are used, as GPG is not involved in DEC guiding). It turns out the RA Maximum pulse is used for RA and DEC. Maximum pulse is sort of a safeguard that wasn't implemented in the Klenske's GPG code , and so I kept it in place.

The GPG parameters themselves are a bit tricky. I did not modify them from their original form, and you can see how they're used in the code we got from Max Planck Institute / Edgar Klenske:
invent.kde.org/education/kstars/-/blob/m...cess_guider.cpp#L344
Basically it blend the control error:
    line 344:    prediction_ = PredictGearError(prediction_point + time_step);
control_signal_ += parameters.prediction_gain_ * prediction_; // add the prediction