HELP! How does PPEC win EQMod work?

Further to my earlier forum topic concerning a potential bug in PPEC with EQMod, I've obviously been trying to improve my guiding game.

Im getting pretty decent results from my EQ8-R but the peak-to-peak error seems quite high to me (for a mount of this $$$) and generally I like to switch on whatever smarts my technology has to see what impact is can have positively or negatively so that I understand where the limits are.

I've tried to train the PPEC whilst guiding and I have a few questions;
1). Why is DEC training an option when the SkyWatcher manual clearly states that RA training is the only available option?
2). What *is* Dec training? Why would we need it give the likelyhood of periodic error being a "thing" is low? Backlash training/compensation I can understand, but PE/PEC for Dec?
3). Has anyone tried enabling RA after training on an EQ8-R? My experience is that it sends the telescope into a crazy overdrive sidereal speed mode and crashes the mount (it's now also started making a police siren style noise while doing it, something that's not good for my poor little heart)
4). A few people have referred to EQMod on ASCOM being able to log and create a "smoothed" PEC curve that can then be loaded into the mount. That is train EQMod's inbuilt PEC for 4-5 worm revolutions and I am guessing use an FFT to pull out the "known" PE versus the "seeing related" PE such that whilst guiding is still beneficial, the peak-to-peak error would be smoothed by the driver's PEC. A few bright folks then replay that PEC training into the mount to create a PPEC that's smoothed - seems like a brilliant idea, but I assume I would need to cross over to the dark-side of ASCOM to try that?

Final question;
5). Is it better to guide "direct connect" (VNC) versus in client/server mode?

To explain - I've been running in client/server mode, RPi4 with hard wired Ethernet connection on my mount/camera outdoors and Mac kstar/EKOS client in my office.

My assumption is that guiding accuracy will be somewhat latency limited by the round-trip time from image capture (say 2 seconds), transmission to client (right now guiding full-frame with my OAG as anything smaller seems to lose my guide star during calibration - say 1-2 seconds), determining "drift", a millisecond or two and then responding to the mount - another msec or two.

All told, round trip time from initial image capture to mount control would be measured as 4-5 seconds. During which time the mount has continued to drift in whichever way it does - I guess my question is, how much does all of that matter? My instinct is that the only time is would really matter is if the mount is really awful or the seeing is really shitty - either way all the guiding in the world isn't going to help - but I that someone out there might have a more scientific answer.

Sorry for the long list of questions, but as much as guiding & PEC have been documented for INDI/EKOS, it's still something of a confusing black box to me. Oh and that's BEFORE I talk about using PHD2 - I assume this is something I really should be using, but would prefer to see kstars get better than rely on third party band-aids to solve what is a product "feature" shortcoming.

Phew, that took longer than expected.

indi-eqmod is a driver: it exposes everything from the motor controller boards. As RA and DEC boards have the same firmware, indi-eqmod just shows you DEC PPEC switches, which are unuseful in a normal situation.
On previous mounts/firmwares, when you turn PPEC On, the motor controller reads period values form internal memory to adjust the speed of motor while tracking. Wrong values may explain this behavior.
A few words about that: in Indi, drivers should have the minimal number of dependencies (that was the situation when I wrote the indi-eqmod driver at least, 8 years ago). ASCOM EQMOd does not have this restriction and may have its own User interface to implement other features. If I would like to do the same in Indi, I should restrict to the Indi control panel and write a bunch of code just to handle the UI part of new features. And I am too stupid for doing that.

Hi geehael and xthestreams,

While at the topic about guiding there was a really good way to get superb guiding at least for my EQ8 Pro mount and a SX cam, I'm not sure why the option "Rapid Guide" is grayed out since long time now but it was a great way to get rid of the latency compared to the usual way getting the image or part of the image transferred to the client and displaying it.

The only drawback with Rapid Guide was the SX driver made the choice of what star to guide on, but if you had a white pixel it sometimes tried to guide on that, but after a number of retries it got a real star and it worked great.

I've never used any other cams but the SX and not sure if the SX driver is the only one that could use that option ??
Anyway, I miss that and would love to get it back even if the PPEC works really well.

Sorry about my spelling but watching '90 day fiancé' messes me up
Br,
/Markku

Thanks Gehalel and thanks for your work on the driver and yes, understand the different design models - it's one of my great frustrations.

--- off topic ----

Agree that the downside of the INDI architecture is that "documentation" and the UI for the driver control panel section seems to be pretty limited by comparison to the main UI.

It's also super confusing for a new user as I was just a few months ago to see the control panel which I originally assumed was a "no touch" zone - it looked confusing, had buttons in there that didn't look like they should be touched and was so "unfriendly" that I naturally assumed I wouldn't be using it that often.

Instead it's part of the main UI for me now, things like reading my SQM values can only occur inside the control panel and so it stays open most days, which is clearly a sign that the model isn't quite right (if I kept my systems Preferences Pane open all day on my Mac in order to know the temperature outside then it would be obvious that we've got a design/architectural problem, same for INDI control panel I think.

Not that I am saying INDI and EKOS are broken or bad, it's amazing!. It's just really clear after a few months of finding aout about it, trying it AND buying it (I am one of the paying customers) that things aren't quite hanging together as more and more great drivers and capabilities are coming into the platform.

Not that I have the coding chops to fix the problems I am pointing out and the other efforts I have seen to solve the problem are broken in their own ways too, so it's not like the problem is a simple one that yields to sweeping generalities and statements.

So I'll keep spending money with the EKOS and INDI team where I can, hoping that a combination of money and passion will drive us to a killer solution.

I agree that the control panel is confusing, it shows you directly the INDI properties that drivers define. And a driver has absolutely no control on how these properties are displayed/used. It only gives you their values and react when you change them. Now it is a very good way to learn how things work. There is effectively a lack of documentation but that would be another great amount of work to achieve. Concerning the different design model, think that you may run indiserver/drivers on a raspberry without a keyboard/mouse/screen attached and remote control all your setup. I'm not sure if you can run ASCOM EQMOD that way (it's a long time I have not looked at their work). With Indi there may be clients that would achieve the PEC control you're talking about: I remember that there is a replica of the ASCOM EQMOd pad for Indi, that may have been added there. EqmodGUI, It's there

I am happy tot contribute by adding the same little floating "pop up" text help to the control panel UI or is that not possible in that part of the UI? (the way that kstars/ekos has a pop-up contextual help to explain what each button does).

I find them super helpful and would happily put my time into taking what is in the driver description section and adding it into the product driver assuming it supports some sort of documentation field - I've not really looked too deeply into the architecture/source. The control panel is almost a whole product to itself - so much functionality & data gets exposed there (eg: current SQM values, which I can only see if I have the control panel open for example).