16n: v2.1.0 firmware release thread

Another Christmas break means time for a small point release of the 16n firmware.

Details and .hex files are over at Github:

This is a minor upgrade to version 2.0.1, and everything new added in 2.x.x (as described in that thread) is still relevant.

This small release adds two new features:

  • soft MIDI Thru option. Once you’ve upgraded your firmware, you’ll be able to toggle this on from the online editor. When enabled, any MIDI data (including clock data) sent to the 16n will be echoed out of the TRS MIDI jack; useful for sending data or clock to other instruments, using your 16n a little like a MIDI interface. Thanks to @AtoV and the Berlin Modular 16n port for their work on this feature!
  • factory initialisation sysex message. Sending an 0x1a to the 16n will force it to reset its EEPROM to factory settings. This will erase any config you have on the device. This is mainly to fix an issue of people re-using old Teensys for 16ns that may already have EEPROM data that would confuse the editor. Now, if the editor can detect a 16n remotely, but can’t read its config, it will offer you the option to force a factory reset remotely. This may be of use if it looks like your new 16n - made using a left-over Teensy 3.2 - isn’t working.

I’ve made .hex files for both regular Teensy 3.2s and Teensy LCs, for 1.3x hardware, and they’re linked in the release. For most people, using the .hex file with Teensy Loader, as detailed in the 16n wiki, is the recommended upgrade path.



Apologies if this is not in the correct location but the other thread seemed to include Feature Requests so I assumed this was an alright place for one.

It’d be really useful for me to have MIN/MAX CC values per-channel. The use-case is for something like the Octatrack - where the Volume of the Amplifier VCA goes from -64 to +63, with “no gain” being 0). I just tested this with the 2.0.1 firmware and 0-127 comes out to the full-swing of the the parameter, while I would bet that a 0-63 range would go from -64 to 0.

Currently I’m using the 16n for the the Track Levels - which works but my understanding of the signal path is that means it’s post-FX slots - where as controlling the VCA would be pre-FX, which may be ideal.


I have a Berlin Modular 16n edition. I updated using the 16n_v210.hex.

I do get invalid midi data out with the type B trs connector from the Beatstep Pro. When I switch to the Type A trs connector that came with the 0-coast there is no midi data being put out. Do I need to buy a different Type A dongle? (I did toggle the switch between type A and B on the back of the 16n)

iinteresting. so, heads up: I didn’t write the MIDI-Thru code; that was all coded by @AtoV and the Berlin Modular crew. However, that means it should work. There should definitely be no difference between the type-A/B connectors output (in the sense that it’s a straight hardware switcheroo: the right connector + the right mode should just work).

So: could somebody else with a Berlin Modular board, possibly @AtoV themselves, confirm the official 2.1.0 hex works correctly with the MIDI thru setting? I did the barest alteration to their code (namely, sticking it behind an EEPROM-powered feature flag, rather than a bool), but there may have been a mistake in the translation.

1 Like


happy new year to all of you!

The circuitry for the MIDI is the same in the original 16n and my redesign, therefore the firmware is fully cross compatible.

I think Make Noise uses Type A midi connectors therefore the switch should be on the left. (Try both sides in case I’m wrong)

I tested the new release again with 16n with teensy LC and Teensy 3.2 and I had no issue.
Are you sure you get midi data at all?
Do you get signal from the faders?
Make sure the MIDI Thru function is activated in the editor, it’s off by default.

If you don’t get signal out, I’d start by reinstalling the firmware.

If you continue to have issues with MIDI I’d check if R83 and R85 are soldered properly.

Let me know


Hi @AtoV,

It seems that maybe it is a hardware issue? Here you can see output over USB is normal. The strange output is from the Midi Jack with the B style dongle. Zero output from the A style dongle still. I did reinstall the firmware a couple times. Maybe the surface mount parts are backwards?

I’ve just installed this firmware on my 16n and it now I need power it after my 301. The 16n is powered from my case and used to all boot up correctly and connect without needing to unplug and plug the 16n back in. Is there an option to change the boot up time?
Pretty sure I was running an older firmware that had a boot up delay built in.
Thanks in advance :relaxed:

This doesn’t look like a hardware issue as you’d have invalid data if that was the case.

Does this happen when the midi Thru is deactivated?

To me it looks like data if being sent to the 16n USB MIDI, do you have any other program running in the background. Please activate “Spy on output to destination”. Then you’ll see if something is sent to the 16n. If the data being sent to the 16n is sent to the output this means that everything works fine on the 16n side and that the issue is elsewhere.

Let me know

