16n Faderbank: build help, dev suggestions

welcome to the gulf that exists between “vertical stack-up of panels+circuitboards put together with standoffs” and “making enclosures”. I have thought about this before!

Because of the current design, any canted option is likely to end up wider than the current version - all the mounting points are at the very corners of the current hardware, so supporting them in a canted frame will require something at the edges; the main hardware will most likely be suspended from the top of the frame, rather than supported from below; then, the top frame will somehow be attached to sides/base separately from the hardware. However - that will put a moderate amount of weight on the eight screws in the top.

The nicest, and slimmest, alternative would be to mill out a piece of aluminium - much like the base of a monome grid - and use that as a support, the angle being built into the milled block. You could then genuinely support the whole thing from underneath, at an angle, and even mill out cable recesses.

That is a really great idea too. Similar to my idea of attaching angled feet under the board, but better. The only stupid issue I have with the board is the teensy placement. Since I use my left hand during writing to ride faders, my hand sits on the left edge and I would expect the cable would get in the way. Such a stupid thing that I am picky about!

Thats a nice idea too! Is it stable? Especially if I sit my left on the device would it stay put or would it tip to the left?

It’s been really stable for me.

How difficult is it to edit the config file to change cc’s and reflash? What do I need to accomplish this?

1 Like

I wrote a guide on flashing a teensy here: How to flash the firmware on a Teensy micro-controller

Otherwise just gotta change things in arduino.

So just finished my faderbank build. Everything is up and running perfectly, except midi on fader 6. I’m using the midi test page in Chrome to verify midi implementation, and it seems to get stuck at half way open (is that the word I’m looking for?). Like when I slide the fader all the way up, the bar in the web page rises all the way to the top, but when I pull the slider down, it comes down just half way, and then stops even though the slider itself continues to slide below/down past the physical halfway point on the actual slider. Where should I be looking? U4 (not sure which pin), and U1 pin 3?

EDIT: So it appears the CV out is also affected on fader 6. The min value I read when the slider is all the way down is 3.0V, and max is 5V. I am double checking all my resistors with a multimeter right now. R6 reads 1kOhm. All R1-R16 read 1kOhm. I did notice something strange though, that the R40 and R26, in fact all resistors that are next to the each of the op-amps measure at 3.6kOhms. All of them do. I thought one set was 10k and the other was 5.6k? R49 and R52 read 47 Ohm, as I would expect. I double checked my order, the package label, the pack list, and the markings on the resistors, and they all indicate they are properly placed and the correct components. Any thoughts?

Lastly, what is the minimum expected CV value when the slider is all the way down. Mostly I read 1.2mV, but two sliders read 2.4mV. Not that those low values will have much of an impact, but is it possible I may have missed something there too?

Thanks in advance!

EDIT: Aaaah, got it! I was so focused on the SMT components I didn’t think to look at the pins on the back of the board. One of the pins on fader 6 wasn’t soldered! That’ll do it.

2 Likes

What is the consensus with the pull-up value for ER301 connection?

Ive seen 4k7 and 10k mentioned. The Teletype busboard pullups are 2k2, so thats where I would have started.

EDIT:
So I did some research.
image

Assuming Vcc is the I2C voltage of 3V3, the minimum pullup value is 967 ohm.

http://dsscircuits.com/articles/effects-of-varying-i2c-pull-up-resistors
This article shows the effect of varying i2c pullup resistors. They suggest that with a 400 kHz clock, values above 4K7 were causing the frequency to be read unreliably by the scope. As the rise time = R*C, as more devices are added to the bus and capacitance increased, the resistance will have to decrease to compensate.

So for a faderbank controlling an ER301 directly, 1K5-4K7 ohm is probably fine. 10k may work but the higher resistance, the worse the rise time of the clock pulse.

On a device with pullups designed to operate with many devices, like the Teletype I2C busboard, the capacitance will be higher, and as such the resistance must be lower to ensure the clock pulses have a sharp edge. Potentially why the TT busboard has 2K2 pullups.

Thought I’d share the info I had found in case anyone has a similar query in the future.

1 Like

Hey, I’m posting this here for information:

Today I had to create a MIDI merger using a Raspberry Zero but when I tried to connect the 16n and a couple of other devices, for some reason it was impossible to connect the 16n faderbank using its actual midi device name « 16n »

The usual command : aconnect 16n:0 mio:0 (even with ´´ ) was not working. I had to modify the name of the midi device in usb_name.c to « fader » and recompile and that worked.

