Balancing scope for Guiding

[Colm Brazel]

Hi,

I'm wondering how critical is good scope balance for good guiding?

For example, Drift method will presumably give good accurate polar alignment on completion, but if perhaps the scope has first been balanced in RA, then in Dec, it may appear to be balanced but in fact balance in RA will be offset and will later show up in scope tracking and guiding problems. Good practice is to first balance in Dec.

I've also read scope when tracking east could benefit from a couple of extra ounces to push against motors that would also help remove backlash. 

When balancing scope its important to have scope fully loaded with cameras and dew shield or whatever it needs for the imaging session, however I assume focusing the scope in the case of a long FL approx 2000mm + in case of SCT 11" or approx 1750mm with Focal Reducer will move the focuser tube and the large objective mirror of the SCT, so can this disturb the scope balance and potentially prevent good calibration/tracking.

PHD2 currently loads no procedures/methods or measurement tools that can focus on errors due to a scope balance problem or a flexure problem. These can only be deduced by analysing the logs and observing tracking results. Maybe some gyroscope tool could be designed to attach to scope to measure rotational imbalance before a session or one that could be added to guidescope to measure flexure by comparing measurements to scope measurements. 

My main question is how fussy do you need to be to get good balance of you scope and its load before calibration and drift alignment. 

Cheers,

Colm

[bw_msgboard]

I think this all depends on the mount.  With the big AP mounts, for example, you could probably sit on the Dec axis and it wouldn’t matter. <g>  I’ve never heard of anyone worrying about it at the level you’re talking about.  If you can’t change focus without causing a problem, the mount is probably not capable of imaging.  I don’t understand what you’re asking with regard to polar alignment, I don’t see why the balance would change based on where the RA axis is aligned.

 

I’ve heard of some imagers who check balance by connecting an ammeter into the circuit between the power supply and the mount motors.  By watching the current draw as they slew the scope, they can know if either axis is significantly imbalanced.  I’d guess something along these lines might be how the Paramounts detect load imbalance.

 

Bruce

 

---

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Colm Brazel]

Hi Bruce,

" I don’t see why the balance would change based on where the RA axis is aligned."

Not so much where its aligned but the sequence of balancing Dec first, I found this here:

https://starizona.com/acb/basics/using_balancing_gem.aspx

"Balancing Theory

Why do you have to balance a German equatorial mount's optical tube first?  The reason lies in the position of the center of gravity.  If you do not balance the optical tube first, the center of mass of the tube is offset, meaning the position of the counterweights on the shaft will be incorrect.  Even if the telescope seems balanced in one position, when pointed to another area of the sky it may not be balanced.

 

If the telescope tube is not balanced first, then the center of gravity (CG) of the system is not along the counterweight shaft axis.  This will cause the counterweight to be placed too close to the telescope."

Thanks for clearing that up, I guess the issue is more of an issue with lighter grade mounts where imbalance on a smaller scale can be more pronounced.

Before I go, could I pick your brain on a solid and reliable software closely coupled with PHD2 for windows 10. I use EQASCOM with Stellariumscope also EQASCOM with Cartes du Ciel both through Synscan PC Direct. But I'd would like to compare these to others if there are any out there or if you have any general advice on compatible software for windows 10.

Thanks

Colm

On Thursday, January 14, 2016 at 7:18:37 PM UTC, Bruce Waddington wrote:

I think this all depends on the mount.  With the big AP mounts, for example, you could probably sit on the Dec axis and it wouldn’t matter. <g>  I’ve never heard of anyone worrying about it at the level you’re talking about.  If you can’t change focus without causing a problem, the mount is probably not capable of imaging.  I don’t understand what you’re asking with regard to polar alignment,

 

I’ve heard of some imagers who check balance by connecting an ammeter into the circuit between the power supply and the mount motors.  By watching the current draw as they slew the scope, they can know if either axis is significantly imbalanced.  I’d guess something along these lines might be how the Paramounts detect load imbalance.

[bw_msgboard]

There really isn’t any “close coupling” between PHD2 and any of the mounts – if the driver complies with the ASCOM standard, that’s all that matters.  I’ve seen the EQASCOM documentation, and they seem to have a bunch of UI controls for diddling around with guide pulse sizes or otherwise affecting the guiding process.  With PHD2, those would be bad things to do, so you should stay away from that stuff.  Many others use EQASCOM with PHD2, so you shouldn’t have a problem with that single caveat.

 

In the image capture arena, it’s a different story.  Both Sequence Generator Pro and Nebulosity can interact with PHD2 to accomplish things like dithering.  There may be others as well, but those are two I know about.  We’ve also supplied a means for controlling dithering from MaximDL, but it’s a bit more cumbersome.

 

Bruce

 

---

[Colm Brazel]

