Some years back, a museum asked me to help them with an exhibit a contractor had built for them. It was a wheel like the one on Wheel of Fortune, but smaller and mounted on the wall instead of the floor. You would spin the wheel, it would stop on some item, and a computer would play a short video about the item. Physically and mechanically, it was a beautifully built exhibit. The electronics, though, left something to be desired.
In principle, this is pretty simple computer task. Measure the position of the wheel, and when it stops moving, play a video based on the position. The problem was the folks who created the artistic mechanics didn’t think hard about the electronics behind it. Sometimes–but not often–the wheel would play the wrong video. Sometimes it wouldn’t play at all.
The Prime Suspect
My immediate suspicion turned out to be correct. I took the wheel off its mount to discover copper foil tape on the back of it. Each pie wedge had foil in different areas and there were two brushes in each area. When the wheel stopped, two of the brushes would be shorted together and the rest were open. The way they detected that was bizarre, but that wasn’t the problem. (It involved a cannibalized PS/2 keyboard.)
Continue reading “Fifty Shades of Gray Code”
If you have used a 3D printer for any length of time, you’ve probably experienced a failed print caused by a clogged nozzle. If you’re not around to stop the print and the nozzle stays hot and full of filament for hours, the clog gets even worse. [Florian] set out to solve this issue with an encoder that measures filament speed, which acts as an early warning system for nozzle clogs.
[Florian] designed a small assembly with a wheel and encoder that measures filament movement. The filament passes under the encoder wheel before it’s fed into the 3D printer. The encoder is hooked up to an Arduino which measures the Gray code pulses as the encoder rotates, and the encoder count is streamed over the serial port to a computer.
When the filament slows down or stops due to a nozzle clog, the Python script plays a notification sound to let you know that you should check your nozzle and that your print might fail. Once [Florian] works out some of the kinks in his setup, it would be awesome if the script could stop the print when the nozzle fails. Have any other ideas on how to detect print failures? Let us know in the comments.
[Pete] needed a rotary encoder for one of his project so he set out to build his own. As the name implies, a rotary encoder measures rotation by encoding “steps” into electrical signals which can be measured by a microcontroller (or used in numerous other ways). Knowing the degrees of movement for each step will allow you to calculate precise distance traveled in applications like robot wheels. Or you can simply use the rotating shaft as an input device which navigates menus or settings.
This concept is a good one to understand. We had originally planned to build rotary encoders for the multi-person Duck Hunt at Hackaday’s 10th Anniversary but the build-off crew had difficulty getting the system to work. In [Pete’s] case he’s using photointerrupters (apparently the IR beam is easily detected through the white paper but usually these parts would be cut out of the disk). We were using reflectance sensors. Either way there’s a trick to detecting which direction a rotary encoder is turning. We’ll explain that for you after the break.
Continue reading “Which Way Are We Going? Concepts Behind Rotary Encoders”
During one of [Michael]’s many forum lurking sessions, he came across a discussion about frequency counting on a CPLD. He wondered if he could do the same on an FPGA, and how hard it would be to count high clock rates. As it turns out, it’s pretty hard with a naive solution. Being a bit more clever turns the task into a cakewalk, with a low-end FPGA being able to count clocks over 500 MHz.
The simplest solution for counting a clock would be to count a clock for a second with a huge, 30-bit counter. This is a terrible idea: long counters have a lot of propagation delays. Also, any sampling would have to run at least twice as fast as the input signal – not a great idea if you’re counting really fast clocks.
The solution is to have the input signal drive a very small counter – only five bits – and sample the counter using a slower clock on board the FPGA. [Michael] used a 5-bit Gray code, getting rid of the problem of the ‘11111’ to ‘00000’ rollover of a normal binary counter.
Because [Michael] is using a 5 bit clock with 31 edges sampled at 32 MHz, he can theoretically sample a 992 MHz clock. There isn’t a chance in hell of the Spartan 6 on his Papilio Pro board ever being able to measure that, but he is able to measure a 500 MHz clock, something that would be impossible without his clever bit of code.
We’re not really interested in building a dummy load like this one for ourselves. But the concepts behind its design make for a nice little mental exercise as you read your way through the build description. [Pabr] wanted to build a dummy load which could be used to test a cheaply made gas generator. He wanted it to be as simple as possible, while providing a range of different loads. What he came up with is this monotonically adjustable load tester which uses gray codes for switching.
The video after the break does a good job of explaining the motivation for the design. Grey coding ensures that just one bit changes at a time. The example he uses to show the importance of this is when binary code transitions from 7 (0b0111) to 8 (0b1000). Three digits have been turned off and one has been turned on. Since he’s using light bulbs for his load this will turn off 700 Watts and then switch on 800W. That sudden jump in power draw can cause all kinds of problems with the generator’s engine. But the system he wired up will ensure that each flip of a switch moves in smaller steps.
Continue reading “Dummy load uses gray code to adjust load in small steps”