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.
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.
Last edited by alistairsam; 18-04-2011 at 02:54 PM.
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.
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
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
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
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
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.
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/De...33D66A25949059
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.
this disk is the 1800line or 7200 ppr (quadrature) disk.
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...
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...
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
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)
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.
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?
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?
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.
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.
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.
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?
when you say less than 1 arcsec resolution is needed, did you mean when measured at the motor end or the output shaft end
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).
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
Quote:
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).
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).
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.