Bruce,

Ascom has Pulseguide settings where you can tick a box to have the RA rate and Dec rates altered. Are you saying these should not be ticked.

What about the buttons for choosing lunar and solar siderial rates in particular underneath these a box for RA and Dec which 

simulator has assigned 15.041067 for RA and Dec 0, I don't know what those measurements are for.

Basically, what are the best settings to leave EQASCOM at for PHD2 to best work with.

I use Nebulosity probably a dumb Q to ask but here goes:) Nebulosity can connect to PHD2 and can use various bin modes but what does it do that for? Does it allow you to start another instance of Nebulosity that controls your guide camera while your main camera controlled by another instance of Nebulosity. Does Nebulosity then download into the PHD2 window, can't see the doc that describes connection of third party apps to PHD2 and what functionality advantage it gives.

Also had a long PHD2 session last pm well into the am, succeeded using Guiding Assistant/calibration polar alignment error down to 1 arc sec approx but things went wonky after that. I'm shortly moving because of these problems over to OAG as the probs could be flexure related though I paid careful attention to this in preps. Scope I was using SCT at long 2800mm with Orion 80mm piggybacked and Orion G3 monochrome as guide camera. 

One peculiar behaviour in the graph output was the red dec diverging from RA and appearing south of RA. RA throughout the evening seemed to be spot on but DEC was problematic. Looking at the PHD2 log analyser help doc it could mean no pulseguide commands were sending Dec north so it was guiding south. At various points I would have changed guide mode from auto, to north, to south to off to try to improve matters to no avail. In hindsight I should have left it at auto but don't know what the point is for north/south or off. 

I notice PHD2.6 has now a dec backlash measurement tool part of the Guiding Assistant. Not sure why its there as Dec backlash is it not measured and eliminated during calibration, also it takes a good while to complete. It didn't improve my results. Hoping to do better with OAG.

Cheers,

Colm

[Colm Brazel]

couple of guide logs attached to last post.

[bw_msgboard]

 

 

---

From: Colm Brazel [mailto:colmb...@gmail.com]
Sent: Saturday, January 16, 2016 4:24 AM
To: Open PHD Guiding
Cc: colmb...@gmail.com; bw_m...@earthlink.net
Subject: Re: [open-phd-guiding] Balancing scope for Guiding

 

Bruce,

 

Ascom has Pulseguide settings where you can tick a box to have the RA rate and Dec rates altered. Are you saying these should not be ticked.

 

I’m not an expert with EQASCOM, which for clarification is *NOT* part of the ASCOM standard, it’s just one implementations of an ASCOM driver.  The PHD2 requirements for an ASCOM mount driver are pretty simple: 1) set the guide rates in the mount, 2) deliver the guide commands accurately without modification, and 3) butt out.  The vast majority of ASCOM mount drivers do exactly that.  Based on just looking at the EQMOD documentation, you need to enable pulse guide support, then set the RA Rate and DEC Rate values you want.  I would start with something in the range of 0.7 to 0.9 for both axes.  These values will strongly affect the PHD2 calibration, so if you change them, you need to recalibrate. Do NOT set either of the RA/Dec pulse width override sliders and do NOT diddle around with any of the sliders in the PulseGuide monitor.  You would be far better off not using the PulseGuide monitor at all, just use the visualization tools in PHD2.

 

What about the buttons for choosing lunar and solar siderial rates in particular underneath these a box for RA and Dec which 

simulator has assigned 15.041067 for RA and Dec 0, I don't know what those measurements are for.

 

Since you’re guiding with PHD2, I assume you’re trying to do deep-sky imaging.  So clearly you want to have the tracking rate set to sidereal.

 

Basically, what are the best settings to leave EQASCOM at for PHD2 to best work with.

 

I use Nebulosity probably a dumb Q to ask but here goes:) Nebulosity can connect to PHD2 and can use various bin modes but what does it do that for? Does it allow you to start another instance of Nebulosity that controls your guide camera while your main camera controlled by another instance of Nebulosity. Does Nebulosity then download into the PHD2 window, can't see the doc that describes connection of third party apps to PHD2 and what functionality advantage it gives.

 

The PHD2 server interface allows another app, typically an image capture app, to control start/pause/stop of guiding and more importantly, dithering.  Nebulosity can do that as can Sequence Generator Pro.  The other things you’re asking about in Nebulosity don’t appear to me to have anything to do with guiding, but I’m not familiar with the app.

 

Also had a long PHD2 session last pm well into the am, succeeded using Guiding Assistant/calibration polar alignment error down to 1 arc sec approx but things went wonky after that. I'm shortly moving because of these problems over to OAG as the probs could be flexure related though I paid careful attention to this in preps. Scope I was using SCT at long 2800mm with Orion 80mm piggybacked and Orion G3 monochrome as guide camera. 

 

