optical encoder wheel and detector source

[alistairsam]

Hi,

I've been trying to build a hi resolution encoder for a while now with mouse parts, up gearing and so on, but i just came across an easy source of high density encoder wheel and detector - a deskjet printer.
I opened up a HP deskjet printer - 712, and it had a 3" encoder wheel and detector on the shaft connected to the paper rollers.
I got this printer second hand for $5.
plenty of second hand ones around on ebay, gumtree.
you'll need a T10 and T9 torque screwdriver to open it up.



the detector had Q9863 printed on it which is a HP part number, and after a bit of searching found the pinout.

1. gnd
2. channel A
3. +5v
4. Channel B

I hooked it up to an oscilloscope and found it generates TTL level sine waves.
since i needed pulses for my microcontroller, i just connected the channels to a quad schmitt trigger CD4093, then inverted it with the next nand gate on the same chip (tie two inputs to form a NOT gate), and lo and behold, square pulses.
works beautifully. now i am not sure if this detector signals vary in amplitude for slow rotation, but from tests, even very slight movements generated square pulses. so amplitude was sufficient for the schmitt trigger to output pulses.

I don't know the details of the detector but you can see it emit a faint red glow. so its not IR.

and you get true quadrature output with each channel 90 deg apart.
the codewheel has 200LPI printed on it, but i havent counted the number of lines as yet. will do so shortly.
but even if it is say 1500 lines per 360 deg rev, using quadrature, that would be 6000 ppr. and if you gear even as low as 1:2, you'd get 12000 ppr.


whats even better is there is one more detector on the print carriage head thats linear. i'm not sure if it would work well as rotary, but worth a try.

Now to print my own codewheels, i bought this transparency film from officeworks for $19, http://www.officeworks.com.au/retail/products/Technology/Monitors-and-Projectors/Projector-Globes-and-Accessories/ACPP100C20 and used this software to print my own wheel on my work photocopier/printer machine.
http://www.mindspring.com/~tom2000/Delphi/Codewheel.html#Generating%20a%20Cod ewheel (http://www.mindspring.com/%7Etom2000/Delphi/Codewheel.html#Generating%20a%20Cod ewheel)

I was able to print a 1400 line codewheel with a diameter of 4 inches at 600 dpi.

So if you don't have access to an old deskjet, you can use the OHP paper above to print your own wheel and get much higher densities than a wheel from a ball mouse.

thought it might be useful for those who haven't built one yet.

[coldlegs]

Being able to print high resolution decoder wheels on a laser printer is a big step up for DIYers. Thanks for the link.
Stephen

[alistairsam]

a quick and dirty test of the codewheel and detector from the deskjet printer.
turns out that it can generate 7200 pulses per single revolution in quadrature, which should be sufficient to use for positioning without any gearing on a telescope's axis.

the quadrature decoder is using a picaxe microcontroller using finite state machine code.

http://www.youtube.com/watch?v=GdWUQ3rguUU

just need to build a housing assly with proper alignment of the detector and wheel.

[Astroman]

Excellent for DIY'ers, When I was experimenting around with Mel Bartels scope program I made a DSC using Dave EK's board and hacked an old ball mouse and made my own encoder wheels for it... Worked great, but the resolution wasn't all that good, most likely my rough way of making things... When testing i was good to see as you rotated the dial the numbers on the test program increase or decrease... I never got it onto a mount, but the idea was there, thanks for trip down memory lane... I think yours look way better than mine :)

[Shiraz]

Thanks for the tip. had been vaguely thinking about digital readout for a focuser and will now take it a bit more seriously. really interesting post. Regards Ray

[megafun]

hi,
I just ripped apart the very same printer as you a couple of days ago and was struggling to find data about this sensor. Your posts here have been very helpful, and i was wondering where you got your pinout information from, do you have a link to a datasheet?
thanks

[alistairsam]

Hi,

Glad to know it was useful, what are the odds that someone opened the same printer!!
anyways, i got the pinout from a google search, sorry didnt find the datasheet for these detectors, i found the datasheet for a similar honeywell sensor though. but that wasnt useful.

this is the site with the pinout for the q9864, thats the detector on the carriage head, so i expected the q9863 to be the same.
i verified the ground pin by tracing the -ve terminals of capacitors on the pcb and the detector with a multimeter. that was the easiest to find.

the pinout is toward the bottom.
https://groups.google.com/group/sci.electronics.components/browse_thread/thread/a8555b7e3eba7652?hl=en

did you get it working? let me know if you need the circuit diag with the 4093. pretty straightforward though.

[alistairsam]

for salvaging hi-res encoder wheels and detectors from deskjet printers, you can use this website to check if the particular printer has an encoder disk or not as not all of them have it.
just bought a deskjet 930C from an ad in gumtree for $5.
before buying, i had a look here,
http://h20141.www2.hp.com/HPPARTS/Default.aspx?mscssid=BBEE3B3AB28F4B 45A933D66A25949059

chose the model, click on the keyword search dropdown and choose encoder. that'll show that it has a paper motor encoder disk.
to see where it is, choose one of the print mechanism diagrams.
this disk is the 1800line or 7200 ppr (quadrature) disk.

the disk is just stuck on the gear with adhesive, you can pry it out as in the pic.
you can remove the detector with the pcb and solder wires to the detector pcb.

[bojan]

