@JP_Roy , that’s what multiplexing and demultiplexing is for. 
OK let me re-phrase it… how would you multiples or de-multiplex 464 rotary encoders !?
The simplest answer is this: http://playground.arduino.cc/Learning/4051 - however eventually you will run out of control pins with that. But there are other solutions available, including a multiple-input A/D signal and single serial output method.
I kinda understand rotary encoders but did not design anything with them yet, so no hands-on.
I was thinking that potentiometers could actually be used but realised that you would need 464 analog inputs so… some kind of huge analog input multiplexing interface.
I went through the Arduino Playground but still can’t imagine an easy way to deal with 464 rotary encoders !?
An encoder, like the one I used (HEDS-973x series), puts out an analog signal, most of them do. The more expensive ones will put out a digital signal. But, a single output encoder will simply give you a HIGH or LOW on the signal line. That’s easy to read. And having multiples of them means you can shove several on a multiplexer (8-channel, 16-channels, possibly more) and then read the mutiplexer’s output. Depending on what kind, you can either get a serial, single stream output, an 8-bit output (you’ll need 8 pins to read it), or other options.
In my case, the encoder I picked is a two channel, quadrature output. The two channels are offset so the signal that comes out can be used to determine whether it’s rotating clockwise or counter-clockwise. Again, having just a single one is easy to read, and this post shows how to do it with interrupts: http://yameb.blogspot.com/2012/11/quadrature-encoders-in-arduino-done.html
Having a large amount however, it would make more sense to stick the encoder outputs on multiplexers and more multiplexers … daisy chain them and read in data.
Think of the TLC5940, using a few pins on the controller to drive a bunch of LEDs. Now imagine the reverse and instead of LEDs you have encoders that are feeding data back to the controller.
You wouldn’t need to read all the encoders in one central spot. Each module could be independent and use a PIC microcontroller (or AT Tiny 85) to read one encoder and output to one pixel. One microcontroller pin could be used for the signal to “clear” the display, which could be as simple as a button that connects all such pins to GND.
That too. Adding a micro inside each pod is trivial, and can be made to only run that pod. Having them all communicate together, to act as one larger display, that would require a bit more work, but again, it’s not that hard to do.
Hey @JP_Roy , this link here is a guy that wrote about multiplexing a bunch of pots, both digital and analog. It might help give you some ideas of how it would work: http://forum.djtechtools.com/showthread.php?t=29052
Would something like this possibly work? The idea would have an attiny85 (or similar) in each puck unit. If all the pucks were being controlled by the master MCU running some sort of pattern then the attiny would just send the data signal straight through from the master MCU to the LEDs.
To switch all the pucks into free user mode, the master MCU would switch the mode control line (from low to high for example). Then the attiny would read encoder signals A&B and directly output a data signal to the LEDs.
As soon as the mode control line is switched back the attiny goes back to passing through the data signal from the master MCU.
I also really like @Garrett_Durland idea of putting the LEDs below the rotating puck. Definitely simplifies some things. I’m sure it would be easy enough to block/prevent light from leaking out around the bottom.
Here’s another interesting question regarding cycling through colors on the puck when in free user mode. Rolling through the hues is easy, but it also needs to be able to be off/black, and maybe white as well, right? Perhaps a little extra logic would be needed to roll from red to black, then white, and then back into red again and continue around the color wheel. For example, remap hue range 0-4 to black, and 251-255 to white and that way the puck could also be turned off or set to white.
Most rotary encoders have a button that is activated when you press down on the knob or shaft. I’ve used this with the arduino button library to implement different functions for short clicks, long clicks, double & triple clicks, etc.
@marmil , they all seem to start at the blue end of the rainbow and go from there. The way I figured, if they’re off and you start turning it, it will fade on to that blue and continue onto the rest of the rainbow and maybe at the end blend to white and possibly stop (forcing you to start turning it back), or fade off again before repeating the color rainbow. Programmatically, I wasn’t thinking of counting steps. Think of a long strip of film for which you only see one frame at a time. Turning the encoder will cause the film to move forward or backward. So rather than saying, it’s 255 steps to go from one end to the other end, you can make it even more precise by saying, each 3 pulses is a hue change. This would allow for very fine control of the colors, and you end up spinning the cap more than just one turn to go through the entire color rainbow (though not excessively so.) The one thing it doesn’t appear to allow is different levels of brightness on the colors.
@Ashley_M_Kirchner_No Ah that makes sense. Yes, could easily tune how many “clicks”/turns to do a hue cycle your way.
And fading up from black to a dark color like blue is perhaps visually more appealing then to a lighter color. Actually I like the idea of having it stop and not starting the color cycle over as well. Probably makes the UI a bit more straight forward.
@marmil , I think your suggestion will run into problems with distance with the ‘mode control’ signal. With the LEDs, at least the controllers will help reshape the signal as it travels down the line, but the mode signal will need to get boosted the further away it gets. It’s not a bad idea, it just needs a better implementation.
@Ashley_M_Kirchner_No if you are considering putting an attiny85 just go with an attiny44 drive the LEDs thru 3 pwm… Use a pin for touch sensing… And serial/spi in series to communicate each pod color… no encoder no rotating parts cost goes down a lot.
@Ashley_M_Kirchner_No Maybe ditch the mode control wire, and instead have the attiny look for a certain data string (steam, key, trigger. Not sure what the best term is.) If it received that string it could then stop passing data from the master MCU through and switch to reading of encoder and sending it’s own data out. Sending the correct data string from the master MCU would set it back to passing data through again.
@Philippe_Charest , that defeats the purpose of attempting to recreate the original display, where you rotate the knob to get a color hue.
@marmil , nah, not ditch it entirely, just a slightly more robust solution. I have yet to think about what would work best, but I’m also pre-occupied with my other (paid) project at the moment to really sit and hash this one out. Also, as far as disabling the local μC in favor of the main μC, you’d have to completely cut off the signal lines to avoid issues with the local μC since you would essentially “back feed” into it and weird things can happen. A diode might help as it only allows current one way however I don’t know how it might affect the data signal. The other issue here too is the local μC would likely need to get reset too when it needs to take over for user control, or maybe not. Dunno, I need time to breadboard this out and start playing with it. Time, what a novel concept …
@Ashley_M_Kirchner_No Your suggestion that the “mode select” idea needs a better implementation got me wondering what that might be.
Instead of a single common mode select wire (that is tied to all pucks), what if it cascaded from puck to puck, similar to a LED data line? This would add an extra wire (for a “mode In” and “mode Out” wire), but would this provide a better/stronger signal to be sent from puck to puck?
You’re essentially suggesting a rudimentary TWI setup. Possible, but with an attiny85, you’re out of available pins for even one wire, unless you use a one-wire LED setup (which I personally don’t like using, I prefer the robustness of a clock line):
*Mistake discovered, you do have an empty pin … *
PIN1 - RESET
PIN2 - Sensor A Interrupt - PCINT3
PIN3 - Sensor B
PIN4 - GND
PIN5 - MOSI
PIN6 - / MISO
PIN7 - CLOCK
PIN8 - VCC
By the way, that setup will only read half the resolution of the sensor because it’s only using one interrupt, which is a limit of the attiny85. For full resolution you’d need two interrupts.