Initiating your telescope from encoders
#######################################
#######################################

For getting correct values also for AZ/ALTHALFSTEPSIZE, etc. you can
do following.

*
*
For the very first time, startup the software, move some steps to right,
and some upwards, till your axes really starts to move.
Instead this you can also move your sprockets to the correct direction by hand.
This should be done for beeing sure, that motors are not in a blind hole, which
is normally given by not 100 percent correct gear-drives. This blind hole, is
a problem for us in every case, and takes effects every time the direction is
changed.
This is, beneath the loosing of steps by frictional-drives,
also a reason, why it make sense to using a little correctionsystem
with encoders. 
*
*
*
Then set on your encoders by setting your correct interface (SERIALENCODER,
PARALLELENCODER,JOYSTICKENCODER).
*
Set the tolerances to 0.0, and
ENCODERAZSIGNALS360,ENCODERALTSIGNALS90 to a higher value, then the real
value.
*
The values for AZ/ALTHALFSTEPSIZE set to a lower value then the real values. 
*
Set DEBUG to ON.
This effects also that the comparion between encodersignals, and halfsteps is off,
at startup. Do not set this to on during running software for this test.
*
Set CALCREFRACTION to OFF, or comment it out, or later start your software with
commandline parameter -rf.
*
Mark the current positions of Motors for the az/alt-axes.
*
Then startup the software. Normally after startup the scope moves some steps to
the right, and some upwards. Skip this by starting the software with the command-
line parameter -skip, or uncomment the config-param SKIPSTARTUPMOTOR=ON.
*
Then move as correct as possible 360 degrees to the right ( FAST correction right ).
(Till your marked position is exactly reached again ).
The same do with fast upwards for 90 degrees with your alt-axis.
*
Then end the software ( use F10 for eltel-monitor ).
*
After this you should get a little list with up to 20 encodervalues, reflecting
the number of halfsteps per signalchanges, and the average of the 20 signals.
Also you get a suggestion for setting ENCODERAZSIGNALS360,ENCODERALTSIGNALS90, and
the tolerances.
But do not use this for this first test, because your HALFSTEPSIZES
are not correct at time.
*
Instead get the values at end of list, reflecting the numbers of pulses. In current
case this are the numbers of signalchanges for a complete turn of 360 degree, and
for 90 degree altitude.
This now you can use for ENCODERAZSIGNALS360, and ENCODERALTSIGNALS90.
*
Additionally you get the first numbers of the really done halfsteps of your az, and
alt axes, for 360/90 degrees.
But be warned. These are the steps done by motors. If you have loose steps during
this turn, by your frictional drive, these values are greater then the really useable.
But for this we do some additional test.
Currently you can do following:
*
Set ENCODERAZSIGNALS360, and ENCODERALTSIGNALS90  to the value read by
"Current state of signalcount az: ??, alt ??"
Then get the values read by "Current state of halfsteps az: ??, alt: ??".
Divide 1296000 with the az  value, and set AZHALFSTEPSIZE  to the result.
Divide  324000 with the alt value, and set ALTHALFSTEPSIZE to the result.
*
*
Now you have some nearly useable values for moving your telescope.
But the goto, guiding, .. and so on is only correct as these settings are correct.
For this reason, repeat this test as often as you have time, ( with
no calc of refraction, and skipped startup-motorturn,
- but now with encoder-comparison ON. You can switch on comparison directly after
startup of software with option "Encoder on/off".
*
After every ending of software you can compare the values. Especially you should
have a look for the numbers of halfsteps per encoder-signalchange. Also
compare the results for ENCODERAZSIGNALS360/ENCODERALTSIGNALS90 given by calculation
of the average of halfsteps per signalchange, and the result of a complete turn
of 360/90 degrees.
If the values for halfsteps per signalchange not equal, perhaps you have to experiment
with ENCODERAZTOLERANCE, ENCODERALTTOLERANCE.
*
If you are nearly sure, that you have useable values, make this test using also
directionchange.
For azimuth-drive this means turn 360 degrees to the right, and turn completely back.
For altitude-drive turn 90 degrees upwards, and the go back downwards to 0 degree.
Show the results. Normally you should have a value nearly 0. If it is exactly 0,
you are a lucky fellow.
Normally you have to accept a little number of arcseconds difference.
Also it is not easy to hit the positions exactly, using marked positions by a ball pen.
Unfortunately, there is no absolutely hundred-percent method, to mark positions exactly
precise.
You have to use your imagination, to find your own methods.
For the az-axis its a good choice to point an earth object with the largest magnification
you can do with your scope, make a 360 degree turn till the object is visible again in
middle of your tubus. ( Also after a complete left turn ).
For the alt-axis its a real problem. You can try with water levels, showing the horizontal,
and vertical position.
*
*
You have not to turn completely 360, or 90 degrees for all times.
With the DEBUG Option, using the monitor from eltel, you have always a look for your
current position ( in number of halfsteps ). If you can handle your pocket-calculator,
you have this additionally way to show the effects of movings, directionchanges etc ... 

A little tip for moving your alt-drive.
Because eltel does not accept negative altitude
positions, and the mostly sensefull setting for ALTHORIZONTLIMIT is 0.0, but for testing
sometimes it makes sense to move under this point.
Set ALTZENITLIMIT to a value greater then 90 ( this makes also sense for real using ).
Before starting software position your alt-axis ( with a water-level ) a couple of degrees
under 0, and then after starting software move it upwards, till the water level shows
the horizontal position, and then write down current read position ( halfsteps ) from
monitor. For further calculations you have to sustract this value.
With this you can avoid that motor stops, in case values are not correct, and
results after moving back downwards goes under 0 degree.
This method is less neve-racking than doing all again, because motor stops on 0
position.


Note
####

Please, do not expect, that you reache hundred percent correct results.
Using own practical experiences differences of 20 - 100 halfsteps after a complete
right turn of 360 degrees, and completely back left provides you a useable real handling
of your scope. If your are under 50 halfsteps - its very good.
Don't forget the normally blind-holes when direction changes. Have a look for,
that a pulserate of 4000 of an encoder, and a halfstepsize nearly one arcsecond,
means that a number of more/less then 320 halfsteps can be done within previous,
and next reported change of encodersignals.
eltel tries to hold last correct position as long as possible, but if the complete
range of halfsteps per signalchange overruns with a bad comparison, it can only
brutally set the position new with current encoder-position.
If the loosing of steps by frictional drives is in a acceptable range, this should
be no problem, and correct in a proper way.
But the blind flying between two encoder-signalchanges with change of direction
is a problem in every case. If this range less than the number of halfsteps per
signalchange, the problem should nerve you only in an acceptable range,
because eltel uses the last correct position also for this. 
But the only way to avoid this completely, is to use hundred-percent precise gear-drives, but
this is normally very expensive, or you are a very good self-made mechanic with
an own lathe.

Also the correction is precise as small the range of halfsteps per signalchange.
Means, if you have a signalchange per halfstep, you are absolutely correct, but
this means over 1.000.000 signalchanges per 360 degrees.
There are a lot of reasons, not to try to build such encoders.
For eltel we do not have the problem, that the numbers of pulses can be too high,
because eltel does not handle the switch between moving by motors, and moving
by hand. Eltel awaits the moving only by motors, and every step effects the
reading of encodersignals, if encoeders are used.
But there is no hardware for handling such a lot of pulses per second, using
segmentdiscs, and opto-/reflexcouplers.
Also you will have problems to build a prober transmission ratio for such an
encoder :-)
As higher the transmission rate, as higher is the problem producing blind-holes
when direction is changed. So you can produce the same problems with your encoders,
you have with your motors.

