Struggling with making an arduino nano midi controller

[ElectricDruid]

Have you got any way you can check that you get the correct incrementing count on the S0-S1-S2-S3 Mux address pins? They should all be at octave frequencies, since it's a binary count.

You showed us a picture of your PCB, but not of your arduino or where the wires from the PCB go to. Can we see that too, please? Clearly if the board is wired to the Arduino incorrectly, it's not going to do what it's supposed to do.

Also please tell us what you think you've done - what you've connected to what and why. This is partly so we can cross-check, but also because I often find that by trying to explain something to someone I go "Aaaaahhhh!!!" and realise what it was that I was missing. So explain to us in complete detail how the two boards connect together and which pins go to which and what each one does. You might find you have a "Aaah!" moment too.

[Esppse]

Have you got any way you can check that you get the correct incrementing count on the S0-S1-S2-S3 Mux address pins? They should all be at octave frequencies, since it's a binary count.

You showed us a picture of your PCB, but not of your arduino or where the wires from the PCB go to. Can we see that too, please? Clearly if the board is wired to the Arduino incorrectly, it's not going to do what it's supposed to do.

Also please tell us what you think you've done - what you've connected to what and why. This is partly so we can cross-check, but also because I often find that by trying to explain something to someone I go "Aaaaahhhh!!!" and realise what it was that I was missing. So explain to us in complete detail how the two boards connect together and which pins go to which and what each one does. You might find you have a "Aaah!" moment too.

Ok here are some more detailed pictures of the wires:

So the color code is:
S1: White
S2: Blue
S3: Green
S4: Yellow

M1: Orange
M2: Purple

5V: Red
GND: Black

2-3-4-5 need to be S0-S1-S2-S3 according to the instructions so I have done that. 5V goes to the VCC pin on both Multiplexers. All the buttons (bottom pin), GND, and Enable pins on the multiplexers are all grounded.

220 Ohm resistors for midi (to 5V and to TX pins)

What does increment counting mean on S0-S1-S2-S3? Sorry, very new to digital coding.

[anotherjim]

Even if you don't have a scope, your DMM reading volts can give clues when hunting logic bugs.
Assuming it runs off 5v...
5V reading means it's stuck high and not pulsing (unless really fast narrow pulses). Conversely, 0v tells the same story.
2.5v or near suggests it is pulsing and you would expect a counter output to read very close to 2.5v.
S0 to S3 counts up (or down!) in binary...
S3>S0
0000
0001
0010
0011... etc until
1111 then back to...
0000 and repeat.
Any of these pins will read around 2.5v.
The 4 S pin bits select which of the mux chips inputs connect to the COM pin.
When you press a switch, it will ground whichever mux input is selected and be read as a 0 on either mux1 or mux2, otherwise, with no buttons pressed, the mux inputs will stay near 5v and read as 1(with MCU pin pull-up enabled).
The program uses the current select count and the state of the mux input to work out which key has been pressed.

[ElectricDruid]

Well, I dunno. I've been through your code and checked the button assignments and mux setup and whathaveyou, and it all looks ok. The wires are wired up as per the comments in the code - Mux S pins to pins 2,3,4,5, and the two mux common wires on pins 9 and 10. It *looks* like it should be simple, but if it's not working, it isn't.

Something's not right somewhere, but without knowing what the Arduino code is *expecting* it's hard to find.

It still sounds to me like the Mux isn't scanning properly, but I don't know why that would be the case. Are you sure that the Nano is a drop-in replacement for the Uno in this case? If the code assumed a certain pin layout which is only true on the Uno, that could explain why things aren't working for you.

[anotherjim]

Nano is just using the SMD quad pack ATMega328 while the Uno is a DIP28 version - the same chip. Although the Nano can have 2 more pins for the complete 8 bits of portA versus 6 bits.

[ElectricDruid]

Nano is just using the SMD quad pack ATMega328 while the Uno is a DIP28 version - the same chip. Although the Nano can have 2 more pins for the complete 8 bits of portA versus 6 bits.

I see. Thanks Jim. That does sound pretty interchangeable. Dang! There goes another theory! 

[Esppse]

