Done

Going away to a international dark sky site this week, with some promised clear skies on the metoffice. So i will be doing some additional testing on PEC.

Based on investigation, It is possible to import the guiding log into PECPrep to generate a smooth PEC curve. 
However the current firmware does not allow for a command to find the position of the worm gear. Aka Celestron has a marker for the start of the worm drive revolution.

So i cannot work out a feasable way, to mark the beginning of a cycle to initiate a playback of the smooth curve.

looking at the code of the predictive guiding algorythym, the Machine Learning code deduces a worm gear cycle time and then overlays the prediction on a estimatec start. So it might be possible to isolate the worm gear start position, from guiding.

My idea is to go a step further still,  if i can get the guiding system to send record cmd, and then only send the prediction... 

was thinking this could be like a 400s dither cmd, which pauses the guiding, but keeps sending predictions until record is complete, then resumes guiding, but resets the machine learning model, so that it relearns the cycle but with PEC active.

Therefore, should have a small amount of PEC, which is normal deviations from std deviation from prediction model, however if any nudges are incorrect, the normal guiding will see this as external factor, and build up a correction patern for these few inperfections.

This seems like a feadible route, but it will take time to reverse engineer how the dither works and to create a copy that does what i want it to do. 

Anyway, i will play with it and see what i come up with.

Hi all,

Testing is complete on the new version of the code. Parking works, slewing works, PEC recording and playback works well.
I managed to get a really nice smooth curve out of GPG predictive guiding and recorded.
If you want to create a PEC recording and then, to just image without guiding, then this is a great option.

However, once PEC is recorded and playing back, it is not possible to guide well anymore.
This seems to be a conflict in the firmware. From what i can see this is what happens:
PEC issues a predictive pulse and then guider issues a reactive pulse, so they double count.
What then happens is that the corrections get bigger and bigger as it doubles up.
If the firmware, could output the PEC pulses, the driver could spot them and cancel them.
or if the firmware could look for the double counts, then it could cancel them.

Both these require, iOptron to update the firmware, so not counting on this happening soon.

I will see if any work around exsit in code for other mounts.

Very good! How did you setup GPG at the end? How did you convince it to not follow any drift?

In the meantime I worked on a different approach, using PECPrep to prepare a smoothed PEC curve and then playback it to train. It's a bit tricky because you have to keep the synchronization between recording and training, but since this is the way PEMPro does with iOptron, I think it should work. It should also allow more control on what we actually program, getting rid of noise and drift. The code is ready and tested "in lab", I have still to try it on field ( I still did not check if the direction of the correction is right, though). If someone would like to have a look at the code, it is here: github.com/simont77/indi. In the repo there is also the PEC file that I'm using now for test (this is a real PECPrep file from my GEM45)

The idea it that you have to record some periods using phd or ekos, taking note of the time of start, then process the log in PECPrep, and finally launch the PEC recording in the driver, all without stopping or slewing the tracking (this will allow the code to playback the correction in sync with the mount at the proper time). 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.

Wow, you have been busy, nice! just reviewing your code now, it is looking good.

I will do some testing in next couple of days, when the moon overwhelms my data collection efforts.
As an aside, we may need to keep PEC playback in the driver, because the firmware clashes with guiding.
Something more testing may prove to fix, but i have seen a lot of reports of this happening with all iOptron mounts on the cloudy nights forum.

i.e As an solution i was thinking something like this.
Driver does playback of PEC file in a loop, based on the wormcycle.
If guide pluses come in a negotiation happens to see if it is a double count, so ignore the PEC pulse.
This way we completely bypass the chip on the mount. (until iOptron sorts it out the firmware)
This is what EQmod does PEC on the windows driver.

For this to work we should always park the mount and never disengage the cogs.
(I know this is a real pain, unless we can work out a way of finding the start position of the worm gear.)
This must be possible, because GPG guiding works it out. So if we can somehow grab it from there?

Another Option is we ask iOptron for a firmware update, which signals the worm gear start.
This should be a small change for them, but it will take some time before it is released.

I'm too waiting for some good weather to test on field. As for guiding, right now I will only do unguided exposure, this is the reason for my interest in PEC. Yes, I saw several posts as well about weird behaviors with PEC+guide, but there are also some guys who had no issue, and others for which it worked for some time and then stopped. I don't think it's a matter of double correction. Guiding corrects the error after having seen it, so with a perfect PEC on, periodic error cannot even be seen by the guider (in reality some error will still spill). The issue is probably due to the fact the at the same time both PEC and guider would like to apply a correction (non necessarily of the same sign and amplitude) and this is not well managed by the firmware. Combining the two corrections in the driver would work (you would start applying only the PEC, and then add the reactive guide for the residual error), but, as you said, requires the driver to know where the worm is, which can be inconvenient. You should always park and unpark, but I think that also any manual slew with the mount not monitored by the driver has to be avoided.

