RA Drift


Jamie Flinn
 

Hi All…

 

I was diagnosing guiding issue last night and solved a mechanical issue that put my guiding back into the realm of “normal”, but as part of that diagnosis I was using the PHD2 Guiding assistance and I was seeing as listed drift in RA that was westwards (read as too fast?) – this tool looks at the guide star without guiding motions, so the “lock position” vs real position is measured.  The drift was noticeable and something like 3” per minute.

 

So I move on and start guiding (got a whole night surprise surprise) and I can see that using INDI/EKOS I was again getting consistent guide-east pulses – put the two together and the obvious answer is the mount is running westward faster than sidereal

 

Pointing is great and I plate solve in very few iterations…but that westward motion I need to kill

 

Can I use the “Frequency –“  function for this (or is it perhaps Frequency + ?) – or would you suggest I play with the worm numbers in config?

 

This is every so slight but it does cause ping pong guiding in RA when DEC is hitting RMS values of 0.34

 

Thought? Opinions?

 

Cheers

Jamie

 

 

 

Sent from Mail for Windows 10

 


HenkSB
 

Polar misalignment can cause that, the amount depends on how it is misaligned and the declination of the target.  I use Ekos with plate solving based polar alignment, in my experience that works very well.

Alternatively if your mount is balanced forward and the clutches and/or micro-steppers are slipping due to insufficient torque, that could be a reason.


Jamie Flinn
 

I did two runs of PA last night reducing error each time and am no very very aligned, Yet I still see the same thing:  DEC is quiet, RA is constantly having to guide out motion in RA - I also took a chance that my steps per revolution were the problem as I am including the decimal portion and inducing a drift, so removed that with no luck
So I am back to the sidereal frequency.
I need a qualified answer about the Frequency + and Frequency - buttons and which maps to EAST and WEST - I am positive I need to reduce rate but not clear which choice will stop me moving too fast to the WEST

Thanks in advance to anyone that can confirm...


Howard Dutton
 

On Mon, Jul 26, 2021 at 05:29 AM, Jamie Flinn wrote:
I need a qualified answer about the Frequency + and Frequency - buttons and which maps to EAST and WEST - I am positive I need to reduce rate but not clear which choice will stop me moving too fast to the WEST
+ results in an increase in frequency (across the board: sidereal clock and axis motion,) so the mount RA axis will tend to move faster to the West.


Jamie Flinn
 

Thanks Howard


Jamie Flinn
 

Howard - final question ;-).....in the android app in tracking page when you press the frequency buttons either + or -  should I expect the listed frequency for sidereal to change or is that hard coded text of what the default would be? (it does not change).... I can press the buttons but get no indication it is accepted or stored - perhaps there is :xxx# type command I can use to see what is current via console?

Thanks in advance as I need to track what is set over multiple tests to confirm which is operating best


Howard Dutton
 

On Mon, Jul 26, 2021 at 06:42 AM, Jamie Flinn wrote:
Howard - final question ;-).....in the android app in tracking page when you press the frequency buttons either + or -  should I expect the listed frequency for sidereal to change or is that hard coded text of what the default would be? (it does not change).... I can press the buttons but get no indication it is accepted or stored - perhaps there is :xxx# type command I can use to see what is current via console?
It's static text describing the +/- 0.02 Hz change, there is no feedback, but you can reset to zero again w/ [Reset Base Rate].

The Hz in question are the LX200 standard "60Hz" gives 15 arc-seconds per second.  So one press changes the rate by 0.005 arc-seconds/second (+ or -.)


Jamie Flinn
 

Great info - just what I need...thx


Howard Dutton
 

Now that I've answered the question I'd like to point out that this doesn't normally need adjusting in OnStep and most likely the error is elsewhere.

Polar alignment. refraction, things bending, etc.

The error in question here is on the order of 0.3% and typical crystal oscillator accuracy is orders of magnitude better than that, though some MCU's have ceramic resonators and they would put you in that ball-park.  If that's the case the solution is to add PPS to correct it continuously IMHO.


Jamie Flinn
 

Ok....so this is MKS Gen-L v2.1 and should have good timing.   I am only looking at guide tools here (PHD2 and Indi) both show and  report a definite drift in RA west only, despite being polar aligned (double checked) with no dec drift.   It is odd and steady - I can watch the guide star creep west, enough that it need correcting almost every or every other image (testing at 1.5 second shots)....average RMS end up being RA->0.9...Dec->0.5 but in the drift plots it is very clear west->guide east-> repeat....I only need to slow this down and it will match dec with all the seeing induced motion.
Phd2 Guide Assistant was clocking the RA drift at around 10 arc-sec/min - I need to re-evaluate tonight under better conditions but 100% it is motion and not sag (it does not change by sky position - sag would send me the opposite direction when I aim west for instance)

