The EQmod driver doesn't know about the index on your RA axis. This index is only used in case the mount runs it's own stored PPEC, so not applied in case of GPG RA.
The EQmod driver can use predefined RA worm cycle period you've entered into the field. Or you can let the Ekos to measure the period, by ticking the option Estimate Period.

Mmm. So how does GPG keep its PEC cycle aligned with the mount? After a slew and guiding re-starts how does GPG know where to re-start? If it simply re-starts where it left off the worm will have turned and GPG will be out of sync. I must be missing something?
I notice there is an EQASCOM CommandString to get worm position :PECIDX#. Surely Indi can do the same?

Hi

PEC and GPG are 2 different things, and up to now, EqMod can not handle the PEC feature, but Hy Murveit is currently developing the support for Eqmod. I was involved in but I had to give up when I found out my old HEQ5 pro cannot support PEC (it's one of the 1st version). But you might help for dev if you want.
Look at this thread , it might be helpful to understand GPG behavior. The documentation should be up to dtae too.

@Hades, I'm pretty sure EqMod driver knows the RA worm position, it should be in motor control tab, Stepper position.

Valentin

Hi Valentin. Thanks for status update on PEC. I see in the Indi Control Panel the count for RA steps changing as mount tracks and 123798 for RA Period and 6 for Dec period but not sure what these values represent. Anyway seems like I should be concentrating on getting GPG working.
I had read the Kstars manual but thanks for link to Forum topic I also read The Gaussian Process Guider paper and boy that needs a bit of time to understand. I would still like a better understanding of GPG to help get it working for me. This is my understanding so far. Please put me right on what I have wrong!
1)GPG needs several worm cycles to build up the data to make best predictions and it doesn't need to be indexed to any particular worm position, just gather data to span a worm period, in my case about 198 seconds.
2) I notice the Ekos documentation for the GPG settings don't all match the Default settings. Periodic Length scale is 10 secs as default but 16 in the guidance doc. Number of periods for interference is 4 by default and 2 in the documentation. Which should I use?
3) Hy says it starts to contribute estimates after one period and fully kicks in after 2 periods and his 'Number Periods for Interference' is set to 2. I will try 2 as well. If its 2 cycles for GPG to learn then I guess I need to wait 7 minutes.
4) Hy is guiding through the main telescope but I have a smaller 60mm Antares Versascope and a 120mm mini. The image scale for the guider is 3.4 "/pixel and for main camera 0.32 "/pixel. Does this influence my guide settings? For example it's recommended to bin 2x2 but that would double my guider image scale. I guess I am looking to work down to a theoretical +/-2" guiding accuracy (the green circle) and indeed the drift Plot seems to suggest this but I am not sure I believe it as a good image and a poor image look very similar in the spread of the plotted points. I find RMS for RA is the best indication which I am striving to lower. It was around .6 at best with GPG off but I understand .5 on good night and .3 on superb night.
5) Pulse for calibration is 1000 by default but Hy is set to 200. Should I use a larger value for my greater image scale?
6) After a slew does GPG need some time to settle down again? Does it re-learn?

I took 300 second unguided images and could clearly see a drift pattern which I put down to PE. With guiding on and GPG off star images were much improved, almost acceptable. With GPG on the images looked much like unguided images. Just a thought but when GPG is learning is guiding turned off?

Need a clear night for further testing....
Thanks
David

I will try to answer some questions, but I am no expert, maybe some people might have better explanation. But I think our understanding level is the same. I have read too the gpg paper and it seems to be rather deep.

