Suggestions for using (many) pots vs rotary encoders

Projects General Guidance
21

crazyjaw:
How does everyone find these cheap parts!

The illustration I posted - and the text - was a link.

crazyjaw:
I do think I want to use an encoder over a pot.

Oh, I am absolutely sure you do. I could have cited the encoder itself, but the version mounted on a PCB with four mounting holes appears to cost exactly the same and makes it easy to mount securely.

crazyjaw:
I don't fully appreciate how the encoders work, but they seem to use a clock and a bit shift mechanism?

That is a misleading notation on the PCB. They should more correctly be labelled "A" and "B" as they are no different to each other. You need to read up on the references given on Gray code.

crazyjaw:
will that still work with one of those multiplexers?

Why are you now asking about multiplexers? I have explained that you can operate nine encoders per Pro Mini if you are using NeoPixels. Are you a bit shy about reading the responses that you receive, fully?

22

That was actually in reply to zoomkats response on the previous page (i didnt refresh and had actually missed this entire page of discussion)! I am not ignoring anyones posts, but rather still haven't come to a conclusion about the optimal approach yet.

There are actually three different designs that that people have proposed that i find super compelling:

There's Drazzy's suggestion of making every pixel independant using attiny85's to control each one, which i dig since its super robust

Theres Paul__B's suggestion of using multiple cheap boards for groups of encoders, which i like since it's the most straight forward to implement (for the most part its things i've done before)

And there is Zoomkat's suggestion of using a single board, and a bunch of muxers, which is by far the cheapest approach though it's not clear to me how to swap in the encoders to use the muxers.

I keep going around in my head which one i want to pursue! I think i like the independent pixel idea, if i can make them cheaper. So while i was putting that decision off i took a moment to mock out a design for the actual led modules i intended to build, and discovered a problem that might make me abandon the encoder (or at least prevent continuous rotation):

Here is a face-on view that a user would see. As you rotate the black part, the bit in the center changes color. Should be pretty straight forward:

1181×991 64.2 KB

and here is a side view of the components of the LED modules:

771×719 65.8 KB

From top to bottom, the components are:
-Outer hub (the part you grab and turn)
-LED Diffuser (make a nice consistent light)
-LED/Neo Pixel
-Inner hub (grabs and turns the sensor)
-Sensor

So you can see from this, the LED is in the middle of hte module, so the wires to control it go up through those holes. As the module is rotated, it will begin tangle up the wires, and if there is no endstop it will eventually rip them out.

The only other approach would I can think of would be to move the sensor to the side and have a belt or gear drive the rotation of the sensor, but i am not sure the complexity is worth it.

23

Actually i was being a fool, I think just making the encoder offset and turned by gear is the way to go. Designing and printing gears is a pain but this will allow the continuous rotation, and and the gear ratios will make it so the outer knob gets more states per revolution (i am aiming for a fairly subtle smooth transition.)

782×742 90.7 KB

24

No, you still have it wrong! The last thing you want is to construct mechanical gears.

You need to understand the concept of a "light pipe". I note your proposed gear design is based on them, but not in a very practical way.

Again, I point out that NeoPixels are going to be the easiest way to implement this. Just make your "inner hub" transparent (translucent), and surround it with (at least) four NeoPixels pointing into its conical side. From eBay, four of these will cost you less than a dollar (should be much less). Note, you are not using separate coloured LEDs, each NeoPixel contains all three colours and you simply program them (in a chain) to show the same colours. (And they are bright!)

Just to reiterate the points behind my previous suggestions:

If indeed, you were using a group of four, then one Pro Mini would easily service all four encoders and all NeoPixels.

A Pro Mini (from eBay; the particular seller I tend to recommend) is going to be the cheapest fully-functional MCU module you can get. Cheaper than ATtiny85s, believe it or not!

A "bunch of muxers" is going to be a nightmare, both in programming and more particularly, in construction. You will not save money that way! And construction is what is going to bite you - that is why even if you get them cheap, ATtiny85s are not so practical.

25

In stead of a lot of "hanger flying" on the project, the OP probably needs to get the basic components of each method and make a basic proof of concept test setup where what is involved with each approach can be evaluated.

26

Thats right. Since i cant decided which is best ill try them all as a one off and see how it goes. I've ordered all the parts and ill give it a shot (luckily they are all worthwhile components on their own even if i dont use them here) wish me luck!

27

Well if anyone is curious, i got my new printer and some parts to play with, and got a working prototype pixel:Prototype light bright pixel

It ended up being a more complex mechanism than i orignially sketched out, but the fundamentals are still the same. I used a attiny/encoder/neopixle approach, which i think is around $1.40 a pixel if i get it all in bulk, plus plastic (which might double the cost).