Lego rotation sensor is a nice little device that enables RCX to measure rotation of an axle with good resolution: 16 steps per turn. Unfortunately it is plagued with a problem: at low rotation speed value read seems to jump randomly from 1 or two units. So I decided to have a fairly indiscrete look at it... here is what I discovered.
Active sensor working
A 10K ohm resistor inside RCX pulls up sensor output to +5V, sensor has to absorb current to drop voltage to desired value.
These values seem a bit low when compared to Michael Gasperi's (see his rotation sensor page), perhaps my batteries were exhausted. You can also see that there is some jitter in read phase duration (between 90µs and 125µs)
As pointed out by here by Jürgen Stuber, we have here the first problem of rotation sensor: during transition between step 3 and 4, output crosses voltage of level 2, and between step 1 and 2, output crosses voltage of level 4. Since this transition takes some time, there is a probability that it happens just when RCX samples value. I tried to determine sampling time, it seems to take place about 60µs after beginning of read phase.
Dick Swan made an experiment showing that step
1 is longer than the three others. See here
his measurements and an explanation.
Some alternative RCX programming languages (legOS and leJOS) perform two consecutive readings and almost eliminate this problem at the cost of halving maximum rotation speed.
But the mechanism of this problem is independent
of rotation speed. So why are worse at very low rotation speed
? Read on...
It seems that very close to transition position, there is synchronisation with power/read cycle, and this increases the previous problem: there is a lot of transitions instead of only one - and when rotating very slowly this transition is doomed to occur at sampling point and cause misread. Note that even double sampling as performed by legOS and leJOS has no guarantee to give correct answer: if rotation is very slow two successive reads will happen during transition...
Opening the sensor
If someone finds a more elegant method to open this shell please let me know!
(Photo courtesy of Andreas Peter)
Circuit board schematics and analysis
D1, D2 rectify power supply, C1 filters it. K1 and K2 are two opto-forks (marked S89, I didn't found exact part type), one side contains an infra-red led, the other side a phototransistor. Blade of propellar shape part can interrupt infrared beam of K1, K2, both or none, providing the four phases of the returned value. Since there are 4 blades, we obtain 16 steps per turn. IR leds receive power through R1 (about 5mA). The node between R1 and K1 led is maintained at a 2.2V constant voltage (drop across 2 IR leds. Output of phototransistors are amplified by high gain Darlingtons (Q1, Q2) and (Q3, Q4). Their output drives the base of Q5/Q6, whose base is polarized to the previous 2.2V reference through R4 and R5. Through D3, Q5 and Q6 absorb current provided by 10K ohm resistor inside RCX, and generate the 4 levels:
May 2006 update: Ian Davis spotted a mistake on my schematics, a missing link between emitter of Q5/Q6 and base of Q1/Q4. This link seems to provide some feedback and helps getting the correct output voltages.
Since problem is caused by synchronisation between supply and amplifier threshold, I tried to increase power supply filtering. I added a tantalum 22µF 10V capacitor in parallel with C1 and tried my modified sensor... Yippee! it now works perfectly even with looooow speed rotation, no more erratics counts, no more signal synchronisation seen on my oscilloscope.
Modified sensor photos
Dan Walkowski sent me photos of a rotation sensor with different construction (older model ?). These images show how he applied the fix.