Hi all,

I'm starting to read and learn how PEC woks; in particular, how PPEC works in a skywatcher EQ6R pro mount.
I know that Indi driver support PPEC, but I'm not sure how does it work and how to train it. With the handset, it is clear: start PPEC training and move the mount with the handset buttons. Once recorded, you can replay the training. That's ok. But, with indi training feature, how does it work? Can I start pec training with indi and autoguide with phd2 to let the indi driver learn the curve? If so, I guess I should disable phd2 guiding corrections (disable output).

With ascom, I've read that is possible to use pecprep to load a phd2 log file and build the curve, and load the curve to the mount with eqmod/ascom. I would like to perform the whole procedure with indi, if possible. Basically, that's my question. The complete procedure to build and store permanently (the mount supports permanent pec) with indi drivers and/or tools.

Also, I'm not sure it it is recommended to use autoguiding+pec (or permanent) or use only one of them. With ascom, as far as I understand, it seems eqmod driver takes into account the autoguide pulses that are sent to the mount and the pec applied at the same time, so it is able to discard a particular pulse if needed (do avoid interfere with pec corrections). Does the indi implementation do the same?

I've been searching in the forum and inet. I've found some info, but still have many doubts.

Thanks in advance.

Miguel

Hi Miguel, I have done some "research" about PPEC and will try to answer your questions:
indi driver supports (eqmod driver to be specific) PPEC recording. You can record such curve, but it must be done directly and you cannot smooth the curve. This means that all noise will be recorded also, such as seeing, wind gusts or other mechanical imperfections of the mount. Better approach is to record the curve during more than one worm cycle (in case of EQ6-R it is 479,9 seconds) and average and smooth the final curve. But this is possible only with eqmod driver under ASCOM, indi does not have such feature. You also cannot replay recorded curve with indi.
Once you record your curve to the mount, another problem will emerge: you cannot use PPEC under indi with guiding and dithering. Once the PPEC is running and indi driver will try to do a correction (or dither), the PPEC will take control back and cancel the correction sent by internal guider or PHD2.
The only thing you can do, is to ask the developer of indi eqmod driver, to implement also advanced functionality to improve support of PPEC.
Lukas

Thanks for the reply, hades.
So, indi driver can record the curve but cannot replay it? What the ppec buttons (in ppec tab) means then?
Just for curiosity, is the pec corrections managed by the driver or the mount itself? Cause, if it is managed by the mount, I can't imagine how ascom can avoid inteferences and allow dithering.
I think I will contact the developer. Thanks!

m

That PPEC button enables recorded PPEC to start replaying. At first it will search for index on the worm, and once it found , it will start sending the corrections.
The corrections are managed directly by mount. And you are right, ASCOM also cannot handle corrections when PPEC is enabled on the mount. I have provided incorrect information. But ASCOM with eqmod driver has so called VS-PEC, here is description from the manual:So this means that PPEC will always fight with guiding or dithering. The solution is to use VS-PEC or some Predictive PEC algorithm in the guiding tool. In PHD2 it is called Predictive PEC and in indi internal guider it is GPG RA.

That's quite interesting; so the solution could be use predictive pec with phd2 + mount ppec.
Yes, I read something about ascom vs-pec. That's a nice feature.
I've just written to Jean-Luc. Let's see if he can throw some light on this matter.

m

I am planning to do a field test with these configurations:
1) PHD2 only hysteresis
2) only PPEC enabled in mount
3) PPEC in mount with Predictive PEC algorithm in PHD2
But as far as I am using INDI, I will not use PPEC it in my imaging sessions, unless Jean-Luc update/improve the eqmod driver.

@HADES Thanks for giving such a clear explanation.
The driver only exposes the hardware PPEC implementation. And this one kills guide pulses as it overloads axis speed at constant interval using speed values stored in microcontroller eeprom (after training).
As long as you have continuous axis speed setting in a driver, PEC is better (and in a simple manner) performed using a software implementation.  That may be done at the INDI telescope class level, but I wonder if guiding software should not be aware of this PEC correction. It seems it is best if they do the whole thing.

Thanks for the help Jean-Luc.
I think I'm missing something. Then, would it be possible to implement a similar ascom vspec correction in indi to avoid any fight with guiding pulses? I think that it is not important for the guiding software to be aware of the pec correction performed, as long as the indi driver intercepts the guiding pulses, just as ascom does

I never used ascom vspec, I suppose it uses the variable rate setting capability of eqmod mounts (maybe other mounts?). You may do the same in indi at the telescope class level (this is not limited to indi-eqmod). The only problem would be to retrieve the worm position between restarts, I don't remember if there is an access to the worm indexer in the skywatcher protocol for instance. And how ascom vspec may do that.
Concerning guiding software I am totally ignorant.

I'm not very familiarized with indi developing. What do yo mean with 'telescope class level'? Is not that class inherited and implemented in eqmod driver or is it another driver? Where could I have a look to the code?