I have a fairly straight forward art project (in principle), where i want to use a rotational sensor to determine the color of an LED. The scale though makes it a little daunting; i want to have ~400 of them in the end.
I will start with small units and work my way up, but i am worried about writing myself into a corner so i was hoping to get some community advice before i get too far.
If i want to read a knob, it seems my options are Potentiometer and Rotary encoders. The encoders seem like the best options, since they their continuous rotation (which is more robust for an interactive art piece where people will be pawing at it), however searching around it seems like they are far more expensive (was hoping ot get something around 1$ a piece), and i've never had to mux them or pots before, so im not sure if there are any complications i should be aware of.
Would it be an option to have a push button to determine which colour to change and then you would only need a single encoder ?
As well as being more expensive encoders are more complex to program. Keeping track of the position of 400 would be a challenge.
However 400 potentiometers would also be a problem - an Arduino Mega has 16 analog inputs but it only has a single ADC which would have to be used in rotation to read 16 pots.
You are correct. It would be foolish indeed to use a potentiometer for public interaction. While these cheap devices may not in the long term be particularly rugged, they will be far more so than a potentiometer. Of course you could get more rugged potentiometers, but you can certainly get far more rugged encoders. It's horses for courses, and cost.
What you need to explain - and plan out for yourself of course - is how integrated this project needs to be? Do they all have to interact, or are they all separate, or divided into groups? It is probable that multiple cheap Pro Minis will be the answer (and you have to determine how to drive the LEDs. You probably want "NeoPixels"). One Pro Mini, nine encoders and up to 100 NeoPixels would make a unit.
One of the nice things about some of the magnet encoders is they're can easily be daisy chained. Here's a video I made a few years back of two daisy chained AS5055 encoders. There's isn't a limit to how many of these things could be chained.
I haven't checked prices lately, but I doubt magnetic encoders would be an inexpensive solution. Besides the cost of the encoder chip, you would also need an appropriate magnet for each encoder.
Magnetic encoders probably aren't a good solution for this application but IMO they're pretty dang cool gadgets.
I'd guess that you end up with many controllers for the 400 sensors and LEDs. Find out how much you can handle with one Arduino, then replicate that system as often as required. Do you intend to use single LEDs, or strips with built-in controllers?
What I don't understand is, how people will use those 400 sensors simultaneously? Are these concentrated in one place (switch panel - how big?), or distributed?
With 2 push buttons (or one 3 way switch) per LED the color can be increased or decreased in discrete steps, while a button is pressed. This would allow to use port extenders, optionally with state-change interrupts so that a single Arduino can handle a huge number of sensors.
Thanks guys! Its nice to wake up and see all these solid responses. Since there were a few questions about it, i'll elaborate on the project a bit:
It will be a large grid, consisting of "many" of these sensor/pixel modules that i am going to build. The key is that each module is a 3 printed container, a diffuser for the neopixel (which i've used in a ton of projects and am generally comfortable with), and is attached to the pot/encoder underneath so that as you rotate the pixel, it changes its color. This basically makes a giant, electronic light bright.
I'm not going to sell these or anything, just going to bring it to burning man for my camp (basically, rough environment, but if things fail its not a big deal).
Im a software engineer by trade, so im not worried about the software side, but I am "self taught" (read "crappy") with electrical stuff (so i apologize of shit goes over my head a lot).
Thanks Paul__b for the cheap encoder link! I think i will order a bundle to start playing with. However since i am doing 1 to 1 encoders to leds, i am worried about ballooning the number of arduinos required. Is there an idea of chaining or multiplexing these types of inputs so i can cut that down?
Also, one question about the encoders. They are listed to have "Pulse circle: 20". What does this value mean exactly? Does it mean i only get a resolution of 20 different states?
If they don't have to talk to eachother, I'd make them all independent, each board with an attiny85, RGB LED (no need for neopixel, you'd have 2 pins for encoder, 3 pins for RGB LED), and the couple of passives needed to make it all work. As a side benefit, no matter what happens to an individual module, the rest would keep working.
crazyjaw:
Also, one question about the encoders. They are listed to have "Pulse circle: 20". What does this value mean exactly?
Poorly translated from the chinese? - could mean 20 pulses per revolution if you are lucky (ie 80 counts per rev).
But as with a lot of things on eBay, caveat emptor!
Typically mechanical rot encoders like this have click stops per pulse, so you probably only get 20 positions
that are useful.
Oh i like the individual board per module idea. Probably costing like $2.50 - $5 per module (~$.15 "dumb" rgb led, ~$1 attiny85, ~$1 rotary encoder, and some amount of plastic/wire/passive elements). Its pros are that i can just swap out broken modules, and its more robust. Downside is that its less flexible (if i did want to expand the scope to do patterns I couldn't), and I've never worked with them before.
I still haven't figured out the price range for the more centralized approach, since it depends a lot on how many encoders i can hook to a board. But it would be something like ~$.30 for a neopixel, and i found these 5 pack pro mini that are about 3 bucks a piece. Seems like they could handle 8 encoders (1 analog pin a per encoder?) which means its low end would be like $2.00 a module. My basic unit then would be 8 pixel octets, which would be less robust.
These are the cheapest parts i could find... but they actually dont make sense to me. It seems weird that a super simple LED and attiny would be more expensive than a smarter neopixel and more complex arduino
MarkT:
Typically mechanical rot encoders like this have click stops per pulse, so you probably only get 20 positions that are useful.
hmm, only 20 states (which corresponds to colors) is crappier than i was hoping for. What exactly would i search for if i want one with better resolution? "click stops per pulse"?
TomGeorge:
If you are using the LEDs in an array, then your input become very simple.
20 x 20 LED
The key design goal is actually to adjust the colors as simply and intuitively as possible, which i currently have designed as each pixel being rotatable, and it just rotates through the colors of the rainbow as it you move. There are a bunch of simpler and cheaper approaches (as you've suggested), but they aren't as interactive as i am aiming for.
crazyjaw:
hmm, only 20 states (which corresponds to colors) is crappier than i was hoping for. What exactly would i search for if i want one with better resolution? "click stops per pulse"?
That would be 20 states per revolution. There aren't any endstops in the encoder like there are in pots. If you're willing to turn the encoder 100 times you could have a resolution of 2000.
I just had a brilliant idea. This thing is an encoder with a RGB LED inside.
Here are three of these encoders in use with some NeoPixel rings.
I'm pretty sure I was controlling the RGB encoder LEDs with with some '595 shift registers (being shifted fast enough to generate a PWM to control the LED color mixing. It's certainly possible to do this sort of thing but I'm not sure I used shift registers in this project.
I was using the color of the knob to indicate which mode the device was in. The NeoPixels were being used as a type of dial indicator.
I thought the knobs and NeoPixels made a fun input device with feedback.
It's not easy to do, but it's possible to use '595 type shift registers to control lots of RGB LEDs. By shifting out the bits really fast, you can even get some reasonable color depth using the shift registers.
crazyjaw:
hmm, only 20 states (which corresponds to colors) is crappier than i was hoping for. What exactly would i search for if i want one with better resolution? "click stops per pulse"?
No you do not get 20 states, these are incremental encoders you only get 4 states and you have to use them to track the rotation in software. You can then divide the movement into as many "states" as you want with multiple rotations of the encoder.
For RGB LED, like WS2812B (neopixel), you get 8 bits of brightness per LED, so you send 3 bytes to each one to set its color mix.
Seems like you'd want to predefine the colors you support as you turn the one knob, working your way around the "color wheel", one example found via google search:
CrossRoads:
For RGB LED, like WS2812B (neopixel), you get 8 bits of brightness per LED, so you send 3 bytes to each
Adafruit's NeoPixel library has a nice "wheel" function which assigns the RGB values based on a single (8-bit) value indicating where on the wheel the color is located.
Right, now, these are fairly basic encoders and they are mechanical. They are basically the same as the one in your car radio knob which does volume, tone and possibly tuning as well. They have twenty detents per revolution whis is plenty; you do not need more and any more would make them too fiddly. It is up to your software to choose how much a certain number of steps changes the colour.
Note you think in steps, not position. The output is only in terms of steps, there are two outputs and the sequence in which these alternately go high and low tells you the direction of rotation - it is called "quadrature" encoding. The sparkfun page shows some people confusing themselves (as always) - this is also a "Gray code" encoding, using only two bits.
Now as I carefully explained in my first explanation, the encoder requires only two port pins (or three if you employ the "push" function, which could be an interesting variation); you connect the common to ground and use the INPUT_PULLUP function of the ATmega and need no other components, so a Pro Mini with 20 available port pins could easily service 9 encoders and drive (at least, or a multiple of) 9 NeoPixels. But it is pretty much cheap enough that you could use a single Pro Mini for only one encoder and NeoPixel - or of course, any number in between. NeoPixels are advised because they are quite cheap and require no other driver components. They do however, require a regulated 5 V power supply. In bulk, an old PC power supply is a simple approach.
And regarding the software - do not be tempted to think interrupts are of any use whatsoever. You do need to debounce the encoders in software. Even driving NeoPixels, the speed of manual rotation should not be such as to cause any difficulty.
I do think i want to use an encoder over a pot. I dont fully appreciate how the encoders work, but they seem to use a clock and a bit shift mechanism? will that still work with one of those multiplexers?
