16n Faderbank Minimum Fader Value Issue

Hey all,

I’ve noticed for example, if I assign a fader to the wet/dry mix of a unit and adjust the Gain setting to 1; the fader moves to the max of 1 but it doesn’t go completely to zero so some wet signal still leaks through. If I add an offset object of -0.1 after the SC.CV, it works perfect. It’s not just with the wet/dry mix; I just used that as an example.

Does anyone else have this issue? Is there some calibration/firmware tweak needed on the16n or is there something not quite right here? I can’t check via the new 16n firmware editor as it only reads the USB outs in realtime and not the TRS (which feeds the I2C that I use).
It’s great I can at least use an offset object but it’d be nice to have to do this for every fader setting.


On mine I haven’t really noticed anything at the low end (zero seems to be zero) but I do notice reading the fader values on Teletype that the high end values aren’t always consistent from fader to fader.

I’m not sure if there’s a way to calibrate in the firmware or not - haven’t really gotten that deep into it.

One thing you could do is to create a global chain for each fader with the offset already set up correctly for each one. Then just tap the global chains in your patch where you want to control with the 16n. Basically set up a reusable configuration. Could save those global chains as a quicksave for easy recall.

1 Like

Thanks Joe. That could be a good solution and a good use of the global chains as I’d only have to load the global if I was using my 16n with the patch.

There is a manual calibration you can do in the firmware configurator but it’s only reading the USB out which is reading accurately and not the trs. Might go with the Global idea and see how that goes for now.

If anyone has this issue or other solutions, please let me know. :slight_smile:

Hmm, I just built a Global Chain for the 16n but it pulls close to 14% of the CPU. Seems on the heavy side. I guess all those offsets add up. Dang.

ps. I suppose I could have one global Offset for all the faders to access too. I’m back to adding 2 objects per assignment again so not ideal but I guess it saves on CPU. :thinking:

pps. And I just worked out that you can only have one global assignment per input. Double dang.

According to the awesome work @a773 did here:

16 x (SC.CV + Offset) should only cost you around 5.5% CPU.

Those global chain class instances carry some overhead of their own, I’m sure. Not sure I’d have guessed quite that much, but I guess it is what it is.

Ok, I’m slowly tracking down the source but I’m very curious if anyone else has similar issue.

I’ve noticed the 16n is susceptible to voltage fluctuations which is possibly why the offsets are necessary. I usually power my 16n via an Intellijel USB power tile in my rig but I noticed when I power the 16n from my laptop port, the voltage output is greater on the 16n. Also the LED on the 16n interferes slightly with the voltage also which I have now turned off via the firmware.

Maybe I’d be better off posting about this on some 16n Faderbank DIY forum. :thinking:

  • can confirm this phenomenon with both an older 16n from msg and the sweet sixteen from Tesseract.
  • @Joe’s ‘workaround’ is more than just a workaround for me. Thanks…
  • edit: not sure, but I had the impression that the residual value is far less with the sweet sixteen. I only get 0.001 with a quick check.
  • I do remember that the 16n might have had different results with different cable lengths…
  • at some point I might investigate this more thoroughly…
1 Like

Thanks for confirming @mopoco At least I know there’s not an issue with my build. Such a bugger that they’re not very accurate. Great for general things but not for subtle tweaks/preset designs. I was also hoping to share an instrument I’ve been designing in the ER-301 along with the Faderbank setup but this won’t work due to the voltage irregularities.

I’ll try a different cable too but it looks like you choose your ‘poison’ and set it to that. One other issue was even when moving other faders up or down can tend to bump the voltage on another fader. Not that noticeable until you’re in the higher frequencies/FM and then it’s really obvious.

I guess it’s highly possible the Sweet 16 is more accurate as it’d be running off of euro power as opposed to USB which is much sketchier. Mind you, euro power isn’t the most stable in the world either! haha.

Let me know if you dig in further and thanks for the above info. Appreciated!

First of all, this ‘issue’ won’t excuse you from sharing your instrument!
And when you share you might want to note this dependency…
Second, like you said, it depends pretty much on the application how severe the effects will weigh. E.g. applied to the cutoff frequency of a
Filter should be negligible for most use cases. Though with fm duties it might get obvious we might find workarounds for those use cases where precision gets crucial for results (thinking of rational vca and quantization…)
Also dreaming of some kind of auto calibration for i2c inputs.
Maybe @M4ngu can shed some light on this, or @odevices

Hi guys, in the firmware there’s a part which is conceived to deal with the tolerance of the faders & circuit, it’s the same setting for all faders btw:

// minimum and maximum values for faders (to deal with tolerances)
#define MINFADER 10 //  original 16n value 15
#define MAXFADER 8160 // original 16n value 8135

I’ve modified the default values to fit my measurements and improve the resolution, anyway placing a higher value for MINFADER will ensure that the module will recognise as zero the lowest position of the fader, also lower values for MAXFADER will make reading the upper position correctly too. With MIN set to 50 and MAX to 8100 you’re loosing less than 2% of the fader’s resolution and should solve the issue with a good margin I think.
Also the new firmware for the 16n (not officially released yet) which is of course compatible with the Sweet Sixteen, has a calibration method using a web application, among other nice features.
I haven’t tested so can’t give more details about the procedure.
Anyway this is in the controller side, what the ER-301 or other i2C device does with that data it’s other history.
Hope this helps.


absolutely! thanks @M4ngu!

1 Like

Thanks. Will definitely try tomorrow. I was wondering if those settings were going to make a difference or not. I didn’t want to adjust those initially as it said it wasn’t recommended so thanks for the settings suggestion. Will report back tomorrow. :+1:


Hello! I just pulled the trigger on the Tesseract Modular Sweet Sixteen (will be here in a month or so) and was wondering about yours or anyone else’s experience with using it with the 301 (no TeleType here).

Asked Mangu Diaz directly about using the Sweet Sixteen with the 301 and what might be required of me referring to this thread but he said he doesn’t own one so he said he couldn’t be of much help :man_shrugging:t2:

Thanks for any advice or suggestions in advance. Hope everyone is staying safe and healthy with plenty of time to use those machines at least!

Please, take a look at these threads…

I’ve noticed this exact issue too, did you find a solution in the end!?

Same issue here. I have to use a negative offset. Btw I am using a reversed 16n.

No I didn’t unfortunately. It’s been quite a while since I’ve tried fixing this issue but from memory, I did try adjusting the fader values with the web app but it didn’t seem to help so I just stuck with adding that small offset within the ER-301. Not ideal but it does work fine as long as you’re not powering the 16n in different ways. I always power via a 1U usb tile within my modular.

It’s mostly a bummer if you’re building big instrument/device in the ER-301 and you have to waste precious space with multiple offsets.

My 16n is also reverved. I’m assuming that wouldn’t make a difference??

Is yours reversed as well @Glydez ?

Do the correction once in a global chain then reference the global everywhere instead.

Thanks for this :slight_smile: I use the sweet sixteen (not reversed) and, like you, haven’t been able to solve it any way other than using the offset. It’s not the end of the world really as the offset works great and can easily be saved as a global chain like suggested :+1: