#1

hello allllll,

I’m looking into the possibility of implementing a monome compatible I2C connection for our own (open source) hardware design/s.

Where would you recommend looking for documentation? Unfortunately II is not a great search term.

On monome.org I’ve managed to locate a document on retrofitting 2x3 headers and a mention somewhere in the aleph docs:
“we plan on co-designing with anyone interested. it is a 3.5mm stereo jack (for easy cabling) that uses the i2c bus.”

Here on the forum there’s at least one incredibly long thread that probably has a lot of useful information, but nothing as straightforward as a pin-out, pull-up specification or protocol definition. Same on the O|D forum.

Help please!

3 Likes
#2

great to hear you are considering this!

i’ll be happy to help with the protocol, for hardware side of things take a look at telex and faderbank repositories (both are teensy based devices that can communicate with teletype via i2c):


1 Like
#3

i havent posted anything about it but im in the process of developing several i2c capable modules including an 8 input switch matrix that accesses i2c bus addresses. check out those projects above ^^ also I found reading the ansible and teletype and aleph i2c code incredibly helpful

6 Likes
#4

cool thanks!

Am I right in thinking that in these configurations, the Teletype or Aleph is the master and the others are all slave devices?

How would you go about setting up a device that can be either master or slave?

1 Like
#6

I was thinking about something perhaps a bit easier: a jumper to set the pull ups, and software configuration for master / slave mode.

Looking at the TELEXi, there are no pull ups - are they on the Teensy board or on the master device, or both?

Another question: does there exist a pin-out for 3.5mm TRS jacks?

#7

oh and why are there two rows of 3-pin connectors??

#8

Same reason there’s two rows of power pins :wink:

But really I’m guessing it’s for physical stability: increased pull-out force and stiffer against bending.

#9

16n and TXB uses tip as SDA, ring as SCL. I think that might also be the same as Aleph.

#10

This sounds about right. 16n requires you to flash it to behave how you’d like - its integration with ER-301 requires 16n to be the master, but its integration with TXB/Teletype requires Teletype to be master. If I was thinking sharper I might have done something with pullups, but we have exposed USB and the kind of people who’d want to change that are probably OK with flashing a Teensy.

A user's guide to i2c
#11

Eurorack power pins are doubled up (or sextupled up with gnd) to provide better current capacity.
It would have been nice to have cables and connectors designed for power instead, but, oh, well.

I still don’t know what the pull ups are meant to be for the master device - I’m assuming none for slaves.
Is the Teletype schematic available somewhere? Aleph? I’m searching, not finding.

#12

I don’t think any individual devices in the II ecosystem have their own pull-ups. Look at the I2C “backpack” for Teletype, which I believe adds the pull-ups needed for multi-device connections. Doubling up on pull-ups probably would not add any benefits.

I was being flippant about the power headers and forgot to consider the electrical benefits. But I believe the benefits are mostly reduced contact resistance rather than increased ampacity. Very few euro devices draw an amount of power which would challenge the ampacity of the ribbon cables.

#13

pins don’t need to be doubled, but it can be used to chain link several devices.

iirc teletype has pull-ups but they are disabled (@tehn would know for sure).

teletype is a master and currently won’t work if there is another master on the bus (won’t work as in: freeze completely). hopefully something we can change in the future.

#14

Where can I find this, please?

Well there must be some, somewhere, or the bus won’t work!
Even if there are only two devices connected, it is still a bus.

#15

Teletype has 10k pullup resistors. The reason for the powered busboard (ie “backpack”) is that this 10k resistance is too high when adding multiple devices to the chain.

If you are designing a master-capable device I’d suggest pull-ups in the 3k3 to 5k range. Having them switchable would be nice to avoid too many parallel devices (leading to too much current draw on the bus), but in practice I’d say it’s fine so long as there’s not 5+ devices all with their own pullups.

Regarding the TRS jack implementation, the main thing to keep in mind is it’s not a good candidate for ‘hot-swapping’ due to the sequential signal mismatch on plug/unplug, ie. Tip is shorted to ground momentarily, then Ring, then finally arrives at Tip. This could cause corruption of the data line, though the protocol could be updated to gracefully handle this situation.

3 Likes
#16

that’s great info, thanks @Galapagoose!

Based on this I’d be tempted to put 10k resistors in. Then it will work with anything Teletype works with, plus it could be a slave to Teletype, bringing the combined pull-up resistance down to 5k. Though jumpers or switched resistors would probably be even better.

1 Like
#17

to confirm, the latest teletype master still has tt pull ups disabled:

#18

Impossible to say what that means without the schematic. Internal pull ups are typically in the 30-40k range. @Galapagoose mentioned 10k - external?

Let’s be clear: if there are no pull ups then there is no i2c bus.

With different devices from different manufacturers implementing the same open source bus protocol it would be pretty weird if this isn’t documented somewhere.

@tehn do you mind shedding some light?

#19

Yes, I will note that 16n has DO NOT HOT PLUG written in large letters by that jack.

#20

TT has 10k external pullups.

the tt powered busboards (also made by @bpcmusic) have 2.2k resistors pulled up to 3v3. effective pullup is just under/around 2k, allowing many many devices.

configurable pullup is a major design challenge for this ecosystem to move forward. i’ve tried to tackle this in earnest (exploring device isolation/etc, i2c hotswap chips (they exist), and assessed nearly every physical connector for i2c suitability).

ps. i plan on releasing the TT schems once i get a minute to clean them up :slightly_smiling_face:

also @Galapagoose has close knowledge of TT, he helped make it happen (when he was on-the-books part of monome)

3 Likes
#21

Thanks @tehn, that’s good to know.
As for the message syntax and semantics I am guessing I will find it in the source.
Friendly word of advice, though, if you want others to take this up then a page or two of documentation wouldn’t go amiss!