Even if you don't have a scope, your DMM reading volts can give clues when hunting logic bugs.
Assuming it runs off 5v...
5V reading means it's stuck high and not pulsing (unless really fast narrow pulses). Conversely, 0v tells the same story.
2.5v or near suggests it is pulsing and you would expect a counter output to read very close to 2.5v.
S0 to S3 counts up (or down!) in binary...
S3>S0
0000
0001
0010
0011... etc until
1111 then back to...
0000 and repeat.
Any of these pins will read around 2.5v.
The 4 S pin bits select which of the mux chips inputs connect to the COM pin.
When you press a switch, it will ground whichever mux input is selected and be read as a 0 on either mux1 or mux2, otherwise, with no buttons pressed, the mux inputs will stay near 5v and read as 1(with MCU pin pull-up enabled).
The program uses the current select count and the state of the mux input to work out which key has been pressed.

I just checked the voltages of all the buttons, they are all over the place. A bunch read between 3.6-4.3.  A few read 2.9. And there were a couple as low as 1.12.

Like on the first multiplexer, the first 12 input pins read 4.3. Then the rest gradually drop 3.7, 2.9, 2.0, 1.1.
The first 2 on the second multiplexer reads 2.0. Then the next 7 are 3.7. The last 2 are 4.2. Rest unused. 

S0-S3 are all about 2.0.
M1 is 4.5
M2 is 3.1.

V is 4.67

I am assuming this is irregular?

[anotherjim]

S0-S3 may be ok. Each of those S pins will be 1 for close to the same time period they are 0 so the DMM will average the reading to half of the total voltage. 2v isn't too bad and all four being the same is good.

The two Mux inputs though should be both close to supply volts with no button pressed and it seems that only one is.

Because each button only gets selected by a mux chip for 1/16th of the total scan time, the button pins of the mux chip only tell the truth 1/16th of the time. They will "float" at no particular level when unselected and no button is pressed. Your DMM won't see this as it ought to zero on a disconnected wire, but perhaps it's sensitive enough to read leakage in the mux chip or from the wiring. Pressing a button only connects the mux pin to 0v for 1/16th of the time, so it will only cause a tiny drop in the average reading.

Are the mux chips in sockets? Take them out and see what the Arduino mux inputs read then. They should both be 4.9 ish.
If they are good, turn off and use the DMM continuity test to look for shorts between adjacent mux pins and that a pin shorts to 0v when its button is pressed.

If the chips are not socketed, you'll have to disconnect the two mux wires. You can still do continuity checks of the mux chips, but be careful to keep probe polarity correct (negative on 0v) or else the CMOS chip pin protection diodes will conduct and fool you.

[Esppse]

S0-S3 may be ok. Each of those S pins will be 1 for close to the same time period they are 0 so the DMM will average the reading to half of the total voltage. 2v isn't too bad and all four being the same is good.

The two Mux inputs though should be both close to supply volts with no button pressed and it seems that only one is.

Because each button only gets selected by a mux chip for 1/16th of the total scan time, the button pins of the mux chip only tell the truth 1/16th of the time. They will "float" at no particular level when unselected and no button is pressed. Your DMM won't see this as it ought to zero on a disconnected wire, but perhaps it's sensitive enough to read leakage in the mux chip or from the wiring. Pressing a button only connects the mux pin to 0v for 1/16th of the time, so it will only cause a tiny drop in the average reading.

Are the mux chips in sockets? Take them out and see what the Arduino mux inputs read then. They should both be 4.9 ish.
If they are good, turn off and use the DMM continuity test to look for shorts between adjacent mux pins and that a pin shorts to 0v when its button is pressed.

If the chips are not socketed, you'll have to disconnect the two mux wires. You can still do continuity checks of the mux chips, but be careful to keep probe polarity correct (negative on 0v) or else the CMOS chip pin protection diodes will conduct and fool you.

Ok some progress, I disconnected M2 from the Nano. (its S0-S3 pins are still tied with the first multiplexer, and it is still receiving voltage)

M2 is 1.8 volts disconnected from the board.

And interestingly enough, all the buttons tied to the first multiplexer actually work right now! So what is strange is that when M2 goes to the Nano, it affects buttons tied to the first multiplexer. Ex... 1st button sends out A and A# notes. It basically sends out the adjacent button's note assignment, sometimes the next 3. Odd right? What could be causing this?

When I tested it just now, I didnt even change the code to say I only have 1 multiplexer connected, and it still worke (first multiplexer buttons). So that lower voltage on M2 is definitely suspicious. Any ideas?