1) Right, to my understanding
2) I noticed that too, and I am as confused as you, as I can't find any satisfying response about the difference between default values and the documentation, and how to estimate the values for our own setup.
3) I think you're right about 'Number Periods for Interference', but Hy might tell us if it is correct.
4) You're right, Hy use a OAG with a long FL, and we use a guider for that (btw, we have the same guider FL and camera pixel is pretty the same too). For binning, as we have a fast guider (and low FL), I would stay in bin1. I have no issue of low snr with such setup. But I'm pretty sure the algorithm can handle big pixels (or bin2) as it can determine the centre of a star with fraction of pixel.
5) yes it's confusing me too, but I guess as Hy has a long FL for his oag, he needs to lower this number. But yes, I'd like to have a better explanation of that figure to determine it for my setup.
6) Right, GPG resets as you slew away and go back for a period of learning as it has no clue about the current position in RA in regard of worm position (I guess it's not really true as eqmod gets the RA worm position and RA in the sky is known with plate solving, but it is not implemented in the current code up to now); It is the point of PEC training btw. In my case, my mount cannot handle the PEC curves recording and playing, but I can use GPG.

And for your last question, my understanding is GPG adds some corrections to the guiding after several worm periods, but the guiding runs at the start, no matter GPG is learning or applying corrections.

Valentin

Here are my answers to David questions, but remember that there is a lot of guiding wisdom on the web, please don't look at what I do as the only way. Also note that GPG and PHD2's PPEC are (or were) exactly the same code, so suggestions from PHD2 folks apply well to Ekos' internal guider with respect to GPG (and probably most other things). Please also remember that this is a hobby. Don't stress too much about these numbers. Experiment a little bit on the most important numbers and see what works decently for you, but don't try to optimize every number.

1) What I do for GPG is lookup my worm period (from here: github.com/OpenPHDGuiding/phd2/wiki/Mount-Worm-Period-Info ) and enter my value. I tell GPG not to estimate the period--since i know it. GPG only makes full corrections after 2 worm periods, though it does ramp up the prediction (e.g. it predicts half as much after one worm period). The whole thing starts over every time GPG restarts--that is every time the guider restarts, like after slews, or lost stars, ... It doesn't need to know what your worm position is. It doesn't know about worms. It is just looking at the guiding error and estimating periodic guider error.
2) Read the PHD2 PPEC doc here openphdguiding.org/man/Guide_algorithms.htm I use 2 for the min-periods-for-inference. If that is 4 by default, then I think there was a typo I can try to fix. I wouldn't change any of the advanced parameters.
3) Don't "wait 7 minutes". Start guiding and then start imaging right away. It'll get a little bit better after 7 minutes, but it should be OK at the start too.
4) Not sure. My guess would be bin 1x1 if you're at 3"/px. You should experiment and see what works for you. Looks like your guiding is already pretty good David!
5) I would set the calibration pulse to whatever moves the stars a few pixels on average, so if you calibrate and after 10 pulses it's moved about 25 pixels then you've set it well. Doesn't have to be exactly that. Just want enough pulse so that you have enough movement to make good calibration estimates. Here's a good video on guider calibration: it's about PHD2, but applies just about as well to Ekos.
6) GPG starts from scratch every time it restarts. I asked Edgar Klenske the same thing, but he said that he never implemented any way to keep its model and re-find the position. Do you want want to do some research and code that up? It's a frequently requested feature. Read this! ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7105398

Hy, just one question. You wrote: "GPG only makes full corrections after 2 worm periods, though it does ramp up the prediction (e.g. it predicts half as much after one worm period). The whole thing starts over every time GPG restarts--that is every time the guider restarts, like after slews, or lost stars, ... "

Doesn't this mean GPG will start over after every (one-pulse) dither, too as this is a very short slew? If so, that would mean GPG will never work here since I always dither after every frame which takes 3min max. and my worm period is 4min.

No, dithering is not an issue.
We don't reset the GPG during dithering (one pulse or normal). It continues to operate.
There is a GPG input where you can tell it about things like dithering.
invent.kde.org/education/kstars/-/blob/m...?ref_type=heads#L294
GPG only resets on a real slew or a guiding reset, e.g. "lost guide star".

Thanks all for your responses. I am still testing GPG and guiding. Had some clear night's. Away for a week but will report on progress later.
What I see is guiding is pretty good but not good after a meridian flip.?

