16N Faderbank is Happening


@iPassenger – i can has PM? Based in Finland, which is practically across the Channel – and a couple of countries and one more sea over :slight_smile:

Having some troubles getting 16n and ER-301 to play nice.

When I plug the USB from the 16n into my computer and go the 16n test page every thing works great. As soon as I power up the ER-301 the MIDI on the test page stops working. I’m interpreting that as a sign that the 16n is crashing, I’m assuming you can run USB MIDI and i2c at the same time. And I’ve never gotten SC.CV to work.

So, here’s what I’ve done so far:

-Made the shunt as indicated earlier in this thread. I wish there was a way to test it. I feel like my soldering chops are not great, but they’re not bad either. I’m worried I lingered with the iron too long and melted something, but it’s probably fine, I’m just being paranoid.
-Jumpers that go from the pins on the CPU board:

  • 1st: Black (SCL)
  • 2nd: Red (SDA)
  • 3rd: White (GND)
  • 4th-5th: nothing

-Enabled Teletype control in system settings and set the address to 0x31
-Connected the jumpers to a 1/8th TRS jack with the following:

  • Tip: Red
  • Ring: Black
  • Sleeve: White

-I did a continuity test and it all seems solid. I’m using a really short 1/8th TRS cable to test just to rule out length issues.

On the 16n side:
-Mine was made by Raph at Michigan Synth Works and I asked him to put pull-up resistors on R17 and R18. I assume he did, I sent an email just now to confirm, but I suppose I could crack it open to look for myself if need be.
-I compiled with the #define MASTER 1 line uncommented in the config.h file

And just in case it makes a difference but I tried every combination of plugging in the USB on the 16n first then turning on the ER-301 or vice versa, and swapping the red and black jumpers on the pins on the CPU or vice versa. And still no dice.

Any ideas? Any logs I should be providing to debug?

1 Like

I would try just plugging the usb into a power adapter to make sure it’s getting the correct current and then powering up the er301. Set up a sc.cv at port one and see if you get any activity. I’ve had issues with the 16n not getting the right power from a computer and not functioning properly.

This is what I would check first. You don’t necessarily need to take it apart to see if the resistors are there (although taking it apart makes it a lot easier to see). With a flashlight, you can look past the i2c jack on the 16n. Behind it are four diodes and the resistors should be on the right and left of these diodes. If they are installed, you’d see six smd-parts there, otherwise it’d be only four.

I got the same suggestion over on lines and lo and behold:

The pull-up resistors aren’t there. So, I’m working on figuring that out, my soldering chops aren’t up for pieces that small …

hey, first of all: anything -duino related newb here so go easy =)

i bet someone is able to point me in a useful direction. i got my 16n, tested that it transmits midi and all sliders work, etc. i tried to access and inspect its firmware with teensy loader, but i am not able to, nor do i know if that would even be possible. i’m over my head on that one, cannot seem to even download the 16n’s config.h to modify (set to master, set i2c address) and flash into the device from github.

mine should have FW 1.32, and should be configured as leader/master as per Raph of Michigan synth works. soldered in the pull-ups just to be safe, but i did take 2k’s for those (recommendations i think ranged from 2.2k to 4.7k, but documentation is pretty scattered on this as on all relevant points, hence my confusion…) since i had those on hand.

now, i’m not seeing anything on the ER-301 side when i manipulate the sliders. should modulation appear at the teletype SC.CV-unit’s output when the port number matches the slider and the slider is moved? there i’ve tried the range up to 48, nada. should the i2c addresses match? this would seem to require flashing the FW to 0x31, 0x32 or 0x33 since these are the only possible in the 301 and the 16n would i guess be 0x34.

also, i have a pre 8/18 unit, so the UART pins are named TX, RX, GND, GND, +5v. not SDA, SCL. so that’s also a point of possible confusion, although there i just connected GND to GND, and have tried TX/RX to tip/sleeve and vice versa…

so thanks to the more savvy in advance.

Yo! I just waded through this process with a few pitfalls of my own. If you’re unsure your unit is in master mode, go here https://github.com/16n-faderbank/16n/releases/tag/v1.32 and grab the 1.32 master hex file if you haven’t already. Mine were assembled by MSW as well, and both needed to be flashed with the master hex before working over i2c. Make sure you’ve got a usb data cable also, because that tripped me up too. After that, you should be able to see output in the sc.cv unit when set to ports 1-16.


The build guide says 4.7k.

Yes, that’s exactly what’s supposed to happen.

You can download the whole repository as a zip file (direct link to zip) if you don’t want to deal with git. In it you’ll find the firmware which you can simply open in the arduino app.

It’s sort of hard to say what exactly could be wrong. I’m not sure how wide the range of acceptable resistances for the pull-ups is and whether that’s your problem. I’d first make sure that the software is right.

No. The 16n uses address 0x34 and it tries to communicate with the ER-301 on 0x31.


to change the firmware source you have to clone the firmware repository, install arduino, open the .ino file and configure the board.

you can find instructions on how to do the above here and here.

the 2nd link will also tell you how to configure 16n to run as leader which is what you want if you want to connect it directly to er-301.

0x31 is the address you want (0x34 is 16n own address when it’s used as a follower with teletype). make sure to also select 0x31 in er-301 admin settings (if you have an older version of firmware you might not have 0x31 in the list of i2c addresses, use 0xB1 instead).

for er-301 connections check this link: http://wiki.orthogonaldevices.com/index.php/ER-301/Teletype_Connection


many thanks for your replies!

well, if the browser test works on my USB cable i take it as verification that it is suitable.

i cannot bring the arduino app to function on my mac, troubleshot it yesterday for a couple of hours, just shuts down right after opening. the teensy loader app does not recognise config.h, i’m pondering just manually altering the extension to config.hex to be able to try something, since that file seems to have the content for the flashing, but since i’ve no idea what the hell i’m doing i’ll refrain for now.

i wont try to change the firmware for now, in light of the responses it does not seem necessary. i’ll settle for flashing the firmware since i’ve confirmed i have the appropriate one.

my unit is older, and this sadly does not apply. the labeling of the pins on my unit does not match that stated anywhere that i was able to find (mine has TX, RX, GND x 2 & 5v pins), but one being ground that’s a soluble problem.

oh yeah, i used a TRS cable of 1m, will try a super short one to rule that out…

now i have. will try that 1st.

you can’t do that. config.h is part of the source code. you have to use arduino program to build a hex file from the source code.

Here is your hookup guide:
But have you performed the diode bypass mod on your ER-301?

thanks, yeah, looking at it now it’s obvious. must have been stoned yesterday :joy:

the mod is performed.

anyway, got it to work. used 5k1 for the pull-ups, flashed the correct .HEX file, flipped the cables a couple of times, and somehow it worked.


I have a question, maybe someone here could help me:

I’m trying to figure out a way to limit the maximum CC a fader sends per fader - I’ve found the right thing to modify, I think:

#ifdef FLIP
temp = MAXFADER - temp;

temp = constrain(temp, MINFADER, MAXFADER);

temp = map(temp, MINFADER, MAXFADER, 0, 16383);

// map and update the value
currentValue[i] = temp;


(Here are the files: https://github.com/16n-faderbank/16n/blob/master/firmware/_16n_faderbank_firmware/_16n_faderbank_firmware.ino?fbclid=IwAR3ppUCqOS4d_4gnIXWPcJ-BcyHziEPBJd4ly5Rren9GQBGDyJYFmMQMGks )

But I can’t figure out how to modify this per fader. Does anyone have an answer? I’m only learning and was pretty proud to be able to change all other things I wanted and to send it to the Teensy, but this seems difficult.



It seems to me like MINFADER and MAXFADER do not speak about CC, but rather about minimum and maximum values that the firmware expects from the AD converters (as the comment in config.h says: to deal with tolerances).

The relevant part that writes midi is here. You could define two arrays minCC[] and maxCC[] for your minimum and maximum cc-values and push the value of shiftyTemp in between minCC[q] and maxCC[q]. You’d want to do that right after the shift has taken place (i.e. before the if-statement) so that the change detection keeps working properly.


Alright! So, would

const int minCC[] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

const int maxCC[] = {108, 108, 108, 108, 108, 108, 108, 108, 127, 127, 127, 127, 127, 127, 127, 127};

Inserted before line 254:

// if there was a change in the midi value
if (shiftyTemp != lastMidiValue[q])

do the trick?

1 Like

Oh, you only want a max value. Then you can drop the minCC array. maxCC looks fine like that.

But of course you have to also map shiftyTemp into the space between 0 and maxCC, e.g. like this:

shiftyTemp = map(shiftyTemp, 0, maxCC[q], 0, 127);

Also, you’d want to put the declaration of the array somewhere up top where the other constants and variables are initialized - you don’t need to create that array every time you want to send midi values, just once at the start.

So, basically declare the array alongside the other constants and variables and then change:


I have not tested this in any way, but that seems about right to me.


@x2mirko – thank you so much. I’m often pretty apprehensive about asking for advice about these things, because I know I’m in over my head and I’m worried about backlash, with DIY and coding more than other topics, for some reason. I love the fact that you took the time, much appreciated :yellow_heart:

1 Like