One peculiar behaviour in the graph output was the red dec diverging from RA and appearing south of RA. RA throughout the evening seemed to be spot on but DEC was problematic. Looking at the PHD2 log analyser help doc it could mean no pulseguide commands were sending Dec north so it was guiding south. At various points I would have changed guide mode from auto, to north, to south to off to try to improve matters to no avail. In hindsight I should have left it at auto but don't know what the point is for north/south or off. 

 

I notice PHD2.6 has now a dec backlash measurement tool part of the Guiding Assistant. Not sure why its there as Dec backlash is it not measured and eliminated during calibration, also it takes a good while to complete. It didn't improve my results. Hoping to do better with OAG.

 

Backlash is not explicitly measured during calibration.  The calibration process does try to clear Dec backlash to improve the quality of the calibration, but it may only be partly successful.  The GA lets you measure it directly and make an informed decision about what to do.  The guiding options for North/South/None are there to help handle mounts with severe Dec backlash.  That is covered in the help docs.

 

You guide log shows you got a hideous calibration, and you should have gotten alerts about that.  It looks like we couldn’t move the mount east at all, and the orthogonality error is huge.  Until you get these problems sorted out, your guiding results are likely to be poor.  Use the LogViewer tool to look at your most recent calibration results, then compare those to what you see in the help docs.  Do you see that the “east” data points don’t go in the right direction at all?  And the ‘south’ commands don’t move the mount at all?  And the red and blue lines aren’t even close to perpendicular?    This is basic stuff, so you might need to run the “star-test” described in the help docs.  Until you can get repeatable results with that, you will continue to have problems.

 

Good luck,

Bruce

[Colm Brazel]

Bruce,

Thanks Bruce that's of major help. Though i checked with calipers if the scope was centered in its rings end everything locked down a major omit was not to check guidescope orthogonal to main scope by insuring target image equally centered during daytime in  both guidescope and main scope diagonals.  The checkbox " assume Dec orthogonal to RA" I ticked inadvertently thinking any orthogonality errors would be compensated for. I needed a far more careful approach to doing all of the above. 

I did notice during the evening some of the manual guide buttons did not appear to be getting an audible response from PHD2 and now see in the help docs you can use this as a diagnostic tool pointing to possible orthogonal errors

"If you are debugging mount/calibration problems in the daytime, listen to (rather than watch) your mount to determine if it is getting the commands from PHD2. The idea here is just to figure out if the mount is responding to PHD2's signals. You won't be able to see the mount move (it's moving at guide speed) but you may be able to hear the motors."

Thanks again for pointing me towards the 'star test'. I'll include some pointers to it here in case someone not familiar with this and maybe overlooked this as I did:

from http://stargazerslounge.com/topic/188777-phd-guiding-basic-use-and-troubleshooting/

Camera non-orthogonality causes elongated stars. This means that the camera sensor is not exactly perpendicular to the telescope’s focal plane, so the stars get stretched in the direction of greatest tilt. You can diagnose this problem as follows:

- Aim the telescope at a group of bright stars about 40 or 50 degrees above the horizon and take a short exposure of a few seconds, long enough to capture the stars but short enough that you would not get trailing due to poor tracking. Look at the image and see if all the stars are elongated in the same direction. If so, it is likely that you have non-orthogonality.

- Now rotate the camera through 90 degrees with respect to the telescope and take a second short image. Figure out which direction is ‘down’ towards the ground in each of your pair of images. If the elongation in both images is in the up/down direction, then you most likely have a problem with the focuser or other element drooping under gravity.

- If the direction of elongation changes as you rotate the camera, then you probably have a mechanical problem in the imaging train. Very occasionally the problem can be with the camera sensor not being parallel to the mounting ring on the camera body, but it is more likely that something is cross-threaded or not fully screwed together. I recently had a problem with a retaining ring in a light pollution filter that was not fully screwed in and this caused the camera to about 0.5mm off true."

Though I'm not sure how to figure out what is up and what is down in star image I'm sure I'll figure it out. 

I'm off to read nb star cross test again  http://openphdguiding.org/man-dev/Trouble_shooting.htm#Star_cross_test

Cheers,

Colm

[Colm Brazel]

No worries about figuring up/down 

"The angular orientation doesn't matter, that's just a function of how you have the guide camera rotated.  What is important is that the lines in the cross are perpendicular and have roughly equal lengths in each of the four directions relative to the starting point in the center.  If the image you get doesn't have this approximate appearance, guiding will either be impaired or perhaps impossible.  For example, consider the following poor result:"

from star test link.

Colm.

On Thursday, January 14, 2016 at 11:02:16 AM UTC, Colm Brazel wrote: