Proposal for PEC training

[simont77]

I’ve implemented in my fork a procedure for PEC training of iOptron mounts, which do not provide a direct PEC programming from PC, but require training using guiding input. I posted some results on indi forum, but I summarize here as well.

The idea is to record few worm periods using phd2 or ekos with guiding output disable, process the log using PECPrep to generate a smoothed and detrended PEC curve, and finally playing back the PEC curve while enabling training in the mount. The tricky part is the correct synchronization of the mount with the playback, since on ioptron mounts there is no way to get the current position of the worm. I solved this issue by using time stamping, i.e. taking note of the time of start of the recording, and then starting the playback exactly after an integer number of worm period. Of course, mount should not be slewed and should be kept tracking for the entire procedure. The updated driver has a new panel PEC (too many options). You have to provide path and filename of the log, the time of acquisition start, the worm period and the zero crossing time of the periodic error function, otherwise the first step of the training would be a large pulse needed to clear the initial large error. The driver will thus synchronize with the next available period and start the playback of the correction at the zero-crossing. You can also specify a minimum guiding pulse. Correction will be sent according to the polling period (1s by default). The rationale is to send for each step a guide pulse that completely clear the PE at that time. So I take into account how much correction has been applied so far, and compare it to the measured PE at current time (this would account also for rounding and uneven polling time). The logging is quite verbose for now.

I already tested this approach on my GEM45. Here you can see the native PE of my GEM45 (first picture), and after PEC training (second picture). In the second picture first 2 periods are with PEC ON, and last one with PEC OFF, for a direct comparison. Seems quite good. Only guide pulses in multiples of a minimum step are issued (as done by PEMPro). I set the minimum step to 20ms (I tried also 10ms, but it seems to undercorrect).

This fork should work with any ioptron mounts compatible with v3 driver. The same approach should also work with any mount with PPEC, provided that period is known and PEC training can be triggered from PC.

My present fork at the moment is functional but rudimental, and it requires PECPrep for processing of the raw data. Also, more testing from more users is needed.

The full PEC training procedure is:

• Acquire data. I use ekos guiding. Just start guiding with corrections OFF
• Retrieve the guiding log (usually in your home under .local/share/kstars)
• cleanup so that only the last guiding session is present
• take note of the time of start reported in the file and add the time to the first sample (in my case 10s)
• process the file in PECPrep and generate the EQMOD PEC file
• go back to the driver. Set file name and path, the time of acquisition you noted before, the minimum pulse step (I used 20ms), and the index at which the PE curve generated by PECPrep crosses zero for the first time.
• start recording. You should see a countdown to playback start, then the actual training. Training will stop automatically when the mount say it is over. Check that the last index recorded is within +/-1 of the zero crossing.

If of interest, it is possible to refactor the procedure to be more easy to perform, or provide it as a general tool for any mount driver. Eventually someone could even implement the PEC processing directly in indi.

Here is the diff with the relevant commits https://github.com/indilib/indi/compare/master...simont77:master

[james-lan]

I had a similar thought about it a while back: https://indilib.org/forum/development/3605-pecinterface.html

I started on this, but got distracted. I'll see about getting back to it. Any feedback on that idea?

Most of any PEC interface (training, mainly) is going to have to be implemented in the UI (Kstars) rather than just INDI, I think.

[github-actions[bot]]

This issue has been inactive for 60 days and is being marked as stale.

[github-actions[bot]]

This issue has been closed due to inactivity.