32 byte inbound message for TRS-specific options: 16 bytes of channels, 16 bytes of CCs.

Note that this data is not contiguous inside EEPROM, so will need two write passes on the device firmware.

I've replaced a broken 3.2 in my 16n with an LC. The V2.1.0 firmware loads successfully and sends MIDI as expected. However, it won't connect to the web editor. I've checked with Ableton and the device comes up as "Teensy MIDI", not "16n."

I then flashing the V2.0.1 which does show up in the web editor, however the first fader won't work. Checking the device name in Ableton correctly displays "16n."

Any help would be greatly appreciated!

Just in case people want to change the i2c address, it would be way easier to have that as a DEFINE in config.h instead of hardcoded in Wire.begin()

Is it technically possible to have multiple faderbanks on the same I2C bus ? I'm wondering if it has already been tested.

Out of curiosity I tried to add an offset here but of course, it doesn't work :-) And I realize that teletype/src/ops/fader.c would probably need a modification, too.

    // map and update the value 
    noInterrupts();
    currentValue[i] = temp;
    interrupts();

Thanks.

Someone brought up that their device is sending CC values over 124 and I checked several devices here and some do some do some dont. Its persistent over all the faders for given device. 5V is good in all cases..

Hello -- I recently purchased a used 16n on Reverb. I just updated to the latest firmware, all good. In the web editor, fader 1 is controlling all of the other fader values, and the other faders do nothing. So in the editor display, when I push up the first fader, I see all 16 move up to 127.

Any suggestions or help? I don't know who assembled this unit, unfortunately. I am also totally not a programmer, just a musician trying to do cool things with this great system.

thank you!

I'm experiencing issues with the I2C connection. I'm testing the connection with a Teletype, when polled, it always returns 0. (See "Context" below). According to the Serial Monitor, the 16n doesn’t receive anything.

I'm not sure wether it's related to hardware or software. If it's related to the hardware, the only change I made is replacing the 1N4148W-7-F diodes by 1N4148WQ-7-F diodes. The specs are nearly identical but the Q-7-F have a reverse current of 50uF instead of 1uF for the 7-F.
Could this be the cause of the issue ?

Context:

• Teletype (old hardware, not the latest revision) Firmware number -> 25E14EE
• TT busboard.
• 16nFaderbank in slave mode
• 16n connected to the I2C bus through a TXo.
• Total cable length outside + inside the eurorack case: approx. 35cm
• Connectivity between the Teletype and the Teensy tested with a multimeter: OK (Tip: SDA, Ring: SCL, Sleeve: ground. Pins 18 and 19 on the Teensy)
• The firmware of the 16n has not been modified (except for enabling DEBUG in config.h)
• Midi (USB) and CV tested: OK.
  Other I2C devices on the bus:
  Backpack header 1: ER-301
  Backpack header 2: Two TXo + one 16n connected in series.

(Also tested with the 16n directly connected to the TT busboard)

Situation:

• The ER-301 and the TXOs receive messages from the Teletype.
• The 16n in DEBUG mode doesn't receive messages from the Teletype according to the Serial Monitor.
• When polled from the Teletype with FB 1, the result is always 0, same thing for each fader.
• Midi (USB) and CV work fine. Midi over jack not tested. Master mode not tested as it would require placing the pull-up resistors etc, but I can do it if necessary

Thanks.

small confusion...

ii.h has 4 ansible addresses listed - and none of those match the ansible address in the 16n code

ii.h:

#define II_ANSIBLE_ADDR     0x20
#define II_ANSIBLE_ADDR_2   0x21
#define II_ANSIBLE_ADDR_3   0x22
#define II_ANSIBLE_ADDR_4   0x23

16n:

      // ANSIBLE
      sendi2c(0xA0, device << 1, 0x06, port, notShiftyTemp);

Build a fader bank from GitHub files. Printed PCB though manufacturer, soldered all components. Used firmware instructions and most current release. Not being recognized in the config tool. Am I missing something?

The i2C address 0xB0 is no longer used by the ER-301.

      // ER-301
      sendi2c(0xB0, 0, 0x11, q, notShiftyTemp);

The new address should be 0x31 or 0x32 or 0x33

  // ER-301
  sendi2c(0x31, 0, 0x11, q, notShiftyTemp);

One of the main characteristics of the 16n is that (obviously) all the output signals are simultaneous; this makes the 16n a controller and nothing more.

What would happen if the output signals (at least MIDI out) were sequential at regular clock intervals (from MIDI in)? It would become a real sequencer. The sliders could adjust 16 pitches by 16 steps ... or maybe 8 for the pitch and 8 for the velocity.

Daydream or could we really give new life to our beloved faderbank?

this isn't really an Issue, rather an idea.
many Eurorack Modules use + / - 5v control voltages.
Is there a possibility to send negative 5v out?

I am unable to get the 16n to communicate with Ableton live. I also cannot find the device in the editor tool https://16n-faderbank.github.io/editor/ BUT this test page confirms midi is being received https://modularden.co/16n-test/ I am confused. Is the editor broken?

