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.
xthestreams wrote: 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?
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.
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)
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.
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?
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.