I2C questions / discussions

Was just curious, has anyone worked on a 1u i2c trs on the front, 3/6 pin on the back adapter? Considering adding a 16n to my setup but have nearly maxed out space in my case and just have a bit of 1u space left

Hi peeps,

Now that i want to use i2c, I see i dont have the i2c header on the white whale.

I have been looking everywhere to find some information about how and where to install the header on the white whale. But found nothing.

Can somebody post a picture,of the back of a WW with the i2c header?


1 Like

Thank you very much 20 characters

Is the alternative orca firmware for WW also compatible with i2c?

yeah it can respond to i2c commands from teletype (see full list here) but it doesn’t sequence i2c followers, if that’s what you meant.

all good info thanks, yes I understood that the WW is a follower and can’t therefore not send but just receive from TT for example.

to be more precise, WW module can be either a leader or a follower, depending on the firmware it’s running (if you use it with polyearthsea or orca’s heart firmware, for instance, it will work as a leader). WW firmware only supports being a follower.

OK, have to check what the commands are then to use ORCA and polyES as a leader. I thought only TT could make commands. Maybe TT is to be used as interconnection . Have to check what I find in the ORCA doc from TT

make sure to check this thread, it has detailed explanations: A user's guide to i2c

basically, there are several devices/firmwares that can act as i2c leaders. each one will have different hardware requirements (see the thread above) and might require additional configuration (described in their respective manuals).

(and specifically, you don’t need to use TT as interconnection but you might need something to provide bus power and pullup resistors, the thread above has the details. also, orca and orca’s heart are different firmwares, the former is a follower, the latter is a leader).

I drilled out a hole to install a 3.5mm trs jack on the back of my case specifically for my 16n connection. But I didn’t add any pins, it’s just the 3 wires soldered to the jack with female headers at the other end. It works great and I just run the I2c cables to my TT back back directly.


Trying to convert (usb)Midi to i2c via arduino to the ER-301
sending triggers works fine:

  Wire.beginTransmission(0x31); // begin transmission to er-301 (0x31)
  Wire.write(0x05); // send pulse
  Wire.write(3); // to channel 4

But cant get CV to work, this is the code i tried:

  Wire.beginTransmission(0x31); // begin transmission to er 301 (0x31)
  Wire.write(0x10);  //  cv
  Wire.write(x);  // value?
  Wire.write(x);  // channel?

to send a CV to ER-301 use:

0x11 I H L

where I is the channel index (0 based) and H/L are the high and low byte of the value you want to send (the value is signed int16).

0x10 will also set CV but with slewing applied (if slewing was set to a non zero value).

some examples available here: https://github.com/scanner-darkly/teletype/wiki/II-protocol#er-301


Working good now, thx!

1 Like

Hey. I’m trying to connect ansible (running 2.0 firmware), and a 16n to my ER-301 via a TT busboard jr. The 16n is working nicely but not the ansible.

Any suggestions?

The stock Ansible firmware currently only acts as a follower I2C device. Ways to use Ansible as an I2C leader include Multipass apps (Polyearthsea / Orca’s Heart) and the leader mode features in the beta firmware. Configuring leader mode in the beta is described here.

1 Like

Thanks very much @csboling. So the beta firmware allows for enabling leader mode?

Has anyone explored/hacked i2c on norns recently?

⠃▋⡇ ~$ i2cdetect -l
i2c-1   i2c             bcm2835 I2C adapter                     I2C adapter


⠃▋⡇ ~$ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
⠃▋⡇ ~$


The “UU” code means that I2C address 0x3b is unavailable for user-level access – it’s probably in use by the kernel itself.

And indeed

⠃▋⡇ ~$ i2cdump 1 0x48
No size specified (using byte-data access)
Error: Could not set address to 0x48: Device or resource busy

Just curious :slight_smile:

Thread revival, but this felt like the right place to post:

I found a used Clank case with their Xpsu. This psu has an active i2c busboard. From their site:

Will there be any conflict using a powered bus like this in a TT, ^^, w/, JF, 301, 16n, etc, etc network? It has run stable in my previous case without an additional bus, but this will make cable management a bit neater.

1 Like

I have one of their cases with the xpsu, and my i2c line works fine! I use crow or ansible as leaders.

1 Like

Thanks! I feel I read somewhere it was not recommended to use multiple buffers on the bus, but I don’t know the specifics. Maybe @nonverbalpoetry can chime in, as they know these things quite well?