I'll report back  - tonight's test is refractions compensation on vs off 
I Guess the best spot is galactic equator and near meridian for best undistorted numbers (dec and ra should have similar motions there)

Cheers


bjaffa Jaffa
 

Howard,

I have an EthernetAddon PCB with encoders (311,296) that is setup in the pointing model only. I am using it to validate the gearing on my Losmandy G11.
My hardware configuration is specified below. I am getting a error that I believe is mechanical, that might mimic RA drift. I don't believe it is the sidereal clock. 
But a slight error in the gear ratio; causing the AXIS1/RA to run slightly faster mechanically than the sidereal/Sky_P expects  and OnStep stepper rate.
I just wanted to get your thoughts, it could also be accumulated  encoder errors but I wanted to run what I was seeing past you.

So I am running this is the daylight, not using Phd2, optical instruments.  The smoke is so bad here in the West US, I am not sure when I will have
a good night to test. So I do a 2 star alignment (assuming I am centered on the star); sync my encoders and run approximately an hour with the default tracking 
rate in Sky_P. I then monitor the EthernetAddOn GUI.

So with the tracking rate 160.440 step rate / Ax1;
Start of test: OnStep: Ax1=   +117*02:43
                     Encoder: Ax1= +117*02:37
After 1 hour: OnStep: Ax1=   +132*20:24
                     Encoder: Ax1= +132*27:54
So the encoder has advance +000*07:30  over the OnStep value

If I decrease the tracking rate to 160.279 step rate / Ax1 in SkyP 
Start of test: OnStep: Ax1=   +133*28:43
                     Encoder: Ax1= +133*28:33
After 1 hour: OnStep: Ax1=   +148*47:35
                     Encoder: Ax1= +148*49:40
So the encoder has advance approximately +000*02:00  over the OnStep value

So slowing down the sidereal tracking rated reduced the error. Which would seem to me that the
3 to 1 gear ratio is fractionally over 3.

So Howard does this make sense or am I off base? And can the 
 AXIS1_STEPS_PER_DEGREEE 38400.00000 be slightly reduced to match the sidereal tracking rate.
I know that Phd2 is suppose to correct but my guiding is between 1.5 to 2"  and if I corrected the gear ratio 
I could improve guiding.

Thanks   Brent


Hardware/Software setup:

SkyPlanetarium v4.58   USB  directly connected to OnStep  (On-CueOn-Step2.0.4)

to monitor tracking  (initially: Tracking 160.440 step rate / Ax1 from SkyP)

MaxPCB with OnStep  v3.16q using  Teensy 3.6 (180Mhz)  

G11 mount implementation: Stepper steps: 400; microsteps: 32; GR1: 3 (Gear reduction 3 to 1);

GR2: 360 (G11);    So   config.h ->  AXIS1_STEPS_PER_DEGREEE 38400.00000

Stepper Drivers TMC5160
EthernetAddOn PCB  firmware: V2.2e  (Teensy 4.0) with AstroDevices 311,296 encoder.

 

(config:  AXIS_ENC_TICKS_DEG   864.711111)




Mike Ahner
 

On Mon, Jul 26, 2021 at 02:47 PM, bjaffa Jaffa wrote:
So slowing down the sidereal tracking rated reduced the error. Which would seem to me that the
3 to 1 gear ratio is fractionally over 3.
It seems there is something about your mechanical system that makes the ratio off slightly. Last year, a user was using a different belts style that didn't match the pulley tooth pattern and as a result, his system ran about 1.15 times to fast.

You can calculate the percentage gear ratio change you need and simply put that into the spreadsheet as GR1: 3.xxx  OnStep handles fractions no problem. Or better would be to find the source of the error.


Howard Dutton
 

On Mon, Jul 26, 2021 at 12:47 PM, bjaffa Jaffa wrote:
I am getting a error that I believe is mechanical, that might mimic RA drift. I don't believe it is the sidereal clock.
It's really impossible for me to say where the difference comes from but if you would like a second opinion about OnStep's tracking rate the UT clock shown in the ASCOM driver is a good way... if it doesn't run slow by about 30 seconds (30*15 = 7.5 arc-minutes) per hour the issue is VERY likely not OnStep.