At last I was able to test the training procedure.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. I had to modify the training function so that only guide pulses in multiples of a minimum step are issued (as done by PEMPro), and set the minimum step to 20ms (I tried also 10ms, but it seems to undercorrect).   

 

 

Wow, impressive results, this is looking fantastic. My guiding graphs when i am well aligned and balanced are 2 arc seconds up and down, which is very similar to your PEC graph.
What is the correction interval (i.e when you are recording, what is the interval of the guiding corrections?)

The reason why i ask, is that based on some research, i have seen that if you are using PEC, it is best to guide with a much longer interval.
i.e The recommendation is around 3-4 seconds, to reduce seeing effects (which works really well for me), but the timing of corrections are based on the accuracy of the mount.
I think if the correction interval of PEC is really small 0.2 seconds say, and guiding is all the way out at 4 seconds. (guide camera timing)
This will eliminate conflicts, because the PEC corrections will be many tiny corrections, continuously.
Then guiding corrections really, fix anything in the >1 arc second range due to other factors, etc.

It would be really great if you could test this and record the outcome again. (PEC On and Guiding at 3 - 4 sec)
I suspect this will get your graph down to max 1 arc second each way.

i want to test your PEC approach, once you are confident, could you let me know with some detailed notes.
Also we should contact Jaseq so that he can promote your changes into the driver for Nightly.

This way we can get a broader range of testing from CEM 60 / 70 and other mounts.

Well down again.

For data acquisition I have a 2s exposure every 10s (using a DSLR and for some reasons I cannot go faster). Then PECPrep generate a smooth correction curve, with a sample every 1s. My code finally generate a correction pulse every 1s, but since I set minimum step to 20ms (with guiding rate to 0.5) and the PE is small, actually it's very frequent that only a pulse every 2 or 3 seconds is issued.

If you want to try, I think it is now stable enough. So:

- 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.

You should also check the polarity of the correction. If it is wrong the PE will increase. If I remember well "West positive" is the option to use if during calibration West guide will move the star towards negative values, but it is better to just try and check.

With some testing i have some observations.

Tests Conditions:
15 iterations of the worm cycle used with PECPREP. (autofilter on the log for best ones)
This is my guiding log at the end of a evening of imaging, with dithers removed manually from the log.
Guiding was using 3 second exposures, to remove seeing.
PECPREP PEC Error correction Cycle generated and exported with "save 10PEC cycles".
However my PECPREP data is 2 weeks old, so the phase would be completely out.

First Results:
Data loads correctly and runs through the system generating pulses (Yaay - see log)
I set mine to pulse at 1, so that for every index i get a pulse.
This is because i have a completely smooth curve generated by PECPREP.
I am hoping that this will mean no conflicts with my guiding system.
(When i record this for real.)

Next if you get the file name  / location wrong the driver crashes.
I suggest if you have a blank file name / location, then just start recording.
(ie for somebody that wants to record manually from GPG guiding.)
If file name / location > blank and not found, then a write an error into the log, file not found.

I do not understand West Positive, ie. how to work out if i should change this.

Lastly, when i do this for real, i am not sure how to get the Dephase number.
For this test I just set it to 100, to see how it works. (ie. it moves the index out by 100.)

Log File attached and PECPREP data attached. 


 

The first point is not clear to me. You should acquire data with guiding OFF. What is "save 10PEC cycles"? You should save only the smoothed curve, a single cycle, in EQMOD format.


Did you check that 1ms pulses are really applied by the mount? The procedure assumes that every pulse is correctly applied, if they are skipped or applied with a different duration the correction will be off. I found that 10ms seemed to undercorrect, so used 20ms.

Yes, there are many checks missing at this point. Will fix them later.

"West positive" is simply the polarity of the correction, which depends on how your camera is oriented, i.e. if a West correction will move the image toward negative or positive image coordinate. You have to try. If after PEC the error increases by about a factor of 2, you have to change direction.

Dephase is the index at which your PE curve changes sign for the first time. It is needed to avoid a big correction step at the beginning of the training. In fact, when the PE curve changes sign the correction needed to nullify the error is almost zero.

Okay, making a bit more sense to me now.

Apologies have not had a good oppertunity for last 2 weeks, so have not been able to get a decent night to do this.
The reason i needed to drop down to 1ms is because my PEC cycle was generated off guiding data, where correction where being applied to the mount.
at 20ms, there are hardly any pulses applied with my (incorrect) data. I will need to do this with a log where mount corrections are not applied.

I suspect the west positive means west pier side as well. But would need to confirm this.

I think i understand dephase now, ie. in the data it will be a series of negative, then switch to positive for a while and then back to negative.
You want to count the number of pulses 1 per second to get to the point where the switch over happens. - Got it.

I think i am all ready now to try this for real, where the rain clears later this week.