optical encoder wheel and detector source

[Poita (Peter)]

Thanks for the detailed response, I understand it all a lot better now.

I've downloaded PEMPRO and graphed the PE etc. of my existing mount and have a far better understanding of how it all hangs together.

What is really impressive to me was how much better it all got by recording the PE and then having PEMPRO load the corrections back into the mount. If you did that in addition to guiding it seems to give a pretty tidy solution.

[rcheshire (Rowland)]

This is a good read. Outside my technical knowledge but interesting. alistairsam you mention using a picaxe microcontroller for goto. Was this in preference to the arduino. My skills are pretty basic, so wondering what the advantages are. I'm resisting hacking into my GEM and automating things, encoders and such, but it's tempting.

[alistairsam]

Originally Posted by rcheshire

This is a good read. Outside my technical knowledge but interesting. alistairsam you mention using a picaxe microcontroller for goto. Was this in preference to the arduino. My skills are pretty basic, so wondering what the advantages are. I'm resisting hacking into my GEM and automating things, encoders and such, but it's tempting.

Hi,

just to state the obvious, I'd advise against hacking into your mount unless required and unless you're confident of the mod, but yes, the picaxe's are incredibly easy to use and program. they're targeted toward school students starting off with microcontrollers, yet they've become very versatile and powerful withe latest generation M2 chips.
eg. they support machester encoding for rf transmission straight out with a simple command, rfout!. so you have rfin at the receiver and the picaxes handle CRC, manchester encoding and so on. same with IR.
several features like 8 way multitasking etc. so love it, the forum has some really knowledgeable guys as well.
I had a look at the arduino, but wasnt too comfortable with the language, picaxe was easy for me as it uses normal basic with some minor variations.

I'm working on the lx200 protocol interpreter for autoguiding, so should have it done soon. just fiddling around trying to decide on a decent guiding cam/scope setup. might get the bintel mini guidescope package.
am tempted with the skywatcher synguider.

[alistairsam]

Originally Posted by bojan

Shaft end I meant.. because average camera scale will be close to 1 arcsec/pixel (1m FL, 5um pixel).

I am aware of those closed-loop systems, but they must be extremely expensive (encoder must be free of PE and backlash, which is not possible to achieve (at reasonable price) with up-gearing)- so I don't think they will ever be available for average user.
And what's the point? Guiding works well (not my own experience yet, though).

Bojan, still a bit unclear. you mentioned 1arc sec at RA shaft end. so what would the resolution of encoder be for 1arc second?
wouldnt it be 86400 for RA (in time increments) and 1,296,000 in Dec for 1 arc sec?
i read somewhere that the losmandy mounts have a resolution of 1/2 arc sec based on the encoders on motor shaft and subsequent gear reduction which is quite high as they use servo motors in a closed loop.

[bojan]

Originally Posted by alistairsam

i read somewhere that the losmandy mounts have a resolution of 1/2 arc sec based on the encoders on motor shaft and subsequent gear reduction which is quite high as they use servo motors in a closed loop.

This is roughly what the resolution for accurate tracking should be - at the RA shaft.

However, because of subsequent reduction (and PE introduced by it) this final resolution is pretty meaningless, because you still have PE introduced by subsequent reduction and this could be much larger (5-10arcsec for very good mounts) and unless it is not compensated in the software, you can't use it for long time exposures with long FL lenses, where you need sub-arcsec tracking accuracy.

Again, don't confuse time increments with angle, expressed in arcsec.
I mentioned earlier:

... it is 3arcmin on both axes. The difference you are mentioning for RA is because for RA unit we use time (meaning, it takes 12 sec of time for the sky to rotate by 3arcmin in angle units)

So, the sky rotates for 15arcsec (angle, at celestial equatror) for 1 sec (in time).
The resolution of encoder needs to be at least 1arcsec (Angle, based on 1m FL, 5.7um pixel size), and that is 1296000 ticks at RA shaft.
The same goes for accuracy - if you have the above resolution, but overall PE introduced by subsequent reductor is +-10arcsec, you will see this on your photo as elongated star image, spread over ~10 pixels in E-W direction.

That is why I think that for good closed loop system you need the encoder with such accuracy and resolution (1 arcsec or better, directly on the RA shaft - and this is very expensive encoder).
Or, you can have encoder on the motor shaft, but the subsequent PE must be compensated somehow.. and the most efficient way is auto guiding.

[alistairsam]

Hi,

I understand the difference between angular units and the time based equatorial units. just stated that for context.

Originally Posted by bojan

That is why I think that for good closed loop system you need the encoder with such accuracy and resolution (1 arcsec or better, directly on the RA shaft - and this is very expensive encoder).
Or, you can have encoder on the motor shaft, but the subsequent PE must be compensated somehow.. and the most efficient way is auto guiding.

Is this even possible? I'm guessing these are not optical.

I have three gear reduction stages, two of which are timing pulleys and one which is a mclennan spur gearhead.
I might drive the encoder from the input of the final stage instead of the RA shaft as the backlash with the timing belt/pulley would be minimal when tensioned correctly.

[bojan]

Originally Posted by alistairsam

Is this even possible? I'm guessing these are not optical.

I think encoders like this are possible but VERY expensive, and therefore not practical solution.
Or, you may have linear (well, bent) encoder mounted on the rim of a large wheel - then something like capacitive encoder (used in calipers) may be good enough.

Originally Posted by alistairsam

I might drive the encoder from the input of the final stage instead of the RA shaft as the backlash with the timing belt/pulley would be minimal when tensioned correctly.

You will still have some PE (because the timing pulleys are not perfectly centred).

This solution is applicable for DC motor servo loop, of course.
If you have steppers, you don't really need encoders on motor shaft (unless your motors tent to stall or skip steps).
You need them to be coupled to RA shaft instead, to have functionality similar/equivalent to argo navis, for example.

[bojan]

BTW, this is how I intend to mount&couple encoders inside my EQ6 (I am using Bartel's system) to have Push-To (already functioning on my dob).. but I don't intend to try to push the encoder resolution to extreme - 3 arcmin will be more than enough for my needs.
The tracking accuracy I intend to sort out with guiding (if I ever needed this - photometry and spectroscopy is more forgiving for PE errors

[pentek123456 (Pentek)]

"alistairsam". I salvaged the same printer to get the encoder. Can you be so kind as to upload the arduino code too. I would appreciate it.

[pentek123456 (Pentek)]

"alistairsam". I have the same encoder. Can you be so kind as to upload the arduino code too. I would appreciate it.

[alistairsam]

Originally Posted by pentek123456

"alistairsam". I have the same encoder. Can you be so kind as to upload the arduino code too. I would appreciate it.

Hi
Which code were you referring to? Btw I use picaxe not arduino.

I have tested a limited lx200 translation routine with the picaxe as well as pulse guiding, so the picaxe emulates an lx200 and sends responses back to the Ascom driver also changes the stepper speed for guide corrections.

Other project I had was a handheld dsc, haven't completed it though. The dec axis was a bit complicated with the negative values, but still workable.
Final bit will be integrating the two so it can use the encoder feedback to control the steppers for goto commands from any software using Ascom.