Just FYI in case this happens to somebody else.

#include <usb_names.h>

#define PRODUCT_NAME \
  {                  \
    'f', 'a', 'd', 'e', 'r'    \
  }
#define PRODUCT_NAME_LEN 5

struct usb_string_descriptor_struct usb_string_product_name = {
    2 + PRODUCT_NAME_LEN * 2,
    3,
    PRODUCT_NAME};

I thought that would also fix the issue of the 16n not recognized by Hermod, but it’s not, that’s another problem :wink:

Cheers,

Ps: I guess ´aconnect ´ doesn’t like devices names starting with numbers or something like that ^^

1 Like

Hi !
I want to build a 16n especiallly for i2c with a teletype and er-301.
So I don’t need midi out jack and the 16’s cv jacks out.
But maybe I don’t need to solder other components (resistor ? Multiplexers ?)
Maybe I need a special pcb for that ?
What do you think about my idea ?

when i built my 16n i didn’t bother with the 16 cv jacks out. I also didn’t bother spending more time thinking about which other components could be forgone !

I have something going on with my midi out over TRS. I was hoping to use both the faderbank and the Zoia together, but something is not working and I am having a hard time tracing the problem. I have tested multiple midi devices into the Zoia using the trs midi in, everything works. Set the channels appropriately, all midi notes and cc’s look good. I also used the 16n faderbank and tested the connection on the chrome page, and with a Midi Monitor to see what was happening in real time. As expected, channel one spit out cc’s on 32-47 over usb. When I connect the Zoia and Faderbank, I set midi channel to 1 on the Zoia, and my faderbank is confirmed to be on channel one by the midi monitor. I use a midi cc in module and set any cc 32-47. I move the associated slider, and nothing. I’ve gone through multiple trs cables, I’ve tested on both tip out and ring out settings on the faderbank. I’ve also tried midi cc in by way of the control port on the Zoia and making sure the control port settings are for midi data on channel 1. I’m starting to think it’s something I’ve done on the faderbank, but don’t know what to check next.

The 16n TRS midi jack is different/separate from usbmidi - so you would really want to find a way to test midi out from the TRS jack to be sure it’s working properly.

I was able to test out midi TRS out on the faderbank to a Beatstep Pro. This worked with TRS midi from Zoia, but not with the faderbank. I believe I can now confirm my faderbank TRS midi out is the source of the problem. I’m not sure where or how to trace my connections for this or what I should be looking for.

I’ve re-flowed the midi jack to the board, and those connections are looking good, but still no luck. Are there connections from the Teensy to the midi jack I should be investigating?

Any ideas or pointers?

Thanks!

Can you post a picture of the bottle right portion of the board near the midi jack?

Here are screen grabs of the relevant bits of the pcb and things to check

  • Check to be sure the switch is soldered properly and not bridged.
  • be sure you don’t have any shorts in the 3.3v line going to the diodes
  • Make sure R49 and R52 are in the right orientation

Here are some of the images. I’ll test the 3.3v line going to the diodes today also. R49 and R52 confirmed orientation. As far as I can tell, my switch doesn’t look like it has any bridges, but let me know if you spot anything that looks funny.

I’ll report back on the once I get some multimeter measurements.

(P.S. switch is currently set to K, though I had it set to A while testing with the BSP)

Looks correct in your picture, but might as well confirm…
Did you use 47R (47 ohm) or 47K (47Kohm)? (They should be 47R)

There’s not really much that can go wrong here. Double check those highlighted solder points on the teensy, check for shorts on 3.3v, check for 3.3v on the left side of R52.

1 Like

iiiinteresting. perhaps we should change the default name of the device. I can certainly update some docs to describe this.

1 Like

Well, have you looked at the schematics and code, which would give you the answer you need?

Spoilers: nope, you need almost all the components on the board. You can skip two resistors, the switch, and the midi jack if you don’t want jack midi, and there are sixteen resistors you can skip if you skip the CV jacks.

The mux, the opamps, and the remaining resistors are all necessary to get the correct analog voltages into the Teensy, which then emits your I2C.

I would not recommend randomly removing components from a board if you’re not sure whether you need them or not. The whole thing will work fine with jack sockets removed… but why would you remove the others?

1 Like

Been meaning to thow this one up for a while. A small 3D printed part that friction fits between the Teensy USB port and the panel. Hopefully lessening the impact of any upward force that would otherwise rip off the USB port when dropped/mishandled

2 Likes