16n Faderbank: build help, dev suggestions

Boom. thanks @infovore increasing the activity threshold fixed the +/- 1 jumping issue. I had to increase it all the way up to 30, but it works fine. I had the smoothed values before being mapped sent out to the serial monitor so I could view them in real-time, increasing the threshold didn’t seem to decrease performance, and there wasn’t any jumping of values. Thanks again!

1 Like

Let me share what’s going on.

So, as @lemmings pointed out, we’re using a “ground plane” to connect all the ground points - basically, filling in all the blanks. When you load the brd file, it’ll look like nothing is connected:

but you’ll also note there are no yellow ‘airwires’ suggesting they need to be, and if you run a “Design Rules Check” it won’t throw errors about ground.

There are two reasons for this; firstly, I’ve turned off airwires for the GND signal. And secondly, a clue: those red/blue dotted lines around the edge: that’s a polygon that hasn’t been filled in.

If you click this icon in the toolbar:


or type RATSNEST; in the command line (if you’re me), this will happen:

and you can see that all the copper has been filled for the polygon, surrounding all the pads at a reasonable distance, but going through the GND pads. (The cross shape you can see is called a ‘thermal cutout’ - basically, it stops heat dissipating enough so you can solder it; if the GND pads were just connected entirely to the solid copper, it’d take ages to get them hot enough to solder GNDs).

In short: the plane is there, but EAGLE never fills them by default on load.

1 Like

That actually makes sense: if it was set to 4 by default, for a 10 bit adc, then for a 13 bit adc, it should probably be set to 4 << (13-10) which is 32.

I think I’m going to add that to the official firmware and do a release.

1 Like

This is what I figured - thanks for detailing it out.

At this point I’ve checked and rechecked everything to no avail. I’m pulling off the teensy which is no small task.

is U8 on backwards here?


Yes, it looks like it.

Definitely backwards! @bradfromraleigh

Great catch! That must have been when I poured the second glass of wine. Will correct this afternoon and report back!

EDIT: Good news is that I got U8 off and the Teensy powers up like it should now! Bad news: 2 legs of U8 were damaged in the process so a replacement part is forthcoming.

Also, after hunting down a few extra steps that weren’t obvious to me in the write-up (the mux library, etc.) I was able to get it to compile and run. Everything tests OK (except channels 13 & 14, obviously) and I await my new opamp to be fully operational. Thanks for the help everyone :slight_smile:


hello all, wondering if someone can help me with this. i have a modded trs cable connected to an i2c.
tip to sda, ring to scl and sleeve to gnd. this is connected from my faderbank to my tt backpack which has a 301, jf and w/ connected to it. i’m trying to test basic i2c connectivity from my faderbank to the tt and not really understanding how to do that.

also i’ve tried sending messages from the faderbank through the tt to the 301. i tried something really simple like opening a subchain in a vca. sc.cv port 1 adjusting the gain and then moving the 1st fader but i’m not getting anything.

any help would be appreciated.

If the faderbank is not leader on the i2c bus (and it shouldn’t be, as this is the role of teletype here), you have to poll the fader values from the teletype with the FB op..

hi, i see that typing fader or fb 1-16 should show you the value but all i’m getting is 0.
the i2c cable itself is quite short, 20 cm. the trs on the other hand is a lot longer…around 3 feet.

also the fb is not leader :man_shrugging:

replied in the A user's guide to i2c thread

1 Like

Any ideas what to look for if a certain fader stays above a certain value on the testpage after being physically moved to zero again?
I had this with two faders and got it fixed by reflowing a few joints but after mounting the panels, fader 6 is misbehaving again…
Would be cool if somebody could point me towards specific things to check.

@marcus_fischer did you get the TRS to work eventually? Sounds a lot like my situation…

define “above a certain value” - like, at 2, or pegged at 30-ish? if it never goes beyond a certain point, that could be an issue with the voltage divider. so: check the resistors and op-amp for that fader. (there are eight opamps, and sixteen faders: left to right, each opamp handles two faders.)

and, as ever, check the multiplexer.

The value stays around 60% of the fader once you travelled beyond that level. If you then move down the fader, the value doesn’t follow to zero anymore, just resides there.
Thanks for the pointers, I will try again. I had the issue fixed once, as this was a symptom of fader 6 and 7, after adding the panels, I checked again and the issue is back for fader 6. It is my first smd project but it did not feel that bad to me. Built a lot of through hole stuff by now, my guess is that adding the screws adds some tension that breaks my soldering… well, I will reflow these things again I guess. Thanks for answering, Tom!

You may be on to something here.

If the panel has some bend, it could flex the pcb slightly when screws are fully tightened.

Easy to test - try with screws loosened, top panel removed, etc.

I will try soldering with top panel only removed first for sure!
Unfortunately my Pushermanproductions panels came with m3 drillings, but I use 2.5 standoffs and screws with washers sandwhiched around the drillings to work around that, I haven’t tried if 3.0 standoffs would actually work…

I’ve not tried the TRS yet.
My midi over usb is still not working :sob:

I reflowed a good part of my non suspicious looking smd stuff without a dice, fader still misbehaving. Turns out, reflowing my poor looking work on the fader solved the issue.
(Feeling slightly paranoid it will misbehave again in a few days…)