Re: Tracking quality test report
- Gday Andrew,
many thanks for your detailed (but not simple for me) explanation of the processes involved. I'll try to study it better.
In the meantime I'll do the tries with DEC percentage.
One note related to the slews I have used for my tests: they are not optained by Goto to absolute coordinates but, as I have said, by the Maxim/Guide/Move tool that I think performs as autoguider slews of predefind time lenght. So, when I said 150 arcsecs, I meant 10 second o time asked by the Guider/Move tool.
--- In LX200GPS@yahoogroups.com, "johansea" <johansea@...> wrote:
> Gday Emiliano
> --- In LX200GPS@yahoogroups.com, "EmilianoP" <eggpap@> wrote:
> > If I have correctly understood, are you saying that the scope
> >(for the searching slews or the autoguider corrections?),
> > in my case, applies part of the backlash at 1.5x
> > (tracking rate + 0.5x), then reverts to the tracking rate
> > (normally 1x) to accomplish the complete slew required?
> Yes and no.
> Lets leave "goto" slews out of it at present ( for clarity ),
> and we will also leave out AltAz, ( as that is more complex ).
> Autoguider requests get handled at the current guide rate
> ie in polar ( with a guide rate of 66% )
> commands in RA get sent to the motors as 15arcsec/sec +/-10
> commands in DEC get sent as 0 +/-10
> In RA, this means we never reverse the motors, hence we never see the effects of geartrain lash.
> DEC commands can result in motor reversals, and this is where the problem comes in.
> > But what part of the backlash?
> > It happens randomly in different percentage?
> Its not random ( but it can appear that way )
> > Suppose I ask a DEC slew of 150 arcsecs and the scope
> > applies the 50% of a backlash of 45 arcsecs,
> > so one half of the backlash is not applied and finally
> > I get a slew error of 22.5 arcsecs, is it right?
> When you do a "slew" to absolute coordinates,
> backlash is essentially ignored as the scope has a
> target point to go to, and it will just go there.
> The problems comes in when you request small "timed guides"
> Lets assume some simple numbers
> DEC drive train is 100arcsec,
> DEC percentage is 50
> On reversing direction, this means apply 50arcsec "instantly"
> Lets assume our DEC is preloaded from a previous North move
> and we send :Mgs1000#, ie guide south for 1 second
> One second of guiding should moves us 10arcsec
> Now on receiving the command the scope knows to apply 50arcsec rapidly, then do the guide command for 1 sec.
> Now comes an interesting timing exercise where the scopes interrupts process away and say "hey, the guide is over, stop the DEC motor"
> Stopping the DEC motor means the rest of the lash cant be blended in.
> Ie we have accounted for approx 60 arcsec only.????? ( not 110 )
> The scope still knows where it is ( ie it doesnt lose any info re position etc, it just doesnt process the reversal fully )
> Now if you issue several more :Mgs1000# in a row, it will stabilise once the full amount is taken up, but it is very woofy in how it works.
> Now lets apply the percentage factor
> If you do the above exercise with % = 0.
> On reversing, it does nothing fast, hence it will take much longer to fully reverse and become stable.
> If you do the exercise with % = 100, then in theory, the full lash is applied in one hit, but in the real world this results in a kick as the motors inertia cause an overrun.
> > > To test this out, set your DEC percentage to 0%
> > What's the meaning of DEC percentage?
> As per above, there is a percentage for each axis to define how to apply the fast portion of the drive train.
> Just play with the DEC value, and see how it affects your guider calibration tests. Keep upping the percentage till DEC reverses quickly without kicking.
> Andrew Johansen Melbourne Australia
- Gday Emiliano
--- In LX200GPS@yahoogroups.com, "EmilianoP" <eggpap@...> wrote:
> One note related to the slews I have used for my tests:
> they are not optained by Goto to absolute coordinates but,
> as I have said, by the Maxim/Guide/Move tool
If it is using ASCOM "nudge" functions, then it is actually doing a goto in the background. ( This is the subject of another bug )
To check this, you need to use a portsniffer ( like PORTMON )
to see what commands are actually being sent.
> So, when I said 150 arcsecs, I meant 10 second o time
> asked by the Guider/Move tool.
Actually, 150 arcsec would be 15 time seconds, as guide rate is 66% of 15arcsec/sec, ie 10arcsecs/sec.
Note. If the move done is greater than your dribe train, then you will still see the effects of the bug, but only on the first reversal.
Andrew Johansen Melbourne Australia