Jamie Flinn
 

Report - attempted using refraction compensation and got exactly the same behavior - so now moving on to the calculations of steps per degree:
Was using GR1= 3.916667 which in the spread sheet produces 12533.33440 Steps per Rev
attempting GR1= 3.916 which produces 12531.2 Steps per rev
Hoping to see an actual difference....I may jump the numbers around to see how much motion I can induce then narrow in on the best  - I should imagine it is all close but as referenced in this thread a different belt  can = 1.15 x fast - and I am on rowan belts - so never know that spur gear 47/12 ratio may be ever so different when a belt is in play...enough when you look casually it is stead, but when you look very closely it is drifting (fast)


Khalid Baheyeldin
 

On Tue, Jul 27, 2021 at 03:34 PM, Jamie Flinn wrote:
I should imagine it is all close but as referenced in this thread a different belt  can = 1.15 x fast - and I am on rowan belts - so never know that spur gear 47/12 ratio may be ever so different when a belt is in play...enough when you look casually it is stead, but when you look very closely it is drifting (fast)
That old thread uncovered a mismatch between the pulley type and the belt type.

One side was MXL and the other side was GT2, and the belt was one or the other.
Which means that the belt's teeth did not match one pulley's teeth, and the result was what was mentioned: a speed mismatch.

If you are using an off the shelf Rowan belt kit, with the pulleys that came with it, this should not be this same problem.

You can also count the teeth on the pulleys, and make sure that the belt's teeth fall in the pulleys grooves with no mismatch between the pulleys, say down side, and top side (so ~ 180 degrees).


Jamie Flinn
 

I may have found the culprit - testing last night with the reduced steps per axis setting s did appear to make things closer, I also PA'd to within an inch of my life and had better results but something was still not right - amazing HF motion numbers but still some horrid drift.....so walked out to the observatory this morning "perhaps my mesh is not good"
I find that the 4 bolts holding the DEC/worm housing had worked themselves loose (very) so every single motion in any axis would result in unexpected movement...'thunk...thunk...thunk..."  I suspect this is also whay I saw RA spike on DEC guide movement!   Now all is secure and I will be retesting tonight if clear (and have ordered locktight extra strength!!!)




Jamie Flinn
 

SOLVED - using the ever so slightly reduced steps per rotation + a couple of presses of Frequency + and finding that the bloody bolts onthe dec housing had worked themselves very loose AND adding some backlash compensation in OnStep
  - I now have proper results Thanks ALL for tips and thoughts and input
  


bjaffa Jaffa
 

Jamie,   So when you mentioned you "slightly reduced steps per rotation" ; were you talking about  OnSteps  config.h ->  AXIS1_STEPS_PER_DEGREE.
What is you  config.h ->  AXIS1_STEPS_PER_DEGREE calculation?

Thanks  Brent


Jamie Flinn
 

yup: 
3.916667 _> 3.916....it dropped my stepsperdegree  just a smidge - it seems to have an effect - that number 3.91667 coms form a 48/12 spur gear - now I am using belt and I suspect that the tooth angle/pitch in spur gear actually has an impact that is not there with the belt (sure it has 48 teeth but not the same angles - My RA drift was enough that it needed to be reacted to which when guiding can cascade to other problems every time you must move, so trying to reduce the NEED for guide motions and it does seem to help - my gotos and platesolving are all still great...I am sure I will be tweaking further


Howard Dutton
 
Edited

On Fri, Jul 30, 2021 at 06:45 AM, Jamie Flinn wrote:
3.916667 _> 3.916....it dropped my stepsperdegree  just a smidge - it seems to have an effect - that number 3.91667 coms form a 48/12 spur gear - now I am using belt and I suspect that the tooth angle/pitch in spur gear actually has an impact that is not there with the belt (sure it has 48 teeth but not the same angles - My RA drift was enough that it needed to be reacted to which when guiding can cascade to other problems every time you must move, so trying to reduce the NEED for guide motions and it does seem to help - my gotos and platesolving are all still great...I am sure I will be tweaking further
Spur gear or timing belt.  It is a fact that the tooth counts determine the overall ratio right up to the point that the mesh of teeth/belt fails (belt rides up on top of the teeth for example.)  Sure there can be an (usually insignificantly small) higher/lower ratio with tooth form and whatever imperfections at play but it will average out to the exact ratio.

Since 48/12 = 4 that spur gear pair's average ratio is exactly 4:1 not 3.91667:1, or anything else.