This is enough resolution for Push-To (3 arcmin)..
I have similar encoder resolution on my Bartelised dobson... very convenient when observing with people around (I can jump from one side of sky to another and Bartels tracking accuracy is kept without problems).

It would be interesting to mount it inside my EQ6...

[alistairsam]

Hi
Does the eq6 have encoders normally?

7200 ppr would be 3arc min in alt/az and dec but 12 arc secs in RA

these disks can be bought for $10 from a store in aus, just search for the part num but it's ideal to use the matched detector in the printer which I don't know if it's available

[bojan]

EQ6 doesn't have encoders.

Actually, 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)

[alistairsam]

a simple housing for the encoder wheel and detector using a smoke detector case I had lying around.
since I didn't have a proper steel shaft, I used a bolt and I used the metal shaft housing from a potentiometer to keep the bolt straight when rotating.

the detector is held by the single bolt and I'm using the nut to offset the detector from the housing base. allows me to adjust optimal placement of the detector around the encoder pattern.

The bolt end acts as the encoder shaft and you could use a shaft coupler or any mating method at the end to the telescope shaft.
since my RA shaft is 20mm, I'm using a wooden coupler.

[Poita]

I've used inkjet printer encoder wheels for projects in the past, they are a cheap source of great high resolution parts.

I am new to using them on mounts though.
I was wondering if it would be possible to add encoders to something like an EQ6 and utilise them to monitor and correct errors in tracking?

[bojan]

The encoders are not precise enough for this task (less than 1 arcsec resolution is needed - without any PE).. but they are OK for GoTo or Push-To (using Bartel's system, for example.. or David Ek's utility)
Tracking errors are dealt with by guiding.

[alistairsam]

Hi,

when you say less than 1 arcsec resolution is needed, did you mean when measured at the motor end or the output shaft end cause I think the highest resolution optical encoders would be around 100,000 ppr encoders and that would be the resolution if they were to be mounted on the RA shaft.

I believe losmandy mounts use servos with integral motor encoders which I think is a closed loop system, so with all the high gear reduction, the resolution does work out to less than an arc second. but that wouldn't detect variation at the final output stage? precise machining of the ra worm and wheel might be key to its low backlash or PE errors.

I've geared up these encoders with a 3:1 timing pulley so its around 21000 ppr on the RA shaft at the moment.
60arc seconds might be sufficient for most goto uses.

also working on a closed loop system for steppers using feedback from these encoders output to XOR gates.

[Poita]

Ah, okay. I thought I had read something about a closed loop system where encoders were used to pick up tracking errors with high end mounts when I was researching the upcoming eq8. I probably had is back-asswards as is often the case!

If it had to be one arcsecond, would that mean an encoder of 1,286,000?

[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).

[Poita]

I'm not sure of the point, I'm new to all this. I'm guessing there is not always a suitable guide-star, or that guiding doesn't solve all of the problems?
Does guiding get rid of concerns about PE and tracking errors in the mount?
Does a guided EQ6 work as well as a guided Titan if both are well inside their weight tolerances?
Those aren't rhetorical questions, I actually am confused about the whole mount issue :shrug:

[bojan]

Peter,
the problem with encoders on the motor shaft is because the only problem you are solving by this approach is eventual motor slippage (or missing steps if steppers are used) and you have the correct tracking rate and position at this point (motor shaft) in case of DC motors (closed loop takes care of this).
But, the rest of the gear reduction (or timing belt) and worm gear errors are not compensated for periodic errors and backlash. So, the closed loop with encoders on the motors will be OK for GoTo - but still not adequate for accurate tracking needed if long focus optical systems are used for imaging (for example, I found that +-30arcsec PE error is acceptable for 300mm lens, up to 30 sec exposure time - precise enough for what I do (photometry), so I don't use guiding yet).
Sure, there are precision-made worm gears (Byers for example, see here: http://www.cloudynights.com/item.php?item_id=2299) , but they are very expensive, and still not completely free from PE.
Also, you should not forget about atmospheric refraction, and not ideal mount polar alignment and flexures (people often tend to overload their mounts).
All the above can be adequately compensated for by guiding, for the fraction of the price to be paid for any other approach to this problem. Even the lack of suitable guiding stars in the area area can be offset by accepting somewhat larger field rotation as result of using stars away from target (better mount alignment, the smaller the field rotation will be).

[bojan]

Stumbled on this, very interesting capacitive encoder :
http://www.amtencoder.com/LinkClick.aspx?fileticket=Jat4EDtyV jw%3d&tabid=215

some more info on the issue is here:
http://www.amtencoder.com/portals/amt/documents/resources/technicalpresentations/AMT102_103_TechPres.pdf

The accuracy (don't confuse this with resolution) is a bit low (+-15arcmin - this is 0.5°, the size of the Moon on the sky) but with appropriate up-gearing, it may be significantly improved (for example, 4:1 timing belt pulley should deliver +-3.5arcmin - more than enough for GoTo applications.)
Because of low power consumption and relatively small size (low profile), it may be suitable for placing it inside EQ-6 mount.

It is available on ebay, see here: http://www.ebay.com.au/itm/AMT102-Incremental-Encoder-CNC-Servos-/330602090182?pt=AU_B_I_Electrical_T est_Equipment&hash=item4cf96b8ec6

[Poita]

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]

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]

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]

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]

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:
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.



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]

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.



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]

"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]

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

[alistairsam]

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.