I got 16N via USB to Mac. The Teensy has light that comes on, but nothing is being recognized on computer either using the configurator in Chrome https://16n-faderbank.github.io/editor/. Any troubleshooting recommendations?

Hi,
I tried to connect my faderbank to the editor via Chrome, but it seems it can’t be recognized.
The editor sent this message : "It looks like a 16n is trying to connect, but may have a corrupt memory », and this : "Click to reset your 16n's EEPROM to factory defaults ». I clicked but nothing happens.
Is there a way to resolve this issue ?
Thank you very much.

The 16n plugged via USB is recognized by my Mac but it is not recognized by other MIDI interfaces like Hermod and IconnectMidi 4+ (plugged into their respective "USB hosts" ports) Do you think it can be fixed ?

Hello, I have an error when compiling:
stray '\302' in program

I made 16n and everything is working perfectly.
However, I checked the MIDI values and when I put the fader in the middle, the value is around 50 instead of 63.
Is this the correct behavior?

At first glance it's not obvious which eagle files are the ones to use.

Adding a version number or putting the old (1.26) version in a separate folder would help reduce confusion.

seems that https://github.com/16n-faderbank/16n/blob/master/electronics/bom.csv doesn't say anything about resistance of sliders needed. also, octopart link gives 404.
what is correct slider resistance value ?

The DEVICE_ID inside config.h should be dynamically set dependent on Teensy LC or 3.2.

32 byte inbound message for USB-specific options: 16 bytes of channels, 16 bytes of CCs.

Note that this data is not contiguous inside EEPROM, so will need two write passes on the device firmware.

So I have some pretty sloppy soldering on my board (my first SMD build) and I'm now getting some strange behaviour.

Most of the pots (1-4)seem to work in a range from 0-109
Pot 5 isn't working at all
Pot 6 goes from 0-127 then raises all the other values by 24!
Pot 8 goes from 0-15
Pot 11 and 12 don't work at all.

Should I be suspecting my 805 resister soldering? Is there a technique that works best for these?

Edit: I'm not very hardware savvy and I'm not sure how to read the schematic to track down what the issue might be. Any pointers would be very helpful.

BOM is not specific on value for slide pots.

Mouser lists 2 versions of the RS6011SP600x - RS6011SP6003 (10KOhms) and RS6011SP6004 (20Kohms)

Datasheet says the 10K RS6011SP6003 is 1B taper (linear) so I assume this is the right one. Might be good to update the BOM with that part number?

Is it possible to use motorised sliders that can snap to preset values from the host to give a true value when using the 16n?

Using the Alps faders from the BOM, what is the optimal panel thickness, especially for the top panel?

Hi-

thank you for reading. I’m using the teensy based ,16n faderbank on VCV Rack2, 2015 MacBook Pro, 10.15 OS. After assigning faders and moving sliders, VCV Rack2 crashes. Any suggestions would be welcomed.

Thank you in advance for help.

...and if it is, does that mean cap counts are correct too? Double check.

16 byte inbound message for device options. Good first issues, as those sixteen bytes are contiguous.

Another discrepancy between Octopart BOM and CSV...

The CSV has 6mm M-F standoff, Octopart has 5mm

Should we assume Octopart BOM is correct?

Hi there!

Not sure what the issue could be, but my 16n worked flawlessly with the v134 firmware but is now acting up when installing v201.

I tried installing the hex and compiling it myself. Serial Monitor tells me:

Got an 1nFo request
Sending this data
7D 00 00 0F 02 02 00 01 01 4C 41 43 02 00 00 00 74 00 D9 CB D4 13 5E 2D E7 46 75 60 F8 79 80 93 09 AD 91 C6 19 E0 A1 F9 7F 7F 9A 13 29 2D B2 46 3A 60 CC 79 52 93 DF AC 65 C6 EB DF 76 F9 7F 7F 84 13 09 2D 94 46 18 60 A6 79 2B 93 B1 AC 3D C6 BF DF 43 F9 7F 7F D8 13
Ooh, sysex
F0 7D 00 00 1F F7

Thanks a lot and all the best!

hi all,
apologies if this is a stupid question, but i'm having issues with my teensy.
i'm a kit builder, so the build was nice and straightforward. now "all" i've got to do is shove a bit of code into it.
i've downloaded everything, opened the loader, done the verify (tick) stage, but now i'm stuck.
how do i get the v201 hex file into my teensy??

any help would be much appreciated.

cheers,
ian c.

NOTE: Not a hardware guy, don't know the complexity of this request.

I purchased a 16n from a maker and really liked it. When I asked whether having 100mm faders was possible, they said a PCB redesign would be necessary to implement that.

I'm opening this issue to see the viability of that.

The main desire here is more fine-grained control without a high amount of finger dexterity. With a longer throw range, the resulting values from the faders are more "spread out" and allow those of us with shaky or imprecise fingers to achieve smaller changes.

Hopefully that makes sense.

This changes to channel 2 when running the master firmware. 1.31 does not show this behavior

Please make it possible to output 14-bit midi over USB.

I don't need NRPN, only the "fine adjustment" allready in the conventional MIDI controller specification, where any of the first 32 controls can be paired with a control offset 32 higher. I found an example here:

