I tried to use Feature Tracking for the eclipse today with my Vixen GP. The mount was just adjusted yesterday by a very experienced guy to remove all but the tiniest bit of backlash. The movement on both axes is as smooth as butter. But SharpCap couldn't calibrate Feature Tracking because the rates are different in + and - RA, regardless of balancing. Moving the mount with the hand controller works just fine.
I have never owned a mount that had anywhere close to equal rates in RA. I don't understand how a mount can even have equal rates in RA. Every mount I've had has been snappy to the east and slow to the west. The mechanics are just different in the two directions because the mount is tracking in RA, regardless of the scope being well balanced and east heavy so that the RA gear is always engaged.
Please allow different guide rates in +RA and -RA. If the mount moves, reaches the minimum number of pixels moved, and slopes are measured, it should not matter if the forward and backward slopes are different. I think this would help a large number of people who can't currently get FT to calibrate.
Thanks for your consideration.
Allow different +RA and -RA rates in Feature Tracking
Forum rules
'+1' posts are welcome in this area of the forums to indicate your support for a particular feature suggestion. Suggestions that get the most +1's will be seriously considered for inclusion in future versions of SharpCap.
'+1' posts are welcome in this area of the forums to indicate your support for a particular feature suggestion. Suggestions that get the most +1's will be seriously considered for inclusion in future versions of SharpCap.
-
admin
- Site Admin
- Posts: 13370
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Allow different +RA and -RA rates in Feature Tracking
Hi Mike,
sorry to hear that the calibration didn't work. Was it measuring the rates OK and then bombing out because they were too different? If so, can you see if you can find the rates in the log so that I can understand how far out they were (there is already some latitude for different rates in + and -).
cheers,
Robin
sorry to hear that the calibration didn't work. Was it measuring the rates OK and then bombing out because they were too different? If so, can you see if you can find the rates in the log so that I can understand how far out they were (there is already some latitude for different rates in + and -).
cheers,
Robin
Re: Allow different +RA and -RA rates in Feature Tracking
Robin,
Yes, it was measuring them just fine. The rates are just very different, by almost an order of magnitude, like 60 vs 8. Can’t say i understand it, as it does not match my experience of manually slewing with the hand controller or the screen controls. I was easily able to manually bump the pointing in any direction I needed to put my target sunspot back on the reticle crosshair after I gave up on Feature Tracking. It was just a distraction during the event, particularly since I wasn’t able to polar align.
Cheers,
Mike
Yes, it was measuring them just fine. The rates are just very different, by almost an order of magnitude, like 60 vs 8. Can’t say i understand it, as it does not match my experience of manually slewing with the hand controller or the screen controls. I was easily able to manually bump the pointing in any direction I needed to put my target sunspot back on the reticle crosshair after I gave up on Feature Tracking. It was just a distraction during the event, particularly since I wasn’t able to polar align.
Cheers,
Mike
-
admin
- Site Admin
- Posts: 13370
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Allow different +RA and -RA rates in Feature Tracking
Hi Mike,
I'm going to guess that the movement in the direction of tracking was probably the fast one and the opposite movement was slow (good to have that confirmed though). Was the backlash compensation done in software or by making hardware adjustments to the mount (adjusting the worm bearings, etc). I could imagine a software compensation potentially being an issue, but if it was hardware then all should be fine.
I presume that if you press the left/right buttons in SharpCap with the speed set the same as you use in calibration, the image moves at the same rate in both directions... That would confirm that the mount is picking the rate SharpCap asks for in each direction. If you are tracking then maybe it will be off by 1x sidereal depending on whether or not the mount adds in the tracking rate, but that would only make 8x be 7x one direction and 9x the other.
I wonder if it's a timing thing...
If SharpCap asks it to move in the tracking direction at say 8x then it just gets going, moves for the 1s that SharpCap requests and goes back to tracking. Maybe with a request to move in the opposite direction there is some delay before the mount actually reverses and gets going, so you don't get the full 1s of movement that is requested.
Somewhere there has to be a (somewhat) logical explanation for the massively different rates, and understanding the why is probably more valuable that just allowing enormously different rates for the two directions.
cheers,
Robin
I'm going to guess that the movement in the direction of tracking was probably the fast one and the opposite movement was slow (good to have that confirmed though). Was the backlash compensation done in software or by making hardware adjustments to the mount (adjusting the worm bearings, etc). I could imagine a software compensation potentially being an issue, but if it was hardware then all should be fine.
I presume that if you press the left/right buttons in SharpCap with the speed set the same as you use in calibration, the image moves at the same rate in both directions... That would confirm that the mount is picking the rate SharpCap asks for in each direction. If you are tracking then maybe it will be off by 1x sidereal depending on whether or not the mount adds in the tracking rate, but that would only make 8x be 7x one direction and 9x the other.
I wonder if it's a timing thing...
If SharpCap asks it to move in the tracking direction at say 8x then it just gets going, moves for the 1s that SharpCap requests and goes back to tracking. Maybe with a request to move in the opposite direction there is some delay before the mount actually reverses and gets going, so you don't get the full 1s of movement that is requested.
Somewhere there has to be a (somewhat) logical explanation for the massively different rates, and understanding the why is probably more valuable that just allowing enormously different rates for the two directions.
cheers,
Robin
Re: Allow different +RA and -RA rates in Feature Tracking
The mount had just been mechanically adjusted the day before to remove all but the smallest amount of backlash (a little is needed to avoid binding). I don't believe the EQMOD software has any backlash compensation, at least none that I can see on the setup while not connected to the mount at the moment.
Most of the manual corrections were in DEC, of course. The sun was drifting north, so corrections were mostly to the south. But I did correct east and west occasionally as well. Those corrections were smaller, but they worked fine.
Typically the behavior I see on my CGEM (where I usually have an 8.5X finer image scale and it is very easy to see what is happening) is that moving east responds instantly and the mount stops on a dime, while moving west is much slower and the mount will overshoot after you stop the command before drifting to a stop. As I recall from Monday with the Vixen GP, I believe I actually switched the snappy direction from being east and the slow direction being west to the opposite when then scope became west heavy after the (unanticipated, oops) meridian flip and I did not think of readjusting the counterweight. But in normal operation the mount should always be east heavy, and the snappy direction is always east and the slow direction is always west. This is in line with the SharpCap calibration (I think), which I believe does -RA first and +RA second. -RA took many steps to clear the backlash (or perhaps stiction) and eventually get out to the 100 pixel minimum movement, while +RA took only 4 or 5 as I recall.
One thing that I remember distinctly from RA calibration was that when SharpCap was measuring to the west, the image would move and then subside back, meaning that the final measured movement was smaller than the maximum movement that the command produced. I'm not sure what this indicates is happening mechanically. It's difficult to envision what exactly is going on when commanded to the west, given that the mount is tracking east continuously (which is why I don't even know that we should expect the same rate east vs. west; how is that even possible). Does this indicate that the mount was too east heavy? It's a difficult mount to check balance on. The load is light and the grease is of a very sticky type. The grease is clean and the motion is butter smooth, but if you are anywhere close to balance the grease stops any rotation almost immediately and it is hard to check the exact balance.
I would offer the logs but I was desperately moving the counterweight up and down and even removing and adding weight, which there is no record of, so I'm afraid it would be nothing but a mess to try to interpret. The next time I use the mount for DSO imaging I will make sure it is as properly balanced as I can make it and run a Feature Tracking calibration using a bright star and send you the log.
Most of the manual corrections were in DEC, of course. The sun was drifting north, so corrections were mostly to the south. But I did correct east and west occasionally as well. Those corrections were smaller, but they worked fine.
Typically the behavior I see on my CGEM (where I usually have an 8.5X finer image scale and it is very easy to see what is happening) is that moving east responds instantly and the mount stops on a dime, while moving west is much slower and the mount will overshoot after you stop the command before drifting to a stop. As I recall from Monday with the Vixen GP, I believe I actually switched the snappy direction from being east and the slow direction being west to the opposite when then scope became west heavy after the (unanticipated, oops) meridian flip and I did not think of readjusting the counterweight. But in normal operation the mount should always be east heavy, and the snappy direction is always east and the slow direction is always west. This is in line with the SharpCap calibration (I think), which I believe does -RA first and +RA second. -RA took many steps to clear the backlash (or perhaps stiction) and eventually get out to the 100 pixel minimum movement, while +RA took only 4 or 5 as I recall.
One thing that I remember distinctly from RA calibration was that when SharpCap was measuring to the west, the image would move and then subside back, meaning that the final measured movement was smaller than the maximum movement that the command produced. I'm not sure what this indicates is happening mechanically. It's difficult to envision what exactly is going on when commanded to the west, given that the mount is tracking east continuously (which is why I don't even know that we should expect the same rate east vs. west; how is that even possible). Does this indicate that the mount was too east heavy? It's a difficult mount to check balance on. The load is light and the grease is of a very sticky type. The grease is clean and the motion is butter smooth, but if you are anywhere close to balance the grease stops any rotation almost immediately and it is hard to check the exact balance.
I would offer the logs but I was desperately moving the counterweight up and down and even removing and adding weight, which there is no record of, so I'm afraid it would be nothing but a mess to try to interpret. The next time I use the mount for DSO imaging I will make sure it is as properly balanced as I can make it and run a Feature Tracking calibration using a bright star and send you the log.
-
admin
- Site Admin
- Posts: 13370
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Allow different +RA and -RA rates in Feature Tracking
Hi Mike,
thanks for the info - it gives me some things to think about, such as what happens when the move commanded is smaller than the mount backlash... If you move opposite to the tracking direction then the mount may eventually move the desired amount, but it will basically stop tracking in order to move that amount, so it won't do it at the speed requested (at least not from the point of view of the camera).
I have a couple of ideas I think, but will have to play around a bit to see if they work out.
cheers,
Robin
thanks for the info - it gives me some things to think about, such as what happens when the move commanded is smaller than the mount backlash... If you move opposite to the tracking direction then the mount may eventually move the desired amount, but it will basically stop tracking in order to move that amount, so it won't do it at the speed requested (at least not from the point of view of the camera).
I have a couple of ideas I think, but will have to play around a bit to see if they work out.
cheers,
Robin
-
admin
- Site Admin
- Posts: 13370
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Allow different +RA and -RA rates in Feature Tracking
Hi,
OK, having thought about this a bit, I think I can see a way to remove all the uncertainty about how the mount reacts to the movement pulse in opposite directions. That would leave a possible remaining issue with delays to the apparent movement on screen due to backlash takeup, which could be dealt with by a delay in measurement, but I intend to try one change at a time.
cheers,
Robin
OK, having thought about this a bit, I think I can see a way to remove all the uncertainty about how the mount reacts to the movement pulse in opposite directions. That would leave a possible remaining issue with delays to the apparent movement on screen due to backlash takeup, which could be dealt with by a delay in measurement, but I intend to try one change at a time.
cheers,
Robin
Re: Allow different +RA and -RA rates in Feature Tracking
Thank you, Robin. Still no chance to try to generate a log yet.
-
admin
- Site Admin
- Posts: 13370
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Allow different +RA and -RA rates in Feature Tracking
Hi,
no worries - I have made some code changes to allow the new idea to be tested out in the next version subject to using a command line parameter to enable it.
We had some clear skies and a crescent moon last night, so I tested feature tracking calibration against the moon. I was using 1800mm focal length with an IMX571 based camera (Altair 26C, ZWO 2600MC, etc equivalent). My mount is a Skywatcher NEQ6 with belt modification to replace the gears, currently using Green Swamp Server as an ASCOM driver. I gather that the Skywatcher mounts were originally clones of the Vixen ones.
Anyway, I had no trouble with calibration using either the old or the new algorithms at a variety of movement speeds from 'guiding rate' up to 8x. I did notice that the guiding rate calibration comes out opposite to the other rates - need to track down if this is a bug in the PulseGuide function of GreenSwampServer or in my code calling it.
cheers,
Robin
no worries - I have made some code changes to allow the new idea to be tested out in the next version subject to using a command line parameter to enable it.
We had some clear skies and a crescent moon last night, so I tested feature tracking calibration against the moon. I was using 1800mm focal length with an IMX571 based camera (Altair 26C, ZWO 2600MC, etc equivalent). My mount is a Skywatcher NEQ6 with belt modification to replace the gears, currently using Green Swamp Server as an ASCOM driver. I gather that the Skywatcher mounts were originally clones of the Vixen ones.
Anyway, I had no trouble with calibration using either the old or the new algorithms at a variety of movement speeds from 'guiding rate' up to 8x. I did notice that the guiding rate calibration comes out opposite to the other rates - need to track down if this is a bug in the PulseGuide function of GreenSwampServer or in my code calling it.
cheers,
Robin
Re: Allow different +RA and -RA rates in Feature Tracking
Good to hear. My GP is in the process of being torn down by a friend m to be de- and re-greased with a lubricating oil instead of a sticky grease. I am hopeful that will make the mount easier to calibrate and guide. It isn’t only SharpCap that had trouble; PHD2 could (sometimes) calibrate, but the guiding was terrible.
Cheers,
Mike
Cheers,
Mike