-------------------------------------------------------------------------------


The using of encoders together with eltel makes only sense, if you
have following problems:

You are loosing steps during moving. ( Mostly happens when using frictional drives).

If direction is changed, motors are running, but it takes a little while till
scope is also moving. In this case you have a not hundred-percent correctly
gear-drives ( which is quit normal ), or another idling transition.
We name this "blind hole, when direction is changed".


If using encoders, a pulserate of 4000 per 360 degrees, for this,
is a practical compromise.
This makes it possible, to compensate the loosing of steps by frictional drives,
and to correct the position after a change of direction to a furthermore useable
position. 

This pulserate also provides the possibility to produce self-made encoders,
with commercial available segmentdiscs ( 120 segments ), two reflex-couplers,
( The combination of these parts, is named encoder by electronicals ).
and a additional transmission rate of 1:5, which can be realized with
the using of only two gearwheels, or a belt conveying, using two wheels.
The using of these parts, provides the self-producing of encoders,which
are precise enough, and without producing encoder-sided "blind holes".
 
The number of loosed steps, should be not greater then one step per two changes
of encodersignals. ( Calculate the average of loosed steps per 360 degrees ).

Generelly, if you have more then one loosed steps per 360 arcseconds ( which makes
one degrees you are loosing during a complete turn ), you should look for
reassembling your drive, because with this you cannot make any useable
Astrophoto :-).

An Exception is the loosing of steps when passing a special, incorrect point of
your mount, which perhaps stops the moving, and frictional sprocket slides.
This point you better repair :-)


eltel provides the possibility to origin the current position to a special
object. If you use encoders, use this option as often you can, if you notice
that after a couple of movings, precision is lost. This resets beneath current
position, also the position of encoders.


Have a look for, that the using of encoders does not remove your problems
completely.
Instead it can reduce it to state where you can live with.

-------------------------------------------------------------------------------