The number of stars reported for guider in analyse increased by 50% after the flip. The guider isn't aligned with main scope but isn't too far out the target being on the edge of the frame. Struggling to work that out but can only assume the area of sky seen is different after flip?
My 60mm guider with asi 120 mini for a 12"at f8 may not be good enough so considering a OAG with a better guide camera.
I would like to investigate backlash as star images are elongated in RA when poor. I have looked at the internal guide log with PHD2 viewer but can't see any measured backlash stats. Does anybody know how to analyse the calibration? Ekos just reports successful but it would be good to judge how successful? If I do adjust the worm position I would like some stats to measure if improvements have been made.
One irritation with Ekos guider options GUI is the use of the mouse scroll wheel. When a window isctoo large to display I normallycusecthe mouse wheel to move upland downvthe window. With the guider options if the mouse happens to be over an input control the mouse wheel changes its value which I find can happen by accident when really wanting to scroll the window. The normal set up is for user to have to click into the input control before adjusting it. Could this be fixed? One day I will set up a system to help out with coding!
As Hy says its a hobby with software developed on a voluntary basis so must be patient and swap notes.

David,

- I think the guider's number of stars and SNR stats should be thought of as relative measurements. That is, you see what they are when the guider starts, but their absolute values may not be too meaningful. As you point out, they depend on the star field in the guide-camera's field-of-view, and the SNR also depends on the brightness of the guide-star that happens to be chosen. So, when you do a meridian flip, the side of the image that the OAG picks off changes to the other side of the image, and the stars there are different.

Currently with SEP MultiStar guiding, even though there are many stars used to evaluate the drift, one star still is the "guide star" and that star's brightness helps determine the SNR. Admittedly, I should change that, but it's probably not a big deal in terms of guiding performance. BTW, I'd recommend you use a lot of reference stars--I use up to 50.

- Usually backlash doesn't affect RA, as the RA motor is running all night. Typically guide pulses are much less than the actual tracking rate so all the guiding in RA does is speed up or slow down the tracking rate, but the motor doesn't change directions. Think of it this way. RA tracking is roughly 15 arc-seconds/second. You'd need an error in RA of > 15 arc-seconds towards the East with 1.0 aggressiveness to completely stop the RA motor for one second. Therefore the motor is always turning the gears in the same direction and there shouldn't be backlash. (This is not true in DEC. DEC isn't tracking, typically, therefore you do change direction in DEC, and backlash may apply. That's why people talk about backlash for DEC.)

You may have large periodic error. This would cause variation in RA that the guider is fighting against. Assuming your mount supports it, you can load a PEC curve to counteract that. That is also what GPG tries to fix, but of course, it would be better if it didn't have to fix it, or didn't have to fix it as much. I have an experimental piece of code that computes and uploads a PEC curve with Ekos for my A-P mount, but only have one volunteer who can help with the testing for EQMOD mounts. It definitely helped my RA performance, though it was already pretty good. See indilib.org/forum/wish-list/5267-softwar...od-mounts.html#93921 if you want to also help test. Of course, you can always use a PC and upload a curve via pempro or theskyx.

- Widgets and the mouse scroll wheel: I agree with you that it would be nice if the scroll wheel didn't adjust the widget until the widget was clicked. This must be something buried inside of the Qt widget library, and we're likely using the default. I'll try and google it to see if it's something that could be changed--but i wouldn't keep my hopes up.

Yes of course it is the PE thats the likely problem with my EQ8 mount. Unguided 3 minute plots clearly show the PEC drift with a distinctive pattern.

I would like to help with testing an Ekos routine to record and upload PEC. Dec guiding is acceptable it's just RA for me. Dec RMS is around 3 but Ra struggles to get down to 4 and can be higher. Drift plot looks broadly elliptical most of the time although strangely the tie up between plotted points and the resultant image isn't clear. What I mean is the drift plot can look poor but star image not bad or vice versa. I think the other factor not well presented in the drift plot is how long the star is out of position . Taking an extreme case for illustration, but imagine a drift plot for 2 positions 1 in the centre and one at 2 " radius. If the exposure was 10 seconds then star image would look worse if it was 5 seconds at each position and better if 9.9 seconds in the centre and 0.1 seconds at 2" position.
You can turn on Pec learning in Indi EQMOD tab now. I have used it and it goes yellow until it finishes after several minutes. Not much feedback but I could only assume it did it? You can turn on PPEC. Are you developing something different? I read discussions where if using PEC it can fight with guiding software which is also trying to correct it.

It would be nice to see a graph building with index position identified and drift shown on y axis.

You seem to be suggesting using GPG with PEC?

If I can be of help please let me know..

David
I have sent you a private message about helping me with PEC.
Hy