Potentiometers affecting each others when connected to 74HC4051

Status
Not open for further replies.
Sorry. No, I've left it out and it did work anyway. If you experience jittery readings I guess you could try and add it. For a more technical and correct answer, someone with more experience might have to fill me in. I just know what have worked for me.

I'm right now waiting on the chips so I can test it out.
 
Well the code at the beginning of this thread throws an error when I compile it. error.jpg
 
Last edited:
Well the code at the beginning of this thread throws an error when I compile it.View attachment 7224

That code was written for Teensy 3.2, which has configurable analog resolution. Teensy++ 2.0 does not have that feature.

You must remove that line. Elsewhere in the code, you'll need to divide the analogRead results by 8, since they'll be 10 bit numbers instead of the 7 bits that code expects. Such is the way of using examples you find on the internet. When they're not written for exactly the hardware you're using, some minor editing is usually required.
 
Thanks for saying the code some what works but you didn't answer the other question is the capacitor really needed it is not shown on here but you guys kept talking about it.

You should *NOT* add any capacitor to the analog pin if you're using the 74HC4051. The page says:

A delay is required between 74HC4051 change and analogRead(). Any extra capacitance can greatly increase the required delay.

Perhaps that's not perfectly clear? You don't want to greatly increase the requirement for a delay. That's bad. So do not add any capacitor on the analog input pin. If you disregard this advice, you'll have to increase the delay. If you disregard that too, you'll end up with the problem this thread is about, where the signals (appear to) interfere with each other. Obviously that's not a good thing, so don't add the capacitor.

Other pages on this forum and many websites which aren't about the 74HC4051 mux approach say to use a capacitor. That's (usually) good advice when not doing this sort of multiplexing. But when you're switching the signals around, that capacitor which normally helps becomes harmful. Don't do it.

Hopefully that answers your question?
 
You should *NOT* add any capacitor to the analog pin if you're using the 74HC4051. The page says:



Perhaps that's not perfectly clear? You don't want to greatly increase the requirement for a delay. That's bad. So do not add any capacitor on the analog input pin. If you disregard this advice, you'll have to increase the delay. If you disregard that too, you'll end up with the problem this thread is about, where the signals (appear to) interfere with each other. Obviously that's not a good thing, so don't add the capacitor.

Other pages on this forum and many websites which aren't about the 74HC4051 mux approach say to use a capacitor. That's (usually) good advice when not doing this sort of multiplexing. But when you're switching the signals around, that capacitor which normally helps becomes harmful. Don't do it.

Hopefully that answers your question?

I wasn't going to add one someone already said it was not needed so I wasn't going to add one.

you'll need to divide the analogRead results by 8, since they'll be 10 bit numbers instead of the 7 bits that code expects.

Could I have an example of this in code because I'm really new to this and have no clue how to do this. I have programmed before but its been a while and this is a new programming language.
 
That code was written for Teensy 3.2, which has configurable analog resolution. Teensy++ 2.0 does not have that feature.

You must remove that line. Elsewhere in the code, you'll need to divide the analogRead results by 8, since they'll be 10 bit numbers instead of the 7 bits that code expects. Such is the way of using examples you find on the internet. When they're not written for exactly the hardware you're using, some minor editing is usually required.


could this code work for the 74hc4051 and the teensy 2.0 ++?

Code:
int chipselect = 0

switch (chipselect) {
    case 0:
      // pinMode(4, OUTPUT_PULLUP);
      // pinMode(5, OUTPUT_PULLUP);
      // pinMode(7, OUTPUT_PULLUP);
      chipselect = chipselect + 1
      break;
    case 1:
         pinMode(4, OUTPUT_PULLUP);
      // pinMode(5, OUTPUT_PULLUP);
      // pinMode(7, OUTPUT_PULLUP);
      chipselect = chipselect + 1
      break;
    case 2:
      // pinMode(4, OUTPUT_PULLUP);
         pinMode(5, OUTPUT_PULLUP);
      // pinMode(7, OUTPUT_PULLUP);
      chipselect = chipselect + 1
      break;
    case 3:
         pinMode(4, OUTPUT_PULLUP);
         pinMode(5, OUTPUT_PULLUP);
      // pinMode(7, OUTPUT_PULLUP);
      chipselect = chipselect + 1
      break;
    case 4:
      // pinMode(4, OUTPUT_PULLUP);
      // pinMode(5, OUTPUT_PULLUP);
         pinMode(7, OUTPUT_PULLUP);
      chipselect = chipselect + 1
      break;
    case 5:
         pinMode(4, OUTPUT_PULLUP);
      // pinMode(5, OUTPUT_PULLUP);
         pinMode(7, OUTPUT_PULLUP);
      chipselect = chipselect + 1
      break;
    case 6:
      // pinMode(4, OUTPUT_PULLUP);
         pinMode(5, OUTPUT_PULLUP);
         pinMode(7, OUTPUT_PULLUP);
      chipselect = chipselect + 1
      break;
    case 7:
         pinMode(4, OUTPUT_PULLUP);
         pinMode(5, OUTPUT_PULLUP);
         pinMode(7, OUTPUT_PULLUP);
      chipselect = chipselect + 1
      break;
    default: 
     chipselect = 0
    break;
  }
 
