One last question: How is a linear trend accounted for? IMHO it should be considered separately as there will always be some trend due to polar misalignment, atmospheric refraction, clutch slippage, etcetera. A trend is a non-periodic signal so when not properly accounted for, it may to additional errors rather than reduced errors.


I have a question about the GPG period in seconds. I noticed that it must be an integer. If the period of my mount is 239.5 seconds, then after an hour (15 periods of 240 seconds) it will be 15*0.5=7.5 seconds off a multiple of 240. Does that mean that my GPG will then be out of sync by 7.5 seconds if I enter 240 as the period, and don't click the "estimate period" checkbox (as recommended)? If it does, can the integer period be changed to a floating-point number?



I typed the upgrade commands, and still have KStars 3.5.5. I started with the stable Astroberry release, which is 2.0.4. Let me go over to the astroberry site, see what's the deal there. Maybe I need a development release.

Anyway, not a big deal: at least in 3.5.5 an older problem has been fixed where the scope would keep turning if I would let Ekos do the automatic turning (could be an LX200 OnStep driver issue, not sure). So, I can now live without the manual settings and upgrade sometime later. Having a stable release is worth something.


I just installed Astroberry 2.0.4 and found that there's a problem with the PA. It tells me that the manual settings (slew E/W, manual slew) were greyed out because the FOV was less than 10'. But at the same time, it had just calculated that my FOV was 109' x x73'. See the image below. Clearly, my FOV is larger than 10' and the controls should not be greyed out.

Another minor issue, after doing a polar alignment it shows the position of the NCP quite a bit away from where it really is. Compare the Stellarium image below with the image above. Look at the 5-star asterism, and you can eyeball that the NCP in the above image is several arc minutes away from where it is supposed to be. This may just be a display issue because I had just done a polar alignment, and the RA and NCP positions are as close as I would expect them to be.


I have enjoyed using the plate solving based polar alignment tool. The GUI is very nice, and it is fun to use. I have used it a lot.

I recently tested the accuracy of this procedure and found that it can be 5 arc minutes off no matter how well I try to perform the procedure. I can get better accuracy manually using the FITS viewer. Here is how it works:

1) Start out with an OTA and mount position where the RA rotation axis contained in the FOV.
2) Rotate the mount while taking a 20 second sub at high gain, preferably at low resolution (4x4 binning) for maximum processing speed.
3) After verifying that the center of the star tracks is in the FOV, save the image as circles.png.
4) Load circles.png back into the FITS viewer. It opens it up in a new tab, say, tab 2. You can switch between tabs 1 and 2 using Ctrl-Tab.
5) Start taking 1 second subs at high gain in a loop (the cycle button). Tab 1 will now refresh with a new image every second.
6) Go to the circles tab (tab 2) and put your cursor on the center of the tracks.
7) Switch back to tab 1 without moving the cursor (use Ctrl-Tab).
8) Double-click and a bull's eye is created. This is now exactly where the RA axis is located in the FOV.
9) Use the Alt/Az controls to move the NCP on top of the bull's eye. This is easy because the subs refresh every second.

You can eyeball the position of the NCP in step (9) by looking for the below asterism:

The eyeballing accuracy is about 1', which is better than the 5' error that I got with the plate solving based polar alignment. This is apparently not unusual as it was also noticed by some users who tested similar tools with similar results. For reference, the star tracks corresponding with this image are here:

Step (1) is not trivial if you start out from scratch. However, if you have the habit of putting the scope on marked feet locations on pavers, for instance, you will have little trouble doing this. If it is a problem, you can start out with a regular plate solving based polar alignment and finish up with the above for best results.

This method is a derivative of my old method where I used a DSLR and a piece of tape with a needle hole in it to mark the center of rotation on the DSLR's LCD screen. Then I would take subs to move the NCP to the needle hole. No computer required, and quite accurate.

Hope this helps. It is easy to use and only requires one rotation, so it is relatively quick. It is fun, too. I am curious to hear what kind of accuracy others achieve with the plate solving based method.


Henk Aling replied to the topic 'Problem with Polar Alignment' in the forum. 10 months ago

Checking the manual slew button for PA works fine. Someone else pointed that out when I asked the same question in this thread some months ago. The PA of Ekos works really well, very nice implementation.


For my AVX with the QHY5/SSAG autoguider I cannot get autoguiding with pulse guiding working.  This is for Kstars 3.5.2. 

What I see is as follows:  RA forward n steps, RA reverse follows with n steps in the same direction as RA forward, then keeps going in the same direction with steps twice as large.  It continues until it fails. 

I tried this on numerous nights (thinking I was doing something wrong) with various step sizes and both smart and multistar autoguiding so it is very reproducible. Fortunately after I connected the ST4 cable and selected guiding via the QHY5, everything works fine.


Henk Aling replied to the topic 'Problem with Polar Alignment' in the forum. 2 years ago

HI CapnRon

I followed your advice doing the slew manually and everything works fine like you said. Who needs an automatic slew, anyway. I'm fine with it now and am certainly impressed with the feature, having used it once now.