OK just did another test, I put M2 into Nano Pin 8 instead of 10 (adjusted the code for it). It all works except 1 button. The first input of the second multiplexer.

I tested the physical button, it works correctly, shorting to ground when pressed. The button also passes the continuity test going to the its multiplexer input. And there are no shorts to any adjacent pins. Now this is strange. The note I designated to it is C#4. When I press that button, it wont send out the note. When I push a different button, sometimes it sends out C#4 like 12 times. As if the previous presses were "held", then released when I pressed a different button. But I cant replicate this behavior though. Is this a bad chip?

[Esppse]

Another test, for some reason, that button came to life just now... but unfortunately that random stream comes out. Look here:





All the C#4 messages shown here were after a different button was pressed.

[anotherjim]

If you're going by silkscreen legends on a board -  they can have errors. I spent ages trying to get midi i/o working until I realized they had swapped the UART Tx and Rx pin legends on a Uno clone board.
Also, some I/O shares functions or have something attached. The onboard LED they have for the test/programming indicator might be in the way - it can stop a pin being used as an input.
You may need to check with the Arduino board documentation. They are supposed to be open source so it should exist.

[anotherjim]

So, I tried to read thru the sketch (not 100% familiar with this high-level language stuff), and I don't see any nuts&bolts pin setup commands at all. I do see an #include for controller.h, so I imagine this is a barebones framework for this application. In which case, I have no idea what it's doing!
I do suspect M2 is behaving like it has no pull-up enabled. It's odd that it's connected to A0, which can be used for digital input, but it has to be told that somewhere.
It could be proved by fitting an external pull-up resistor on M2 to 5v, 10k to 100k.
Note that AVR chip inputs include Schmitt trigger action, so an input voltage floating between 0v and 5v will be ignored.

[Esppse]

So, I tried to read thru the sketch (not 100% familiar with this high-level language stuff), and I don't see any nuts&bolts pin setup commands at all. I do see an #include for controller.h, so I imagine this is a barebones framework for this application. In which case, I have no idea what it's doing!
I do suspect M2 is behaving like it has no pull-up enabled. It's odd that it's connected to A0, which can be used for digital input, but it has to be told that somewhere.
It could be proved by fitting an external pull-up resistor on M2 to 5v, 10k to 100k.
Note that AVR chip inputs include Schmitt trigger action, so an input voltage floating between 0v and 5v will be ignored.

M2 is actually connected to digital pin 8. I originally tried 10 but that didn't work for some reason. This is the second micro controller I tried with this garbled messaging. The first one was an ItsyBitsy.

Does it say somewhere that M2 is connected to A0? Some of the text in the code is actually "example user help text" and has no effect on the output.

I assume you mean this:
Mux M2(10, 16, false); //Analog multiplexer on Arduino analog pin A0

The text after the semicolon was just default example text that may be deletable. The 2 forward slashes make that part dim in the Arduino program, which I think is inactive.

[anotherjim]

//Analog multiplexer on Arduino analog pin A0

Everything after // on the line is ignored by the compiler. It's a Comment, meant to help understand the code. Get in the habit of fixing it if it's not relevant.

pinMode(pin, INPUT);           // set pin to input
digitalWrite(pin, HIGH);       // turn on pullup resistors

This is how an Arduino sketch sets up a pin function for input with pullup.

Mux M2(10, 16, false)

This function looks like it's looking for a button press returning a 0 (false) but I've no idea what 10 & 16 mean unless it's testing a specific location in an array which is probably what controller.h code is working. That included code may be written in C anyway since Arduino language only works one pin at a time for I/O and it needs to handle 4bits for the mux chip addressing.

[FiveseveN]

probably what controller.h code is working

Something along those lines. It defines Mux

Code Select Expand

Mux(byte outpin_, byte numPins_, bool analog_);

And two other classes:

Code Select Expand

Button(byte pin, byte command, byte value, byte channel, byte debounce);
Button(Mux mux, byte muxpin, byte command, byte value, byte channel, byte debounce);

Pot(byte pin, byte command, byte control, byte channel);
Pot(Mux mux, byte muxpin ,byte command, byte control, byte channel);


[anotherjim]

Well, I don't know. It looks like controller.h expects 16 buttons on mux1 and 16 pots on mux2 doesn't it? That would explain why the code has A0 for mux2, it's feeding the chips ADC.