Last edited:
When controlling the 3 address pins of a 74HC4051, normally the 3 pins are always configured in OUTPUT mode and you use digitalWrite() to control them.

Using pinMode() with INPUT_PULLUP to control the 74HC4051 isn't a good approach. It probably won't work. Even if it does, the performance will probably be poor.
 
When controlling the 3 address pins of a 74HC4051, normally the 3 pins are always configured in OUTPUT mode and you use digitalWrite() to control them.

Using pinMode() with INPUT_PULLUP to control the 74HC4051 isn't a good approach. It probably won't work. Even if it does, the performance will probably be poor.

Will you look at the code again because I went and fixed it to stay OUTPUT instead of INPUT. That is what I get for programming when I'm sleepy.
 
There's no such thing as "OUTPUT_PULLUP".

If you want help, you really must post a complete program which can be copied into Arduino and verified. See the "Forum Rule" which appears at the top of every page in red text. We have this simple rule because posting a complete program lets everyone help you much easier. It saves everyone a lot of time and trouble, and you get much better answers.

Please, post a complete program which you've actually compiled with Arduino. In Arduino, you can use CTRL-A and CTRL-C to copy the entire code to your clipboard. Then paste the entire thing here between code tags.
 
Analog filter pretty mux?

If there was an analog LP pre-mux (on each pot) would the TC be less problematic?

I'd think the charge would have more time to stabalize as the mux cycles thru the inputs. And the difference in voltage would likely be less significant as each pot has to pass thru the intermediate states.

I know it's a much higher part count but if you need to get rid of HF noise without multiple code LPs would it work in theory?
 
Adding a capacitor to every pot might help a little. Maybe. But a little math can keep the scale of these things in perspective....

But if your pots are 10K, then the worst case impedance is 5K when it's near the middle of its range. The switches are usually well under 250 ohms. The total capacitance should be well under 50 pF if you haven't added any capacitors.

5250 ohms * 50 pF = 0.26 us.

Even if you wait 10 of those time constants for the signal to settle, that's still under 3 microseconds.
 
Thanks Paul... but I'm not sure I understand your point... I'm way out of my depth on this stuff but that never stops me.:p

I get that no added cap means very low τ (R*C) and adding a cap post MUX can be a serious problem as the charge in the cap will massively slow the response to the (possibly large) difference between the voltage from one pot to the next as you cycle thru and this delay multiplies by the number of channels so the more inputs the worse this situation gets... so far so good for me... but why does this speak against electrical filtering before the MUX? (If it's needed at all, and maybe that's your actual point!)

It seems to me the τ of a filter upstream from the MUX will have no impact outside of what it does to the voltage on the pin of the MUX

Am I out to lunch on this? If not that's all my point was... before the MUX you can filter as if you were doing a single channel...
 
Last edited:
but why does this speak against electrical filtering before the MUX? (If it's needed at all, and maybe that's your actual point!)

Yes, that's exactly the point. It's (probably) not needed.

But if you really want to add those capacitors, go ahead, as long as they're on the pot side of the mux.
 
Thank Paul... sorry for the rambling I've since removed.

My take away... hysteresis is needed to tame minor noise
...analog fliters are likely not needed for midi resolution
...if you do use don't put one between a mux and the Teensy
 
I have found it best to connect the 3.3v to the positive of the pots while driving the Teensy with 5volts. I connect the 3.3v to the AREF and specify AREF as external.
I am currently running with 48 pots. I sample four times and average for each pot. The biggest noise issue I had was with an XBee on the 3.3v so I moved it onto the 5 volt power (Xbee explorer). I did find one pot to be noisy and replaced it.

I have VERY low noise level down to +- 1 with some spikes to +- 2 (of 0-1023).

Can you provide the code please?
 
Status
Not open for further replies.
Back
Top