I have a CGEM DX mount, I use an OAG with Camera (SX Lodestar) and guide with Phd2 using PPEC. My polar alignments generally are good (I can view Polaris and run the routine 3 times to tweak the final alignment), the drift results in Phd2 indicate a PA Error of 1-3'. I imaged at two targets last night, both near the EQ and Meridian and both for an hour or more. My Phd2 guide was good (for my equipment) with RMS total values around 1.2". While imaging I collected 14 cycles of PEC using the PEC tool in the Indi Control Panel for the CGEM mount. I took the multiple cycles because I read that the best data is an average set of 3,6,9 or 12 sets of PEC data. First, I would find an index and then begin guiding. The tool would collect data for all 88 points and save the data to a file, it then indicates index found and I could record another set of PEC data.

I am looking at the data in an excel spreadsheet and I am confused by what I see. The data cycles are all over the place, some start going negative, some start going positive; none look like a "classic" PEC curve of one cycle or even more. The only thing they have in common is that they all start at value 0 and all end at value 0 (I assume drift is removed). The excursions of the data are similar; the positive and negative peak values are about the same for each set, but they don't occur at the same point in the cycle (not even close). I had assumed that while the data is collected starting at any index, the output data (to the file) is registered to the same starting index for all the cycles (Question 1: is this correct?). If I just average all 14 cycles the resultant curve is all positive with some squiggles. I might consider flipping some curves so they all start going in the same direction, but I don't have a justification for doing this.

So, I understand that the added value of using a stored set of PEC data for the CGEM may be of marginal value, the PPEC guiding routines do a pretty good job of taking care of that. But I have also read that people have found some improvement in doing so and we are all looing for the best guiding we can achieve.

Can someone explain what the PEC collection part of the CGEM Indi control panel is doing or at least point me to where I can look at the code to try to figure that out myself. Does anyone have any experience taking PEC data using this tool and have results of using the PEC stored in the mount?

I looked for indi on Github and I did find some items associated with PEC data and Celestron Mount. It does seem that they remove the drift from the data before it is stored and they right the data to the file using the index as the data reference counter, so I believe they are stored in order from 0 to 87 bins (or something like that). But it does not explain why my PEC data is so uncorrelated, escept maybe because I am running a Predictive PEC algorithm in Phd2 and that is constantly making corrections of the PEC of the mount, so every cycle may be different. But you would think at some point the Predictive PEC would start to look the same as it has the mount calibrated.

I may have to are-runthe experiment using a different Phd2 algorithm as the Celestron PEC collection is expecting you to be manually guiding the mount (assuming the PEC routine has not been updated since the manual was written!). Is there anyone with better information?

thanks,

You post is prompting me to try recording PEC for the 1st time. I normally run PPEC in Phd2, but I was thinking that I'd go back to the Hysteresis algorithm while recording the PEC on the assumption that I might be recording a corrected PEC as the PE.

Good Luck,
I did just that tonight. I had fairly good seeing, started out in PPEC, but then switched to the Hysterisis algorithm and let that guide while I recorded PEC data at the mount (guiding was not too different from when I used PPEC, it can give a total RMS around 1"/px, with Hysterisis I was getting around 1.4"/px). I use the routine built into the Indi control panel for the Celestron CGEM mount. I recorded 6 cycles, each starting at different index values. I have not had a chance to review all 6 sets of data, but from what I did look at I am still seeing that they don't appear to be in phase. I wish someone would confirm for me that the data stored in the file in the Pec_Data folder is actually ordered from index 0 to 88, rather than in the order the data was taken (I don't always start at index 0 as the index continues to increase and I start one set after I have recorded/saved the previous set, so there is an offset in the index value between saved sets). As someone has suggested maybe I am just wasting good imaging time and should just guide with PPEC and not worry about putting a PEC curve into the mount, but I am stubborn.

Please, let me know how you make out. I would love to have some verification that what I am trying will work.

thanks,

OK, from last night, here are 5 PEC recordings from my CGX, using Hyteresis rather than Predictive PEC in Phd2.

My guiding was consistently above 1", which is unfortunately not unusual for me. There were wind gusts up to 10 km/hr during the shooting.


Not sure what this says, but I believe it.

Those do look consistent and could be averaged to something meaningful. Mine look like this, for 6 cycles:



