At the moment I am using two telescope descriptions in setting up EKOS. I have the main scope for imaging (and for guiding as I have an OAG), the second telescope is my e-finder; a small Orion 9x50 (fl 179mm) with a camera that I use only for plate solving (it it very fast because of its wide FOV) when I am moving to a new target.
At some point in the (hopefully ) near future I will receive a Night Owl reducer to drop the main SCT to F/4.0, with a fl of 940 mm. At that point I can no longer use the OAG as there is not enough backfocus distance. So I will need to add another scope for guiding. I already have an Svbony that has a fl of 290 mm and it will be used as my guide scope. I would like to keep the e-finder in place for plate solving during slewing, but that requires a third telescope description in EKOS.
Would it be possible to add a third telescope description to EKOS so I can keep my arrangement?
thanks
Read More...
To take my PEC cycles, I aim the scope at a target near the Meridian and Equator, set up Phd2 to be prepared to guide on a star in that area. In the mount Control panel, in Ekos, I select (in Motion Control) to find the mount index. The mount will move slightly and then indicate that the index is found. I then begin guiding in Phd2 and let that settle down after a few minutes. Then back in the control panel I select 'record PEC' and the recording begins of the 88 steps for my CGEM mount, while Phd2 is sending guiding commands to the mount. After that is complete a file is written, I save it in a folder labeled PECData. If guiding is still ongoing I can then select 'record, again and a second PEC set of data will be collected (for the CGEM mount it takes about 8 minutes to run a full gear cycle). (Note: i ran this PEC record process with two different guiding algorithms; first with PPEC and second with Hysteresis, just in case the PPEC algorithm somehow interfered with the PEC collection process) I have done this for multiple PEC cycles, which I then read into an Excel file (the files saved are of CSV type) In Excel I can average and smooth the curves to produce a final single PEC curve. Back in EKOS I load that file, in the Control Panel, and then select playback. The PEC data is now in the mount and being played back to correct the PEC of the mount.
Later I ran the Phd2 guiding assistant for several PEC cycles with PEC off (Disabled in Control Panel), with PEC engaged and with a negative of the PEC curve loaded (I have read that sometimes an inverted PEC curve is required). I found no consistent improvement in the outcome of the Guiding Assistant. So for my mount it does not seem that PEC (in the mount) will improve guiding. So I will continue to use the PPEC algorithm in Phd2 to compensate for PEC in the mount.
Read More...
I believe the Indi driver for the Celestron CGEM mount is reporting an incorrect 'Guide Rate." I have an updated hand controller for the CGEM mount. I recorded a verbose debug log during start up. A section of that log is attached
and I have copied the lines of interest here:
"2023-04-01T21:03:27.179 EDT DEBG ][ org.kde.kstars.indi] - Celestron CGEM : "[DEBUG] RES <80 23> "
[2023-04-01T21:03:27.179 EDT DEBG ][ org.kde.kstars.indi] - Celestron CGEM : "[DEBUG] Get Guide Rates: Ra 50.588235, Dec 50.196078 "
[2023-04-01T21:03:27.180 EDT DEBG ][ org.kde.kstars.indi] - < Celestron CGEM >: < TELESCOPE_TIMED_GUIDE_NS >"
I have the guide rate (both RA and DEC) at .5 Sidereal in the hand controller. The result above seems to indicate that the driver is interpreting that number as percent and not the actual value. Phd2 is computing a guide rate based on this value and reports (Phd2 debug log) a guide speed which is two (2) orders of magnitude too large, see below:
Calibration Begins at 2023-03-20 21:29:48
Equipment Profile = Feb11_23_f63_OAG_SX
Pixel scale = 1.20 arc-sec/px, Binning = 1, Focal length = 1480 mm
Search region = 15 px, Star mass tolerance = 50.0%, Multi-star mode, list size = 1
Camera = INDI Camera [SX CCD LodeStar], full size = 752 x 580, have dark, dark dur = 3000, no defect map, pixel size = 8.6 um
Exposure = 3000 ms
Mount = INDI Mount [Celestron CGEM], Calibration Step = 300 ms, Calibration Distance = 25 px, Assume orthogonal axes = no
RA Guide Speed = 756.8 a-s/s, Dec Guide Speed = 750.9 a-s/s
In actual guiding it is using this rate:
Norm rates RA = 9.0"/s @ dec 0, Dec = 8.2"/s; ortho.err. = 7.9 deg
I have not had any issue using Phd2 for guiding (other than what you might expect from an aging CGEM mount) but I would feel better if the info from the mount (as reported by the Indi driver) was in better agreement with the actual guide speed. I don't know if this could cause issues with the internal guiding of Kstars/EKOS (I have used the internal guider succesfully also) or any other aspect of the program. It would just be NICE to get this corrected, if in fact it is an error in the driver.
thanks,
Read More...
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
Read More...
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.
Read More...
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.
Read More...
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,
Read More...
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.
Read More...
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,
Read More...
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,
Read More...
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?
Read More...
I will answer my own question. I thought that the goto slew rate was set by the control panel options in Kstars, but it is likely not (I am not sure what setting the slew rate in the Motion Control tab of the mount control panel actually does other than set the default slew rate for the mount control panel to whatever you had set there).
I believe that Kstars (and maybe other programs) use the special slew rate "9" for programmed "goto's". I have a new hand controller for my CGEM (Nexstar +) and the procedure I used to set the actual slew rate of "rate 9" is this:
on the hand controller, use "Scope Setup", then "Custom Rate 9" enter to get to RA axis, then enter when you see enable, then it should show a rate number (mine was set at 4.50) you change this number (I first went to 3.50) and then back out (or Undo). Then enter on the DEC axis and do the same thing. Power down everything and power back up. the new "rate 9" value should still be there when you go back to that setting on the Hand controller.
I used a Kstars goto to check the speed. At the original setting (4.5) It moved very quickly (almost not enough time for me to stop it if something was going terribly wrong). When I change the "rate 9" setting to 3.50 I hardly noticed a difference. It was still way faster than setting of "7" or "8". So I went back and changed "custom rate "9" to 2.50. Now it was noticeably slower, so that I could tell the difference in motion. Still faster than 7 or 8 settings, but just barely so.
I did not discover this on my own, I just found this by searching.
Read More...
I read a previous thread that indicated you could set the goto slew rate in Kstars/Ekos by setting it in the Indi Control Panel for the mount and then save the configuration in the Options tab. I tried that and it does not seem to work for the Celestron CGEM mount . The mount slews to objects reasonably accurately, but too fast as it sometimes misses the target and takes multiple tries to achieve it.
I tried setting the slew rate to "6", it keeps resetting to "1" but that is not how fast it slews to targets in GoTo's. I set it to "6" got to Options and save, back to Motion Control Tab and it is reset to "1". But again it slews much faster than that.
If I open the mount tab and manually move the mount, that setting works correctly, but it does not effect the speed of GoTo motions.
Can anyone tell me if there is a way to set the slew fate for GoTo's for the Celestron CGEM mount?
thanks,
Read More...