fixed CC's are OK for me {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15} paired with {32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47}.
I plan on using it with VCV Rack 2

Cheers,
Jens Peter

Ps: I bought the AtoVproject-Reworked - and asked them too.

Hi,

I was thinking that it would be a great addition to the firmware to be able to have the Midi clock transmitted to the MIDI jack when the 16n is connected to a DAW.

This would allow to control parameters in the DAW and a Midi device while maintaining synchronization without the need for extra cables and Midi Thru and all that.

Let me know if that's something you would be willing to implement.

Cheers

Hello,

Since PJRC put a large disclaimer on their website regarding the stock and supply of the NXP chip on Teensy 3.x's & Teensy LC (see: https://www.pjrc.com/store/teensy32.html), I was wondering if anyone has already thought about, or maybe even designed an alternative design using the Teensy 4.x platform.

I would guess this would be possible, since their pinouts and capabilities are almost identical, but I just had not found any information about this yet :)

If anyone has done such thing, please let me know. And if not and I'd decide to do this I'll also share it ofcourse.

Kind regards,
NeusAap

The checks for 'valid memory' only work on 2.1.0+ - and fail on 2.0.0 to 2.1.0. We should assume success, not failure, if we don't get a valid response to the valid-firmware check.

My fader 5 suddenly started to send values from 76 at minimum and 127 at maximum with linearity. The raw value was adjusted from 0 to 7850 so all faders would reach 127, but this behavior seems not to have anything to do with it.

Just updated to 2.1.0 hopping for a bug but it's not the case.

Could it be a bad soldered leg on that fader? I did it myself 2 years ago.
Any troubleshooting ideas would be welcomed!

Hi,
i wonder what functions are critical in the 3.2 that would stop to 4.0 migration ?
Background: I hardly can get a 3.2, but 4.0 seems pin compatible.

It would useful to have the possibility to flip the device, I2C connector on top, midi connector on the left.

In config.h there's an option for the fader numbers #define REV 1 but what is the best way to also invert the values ?

I replaced temp = map(temp, MINFADER, MAXFADER, 0, 16383);
with temp = map(temp, MINFADER, MAXFADER, 16383, 0);

It works but the lowest MIDI value is always 2 or 3. How can I adjust that please ?

Hi,

I´m trying to design a mate for the 16n: the 64n, 3 potentiometers and 1 encoder to match each one of the fader.

How can I figure out what components it will need? Will it work with the Teensy 3.2? I suppose I´d need a small multiplexer for each pot like the 16n has one for each fader but, will the big multiplexer be enough to handle them?

The only outputs it will have are USB and jack for MIDI, no I2C required.

Thanks!

At the moment MIDI and I2C messages are sent as fast as the main loop can.

If a tiny amount of hysteresis was added to the smoothed analog value, messages could be only sent when the sliders are moved. This could make 16n coexist on an i2c bus (as a leader) with multiple leader devices.

Is there any reason why this would be a bad idea? If not, I'm happy to submit a PR to do this.

hi!

are the 2.5 mm screws included on the BOM? i couldn't find them :)

A 16n with v2.0.x firmware starting up for the first time checks its EEPROM to see if it needs to do a factory initialisation. It does this by looking at the first byte of sort-of-EEPROM; if it's not 0xff, it assumes it's already been programmed; otherwise, it fills the EEPROM with default settings.

This is a problem if your Teensy has been used in a previous project, and has a non-0xFF first byte, but the rest of the EEPROM is not really 16n data; that data gets sent as garbage Sysex.

So:

• Add a new sysex receive message that will force a factory reset.
• Add some kind of way of triggering this from the editor tool, or a new endpoint that can handle it.

Panel DXFs have 5.5mm holes at the corners, not 2.5mm.

The 5.5mm is the countersink; the drill should be 2.5mm.

This can be attributed to the DXF being extracted from fusion360 from the wrong side. Needs fixing ASAP.

I'd like to build this, but can't find the ALPS faders listed in the BOM. I'd prefer to have faders with LEDs and found Bourns faders with dimensions and mechanical and electrical characteristics comparable to the ALPS that have LEDs in the lever. Has anyone made this substitution? Is this a straightforward replacement, or is there some other factors I need to consider or adjustments I need to make?

Thanks in advance for any advice.

As seen here:
https://llllllll.co/t/16n-is-a-bank-of-faders-release-thread-current-version-1-31/18620/118

I’m having problems compiling the code. 1.8.8/1.45 on win10 64bit.
_16n_faderbank_firmware:27: error: expected constructor, destructor, or type conversion before ‘;’ token MIDI_CREATE_DEFAULT_INSTANCE();

Hello,

First of all, sorry for posting there but I've been reaching Michigan Synth Work for my issue with 0 answers from them (my 16n was built by them).

I use the 16n faderbank mostly for the CV outputs and recently realized these were not going to full 5V. (I have to slightly offset the value with another module to reach a 100% wet value) The problem is: I don't own 16 offsets and it's getting a big issue for me! I already tried other USB cables/power sources thinking it could be the problem, but they all give the same results so this is probably not the issue.

Is there any workaround/solution for this? Thanks!