#25

OK, i see the by design UART ports are used for I2C and need a little hardware fix.
I would suggest to directly use UART instead of I2C then to avoid the fix and soldering. For the NerdSEQ the communication port doesn’t matter. All is possible.

1 Like
#26

No, that wasn’t by design. After the ER-301 came out, Monome approached me about supporting i2c control from the Teletype but at the time the ER-301 only had a UART port, hence the hardware hack to get one. However, from the next board revision onward, I now provide a dedicated i2c port. Only users with the older board revision need perform the hardware modification on the UART port to get a working i2c port.

I believe i2c was chosen because it is an addressable bus rather than point-to-point. This way you can support multiple devices (i.e. modules) on the same i2c bus, something that happens all the time in the Teletype ecology.

As for the protocol, I believe there are 2 main options?

Option 1: Make a digital bridge just for the NerdSeq and the ER-301.
Option 2: Join the Monome/Teletype i2c ecology. https://llllllll.co/t/teletype-i2c-protocol/13642

Personally, I think option 2 is the more interesting option because there is a very strong community of developers and users there already. Unfortunately, I’m not aware of a coherent set of technical documentation for the Teletype i2c implementation (help?). When I was implementing the i2c client stack for the ER-301, I mostly ended up looking at the Teletype and bpcmusic/telex source code on GitHub as a guideline. The protocol is very simple though and consists of just raw i2c messages of (field,value) pairs.

If we do go with option 2, then you probably should have a discussion with Brian Crabtree over at Monome (his username is tehn on the lines forum).

6 Likes
#27

I’m not the person to talk to about the technical stuff at all. but to shed some light, I share some insights as I have various of these modules connected together.

As mentioned already, the monome(ish) i2c ecosystem grew around the monome teletype module. teletype (tt) is in the “official” monome implemention the only module that acts as a master, all the rest are slaves (at lines people prefer the terminology leader/follower, for reasons of the cruel connotation of the former). the current implementation of the i2c bus doesn’t really handle having multiple leaders on the same bus. though recently there have been community projects (poly earthsea & faderbank) which allows leader functionality for other modules/devices too. it has been reported that it can even coexist well with teletype on the same i2c bus.

The quickest thing to do from the nerdseq point of view would to send the same er301 relevant messages to the bus as the teletype command SC.TR and SC.CV do, each on channels 1-100(iirc).

As an owner of various monome and mannequins modules (just friends and w/ also respond to tt commands), I’m intrigued to think about the possibilities if the nerdseq could talk to all of them. but the commands are, unlike the er301 ones, very specific to the sequencers/functionality of the various modules, each having their set of specific commands they understand. of course I would love to think about scrolling through all possible endpoints and commands on the nerdseq! but the one with the best ROI I believe is supporting the er301, as it’s so flexible. another very interesting one would be mannequins just friends, as it can act as 6 individual voices via i2c. maybe it makes more sense to support all tt i2c devices/commands after all for consistency? or having a config on the sd card which can be adapted at need? just thinking out loud here.

I’m sure tehn or others over at lines will be glad to help with questions. I’d hoped @scanner_darkly could chime in, the author of poly earthsea and other firmware goodness in the ecosystem. or @bpcmusic, the creator of the tt expanders (telex) .

Last but not least, thank you so much for even considering doing this! I bet you would make a lot of people very happy. definitely me.

(and huge thanks to @tekzon for initiating this!)

forgot: would be happy to help with testing of course

4 Likes
#28

as somebody who’s been watching nerdseq with great interest (an old tracker user here) i’ll be happy to help. i agree with @odevices that option 2 will allow for more possibilities (like using telexo or faderbank with nerdseq as an example). and yeah the protocol is super simple: address (device specific), followed by a command and parameters (different length for different commands). leaders can also poll for values. let me put a document together, should have something next week.

one thing to be aware of - teletype provides power to i2c lines. in er-301/nerdseq setup something will need to do this too. @bpcmusic will have txb module soon that can be used for this. more info: https://github.com/scanner-darkly/polyearthsea/wiki/i2c-set-up

5 Likes
#29

pleasure overload

1 Like
#30

Ok i see. The uart one was also only an easy shot. Of course i know about the benefits of I2C.
As for the NerdSEQ, i am going to release expander modules very soon and in the same road i see the connection for the ER-301 (or any other I2C then). So one expander would provide the I2C interconnection then. All expanders are smart devices on their own as well and can so communicate bi-directional with the NerdSEQ. It doesn’t matter then for the I2C expander for being the leader or the follower ( i have to say i hear this for the first time, but all good here).
Normally, the NerdSEQ recognizes the expanders and knows all it’s parameters. I guess i would need another more dynamic way here for I2C followers then (as they are a follower of the follower then). But no problem as i wanted to integrate the dynamic approach anyway for DIY extensions at some point. NerdSEQ can also handle many parameters including type, min/max/range and up to 32 bits values for them with names and abreviations. One work-sensitive part will be, if they are different I2C followers, that all NerdSEQ I2C extensions got their own screen layout in the patterns. While all functions can be accessed, i have the most used functions popular available ( eg Notes, Triggers/Gates, Tables, Patches, Volume etc…). So a connection to ER-301 would also have a specific screen layout (and others would then too). As i got to concentrate also on my own expanders, a still long 2do list for the NerdSEQ, and more products (to survive) i don’t know how far i will go with that. Also the ER-301 implementation is not on top of my current 2do list.
That doesn’t mean that i’m not interrested to make it. I am definitely are, it will just take a while until i get onto it. I don’t even have the ER-301 yet so i don’t know how it works and what implementation would make sense. So thats my first step anyway.
So please don’t be too enthousiastic and expect that i will have all ready within a few weeks (even though it sounds not too hard to do)
To be continued…

6 Likes
#31

Here is a rough proposal to give you a better idea of what is (I think) minimally required.

The ER-301 currently supports only 9 different i2c messages from the Teletype. See the command table listed in here:

http://wiki.orthogonaldevices.com/index.php/ER-301/Teletype_Integration

However, if you implement only these 3 main Teletype commands:

  • SC.TR port value which translates to SetGate(port, value)
  • SC.CV port value which translates to SetCV(port, value)
  • SC.CV.SLEW port value which translates to SetCVSlewTime(port, value)

where port refers to a destination channel inside the ER-301 (1 to 100), then I believe 99% of the users will be happy. The i2c message packet for each command is 4 bytes long:

4 byte array: command id: unsigned char | port: unsigned char | value: signed short

You would send this 4 byte array to the i2c address 0x31 (globally allocated from the Teletype i2c address space to the ER-301).

There are of course more elaborate things that can be done but this would be the core requirement in my opinion.

4 Likes
#32

sorry im not following all the tech talk very well, but for option 2- doing it this way, would this mean we would need a nerdseq and a Teletype module in order for the Nerdseq and er 301 to communicate over I2C? Or are you just talking about to how to write the Nerd commands to make it look like the commands are coming from teletype on the er 301?

#33

No need for a Teletype.

2 Likes
#34

here is a more detailed description of the protocol: https://github.com/scanner-darkly/teletype/wiki/II-protocol

3 Likes
#35

Would it be possible to load Quicksave slots via the NerdSeq ?

1 Like
#36

I don’t know what quicksave slots are…

#37

I could be wrong, but I don’t think i2c supports it.

#38

It’s just saved states of the ER-301.

#39

The existing Teletype ops for the 301 can only work on the things that CV and gates work on; I don’t understand the 301 as well as I understand the Teletype, but I believe the SC.CV and SC.TR devices can’t reach things like loading or saving patches, or (to my current chagrin) loading or swapping samples.

2 Likes
#40

This could be something for the « command bus » - if this feature is still planned (Edit: I’ve found the feature in the wiki, so I guess it’s planned :slight_smile: )

#41

Please @XOR-Electronics :slight_smile: (Just i2c, cv and gate, the rest is superfluous for now)

image
C87A562B-A712-4F5F-8162-4DCD69D63625.jpeg3024×3024 3.01 MB

6 Likes
#42

Watching this thread eagerly as a new Nerdseq owner!

2 Likes
#43

Same here.

Agreed!

2 Likes
#44

Nerdseq -> ER-301 is such a powerful combination and any way to make them even more integrated with each other is something I would definitely kill for. A big big want on my list now :smiley:

3 Likes