I am running Kstars/Ekos on a Rpi with Ubuntu OS, so I cannot run some other outside programs to record PEC data. In the Indi Control panel for the mount there is a section for recording and playing back PEC. last night I started guiding using Hysteresis in Phd2, after I found the current mount index. The first run the index was at (50) and I let it record and save to a file. I did the same for the next 5, however I could not always start them at the same index, so my data started at different Index values; they are: 50 - 0 - 3 - 14 -15 - 0. From my data you can see that run 2 and 6 look the most alike (both started on index 0). While series 4 and 5 (both around index 14) look like flipped versions of each other (I have read that can happen). I had looked at the CGEM Indi program on Github and it looked to me like the data was always printed out from index 0 to 88, but maybe that was just the order of collection and not the actual index value that the data recording started. In other words the data was not re-arranged to produce a listing always starting at index 0, instead it is just recorded from 0 to 88 values starting at whatever index value you clicked record on. At least that is what I think based on the data I collected using the Indi Control Panel for the Mount in Kstar/Ekos.

How did you collect your data, were you careful to make sure each run started on index 0, or are you using the PECTool outside of Kstars/Ekos where it can record multiple PEC cycles?

I did not want to wait another 8 minutes between PEC records to make sure they started at the same index value, but it looks like I may have to in order to get good PEC data. I am going to 'play' with my data to see if I can shift the other sets of data into something that looks like cycles 2 and 6.

thanks for following up on this.

I also am running on Ubuntu mate, after seeing that the driver knew what index it was on, I just recorded them regardless of the current index.

Wow, your data came out way better (more similar) than mine did. I have run over 20 sets of PEC recordings using different guiding algorithms and of them I only have 2 sets that look similar!!

I did take my two '0' index curves, averaged them and used PECPrep to smooth the curve as I have read that you could introduce spurious frequencies into the guiding if the data is too jagged. I am not sure how much of an issue that is really, but it was fairly easy to smooth the data.

After averaging, my PEC curve would look like this.



Of course what gets loaded up is just the list of 88 points, this is just a plot of those points. The only real test is to upload the data into the mount and see if your guiding improves with the PEC data enabled over that without it.

thanks,

I have considered purchasing a CGX mount, my CGEM is 12 years old, I hypertuned it a couple of years ago and after that its motion is much smoother and I can balance it so it stays put in almost any position. The motor gear boxes have multiple gears and there are many problematic frequencies. The CGX are belt driven and I assume are an improvement over the CGEM, but I have read (I do a lot of that) that people have issues with the CGX, even with its improvements. I can achieve (barely) sub 1.0"/px guiding on stellar nights. My skies are probably Bortle 4 and I live on the water in Eastern NC, so there is always humidity and upper atmospheric winds. If I had higher ambitions for this hobby I would probably upgrade to a Losmandy (if not the CGX). None of this explains why I am having such a hard time developing a PEC curve. The two nights I tried where both decent seeing (cold, clear, not much wind) and my guiding was respectable (less than 1.3"/px) for long periods of time.

I guess the good news of this thread is that I should be able to collect PEC data anytime I am guiding while imaging, the bad news is that I may just end up with many more randomly phased PEC curves.

Thanks for the comment about PECPrep. I'll try that out (through Parallels). On the advice of a more experienced astrophotographer, I had subtracted the linear fit data from my average curve data to de-trend the data before upload. Seeing conditions were poor enough last night, the results were inconclusive.

Where did you find the note about spurious frequencies?

Cheers

I am looking, but can't seem to find it (I have read so much over the last couple of weeks). It may have been something I read about either "Metaguide" or "PEMPro" software and their use in either guiding or recording PEC. The CGEM has a complicated gear box which produces a number of frequencies that are difficult to guided out. If you add a PEC curve that includes these frequencies, you could be complicating the job that Phd2 has to do. The solution, I recall, was to smooth your PEC curve to only include 'integer' frequencies, almost sinusoidal. Then you are addressing only the 'fundamental' frequency with the PEC and using Phd2 to try to address the remaining error. At the risk of "chasing the seeing' it was suggested to reduce the Phd2 sample time to address these 'other' frequencies. The original document on "PECTool" from Celestron suggests using multiple of 3's in collecting PEC data (3, 6,9) and average over these, and the reason for that was to try and average out the "8/3" frequency, which is symptomatic of the CGEM.

Your mount is likely totally different as it is 'belt' driven and probably avoids a lot of this issue. I hypertuned my mount myself, with a kit, and I have swapped gears in the motor gear box to try and find the smoothest gears for the RA axis (as DEC guides fine in one direction) . It is a never ending saga until you finally say; I give up and just guide the best you can with Phd and do some imaging. My solution was to purchase a Starizana .63 x reducer and use my SCT 9.25 at f6.3 instead of f/10. And in fact I have ordered, when available, their NightOwl reducer, which takes the scope to f/4 and should make guiding much less important as I can image much faster.

But as I mentioned the only way to 'know' if your PEC is working is to run Phd2 with and without PEC enabled and look at the results.

I believe this is where I read that you could make things worse with PEC if you enhanced frequencies that Phd2 could not address.

Cloudy Nights PEC on CGEM thread

thanks,
Ron