If you are comfortable compiling the firmware yourself, you can uncomment the line 37 in config.h (removing the // )
#define BOOTDELAY 10000

This will delay the start up and give time for your ER301 to boot before the 16n does.

Otherwise send me a PM with your email, I’ll send you a precompiled firmware.

@infovore maybe this can made by default when the 16n is set as i2c Master so that it gives time for slave devices to boot before the 16n. This would make the connection more reliable IMO. If you like the idea, I’ll make PR.


I actually have no idea how to compile a firmware so your help would be awesome!
I’ll pm you :slightly_smiling_face:

Having it set as a default for future firmwares would be a fantastic addition!



When sending midi from Norns the only data received is all invalid. Like this:

Actually, that’s a good idea. It was suggested once that we just delay the boot everywhere, and I wasn’t happy with that. But adding a the slowdown if the faderbank is i2c leader is actually a good idea - it doesn’t affect most users (who are all on i2c follower by default), and if you care enough about i2c to have your faders as leader, you won’t mind the 10s bootup delay.

I think that’s a good idea?


Hi @jasper_ryder

To be honest I’m really confused by your issue, I have been testing the firmware again and could not fault it. I tried sending any kind of midi data at once and compared what was sent and received as well as measured delay and there was no issue at all, no invalid data nor dropouts. I even tried with a norns and I’ve had no issues.

The first few screenshots you sent me shows that midi is going through properly. I see that some messages are repeated, I only had this when I had some unwanted midi loop

Do you mind trying to fix this problem through emails? I’ll come back to the feed and explain the issue when we figure out what is happening.


Looking for any suggestions as to what might be causing an issue i’m having. I have a Sweet Sixteen mkI and am having trouble changing my config settings using the online web editor.

I can connect to the editor no problem and shows connected with the firmware version displayed top right. Move a fader on the SS and I see the feedback on screen. When I go to “Edit Config” though, make a few changes then hit “Update Controller” nothing happens.

The SS had an old version of firmware on it when I received it so I immediately updated to ver 2.1.0 so I could configure it with the online editor. The first time I connected to the online editor everything worked fine and I was able to edit and save my changes without any issues.

I then noticed that the fader midi cc values were reversed, meaning fully down were showing a CC value of 127 and fully up a CC value of 0. Found a post here with someone that had the same issue and downloaded and installed a different firmware version to hopefully correct the fader issue:

Now no matter what version firmware I have loaded onto the SS I am unable to make and changes using the editor and the different firmware version above did not even fix the fader midi CC value issue.

So I am stuck and hoping someone might come across this post and have some insight or suggestions.
Thank you!

Hmmmmn. It’s strange that it’s not saving any values at all. Question: if you open the console - View Menu → Developer → Javascript Console - do you see any red errors, and if so, what?

Is the SS running with a Teensy 3.2 or an LC on the back? Either should work, I think, I added support for the LCs a while back, but there was an issue with LCs receiving sysex data.

Do you have any other MIDI devices connected to your computer? I’m afraid I don’t know about SS-specific issues such as reversed faders, as I have limited knowledge of that device.

Sorry for the delayed response and I just had a chance to open console while connected to the web editor.

Yes, when I hit “update controller” I get these errors in the console view:
Screen Shot 2021-02-18 at 10.16.18 AM

The SS is running a Teensy 3.2 I believe (edit:confirmed). What is the best way to confirm that though?

No other midi devices are connected to my computer when the SS is connected to the online editor.

Edit: I figured out how to clear the EEPROM and can connect again to the editor without issue.
Now just to sort out how to get the fader midi cc value behavior reversed!

Edit: My issue has been solved by erasing the eeprom on the teensy, then loading firmware version 2.0.1.

I can connect the web editor now and make changes to the SS configuration.
Note that if the fader midi CC values are reversed on the SS to enable “Rotate Faders 180 dergress” in the “Device Options” tab in the editor.


1 Like

Hi all, I just acquired a Sweet Sixteen and am setting it up.

@bc3 's fix worked for getting 2.1 to properly install (thanks!) and now the web editor sees the hardware, and can update its config (changes persist through power cycles and disconnections) but none of the fader positions are being read, either by the web editor or Crow via ii.faders.get(x).

Any thoughts? Thank you.

edit: The analog outputs are working fine for attenuation and offset, as are the LEDS.

@zbs I recently went through some trouble shooting with a new Sweet Sixteen. I had to use the firmware from Mangu’s github instead of the one for the 16n. I too had updated via the 16n firmware and it made some of my faders non responsive. I ended up having to flash a different version from Mangu’s github via the arduino IDE and not the teensy loader. Its just called Sweet_Mkii, not the 2.01 he has. This fixed the issues. I have yet to fully upgrade to 2.1 because I got it working and life got in the way. But hopefully this might save you some time in your trouble shooting.


Thanks for the reply! I have tried this and am now running into the “It looks like a 16n is trying to connect, but may have a corrupt memory.” error on the web editor. Oh well, progress is progress. Will update my post if I find a fix. If anyone has any ideas, let me know.

1 Like

These are the steps that got my SS working with the online editor.

  1. Erase the teensy EEPROM: EEPROM Clear ~ Arduino Tutorial
  2. Install the 2.0.1 firmware: _16n_faderbank_firmware.ino.TEENSY32.hex (93.6 KB)
  3. You should be able to connect to the web editor now. If so, there is an option when you are editing the configuration to “rotate controller 180 degrees” which should be selected. This should correct the reversed faders.

Hope this helps and Mangu from Tesseract Modular was very helpful when I was troubleshooting the issue. Email him if you are still having issues and I’m sure he can provide further assistance.