#1

Edit 16/01/2021:

This project now exists. Github link for more info.

Old post june 2020:

Short version :*

The idea is to have a Raspberry Pi Zero W hidden in the Eurorack case, and powered by the case. It would receive OSC sent from various devices and transmit the messages to the ER-301 via the i2c bus using the ii protocol. Do you think it’s technically possible ? What is required on the software side ?

Long version :

There are now many ways to control the ER-301 in addition to the CV inputs present on the module. For example, from Norns via Crow and I2c, or Teletype via I2c (and now Teletype receives MIDI too and can convert Midi messages to I2c thanks to @scanner_darkly )

I’m thinking of something else, in addition to all these possibilities, but I don’t know, mostly on the software side, what it would take to make it work:

The idea is to have a Raspberry Pi Zero W hidden in the Eurorack case and powered by the euro case (power consumption is probably < 200ma ). It would receive OSC and transmit this to the ER-301 via its I2c port.

Is it technically possible ? The power consumption of this small Pi is really low so it could be powered by the 5v bus of most euro cases (or the two 5v pins available in the Intellijel cases) and thus not require another power source/cable. I hate to have 4 or 5 cables coming from outside of the case. It is unclear yet if I can connect the Pi to the 301 directly or if I need to create an additional circuit including a level shifter and pull-up resistor (and 5v power protection for the Pi)

Now, how does the RPi speaks (ii) and sends SC.CV SC.TR etc ? That’s a question I’ve always asked to myself. When I designed my Norns clone I put an I2c output (routed the gnd scl and sda to a header) but didn’t go further, so this output is useless haha. If it was a Teensy I could borrow some code from the Telex projects but the Teensy doesn’t receive WiFi… Edit: just found out the ESP8266 module that adds wifi to Arduino, that’s another possibility im considering then

Do you think I should use a Python program for that ? I’ve already found a Python-Osc library, it might be helpful.I’m not familiar with Python but I can learn.

I’m not saying that OSC would be ultra reliable for sequencing without latency but for controlling dozens of parameters from Lemur it might be just fine.

Other options I thought of, always using a RPI zero are: plugging the Pi zero to Teletype, using PureData to convert OSC to Midi and then TT could convert this again to send messages via ii to the 301. Probably too much power required by the RPI to be powered from TT though.

Installing Norns on the Pi Zero, connect to Crow ? Even if Norns could run on this small Pi, same thing it would need an additional cable to power the Pi. Loads of USB cables around the modular I’m not a fan of that. But using the Norns system would be useful yes since it already speaks OSC, talks to Crow etc…

Please let me know if you know have an idea on how to make this work, or you’ve already tried implementing such a thing…

Thanks !

P.S: I’ve mentioned Lemur but it could be any OSC speaking devices and since this setup would use a RPI, why not Midi Ble too? (Using a Roli control block to trigger the pedal loopers of the 301…) Obviously the SC has been made to be used with CV but sometimes when there are a lot of parameters to control, some « Wireless » faders could be handy :wink:

2 Likes
#2

I’ve done some research and here’s what I’ve found :

Software :

Possibility to use Python, there are already many OSC libraries available.

But I’m really interested by Node.js too, it seems to be fast, reliable and modern. It’s implemented in Max Msp and features packages and some code example to set up an OSC server easily. There’s also a well documented Raspi-i2C package for node.js / It might be easier for me to use that since I’ve learned a bit of node.js a few months ago and already know JS

Regarding the ii protocol, I’ll try to use the 16n faderbank firmware as a source of inspiration…

Hardware:
Still unsure but I don’t think I need a logic level converter, the Olimex board seems too use 3,3V too.

The RPi already provides pull-up resistors on its 3,3V i2C bus.

The only source of concern might be the 5V input of the Pi. There’s no power protection after the 5V Gpio on the Pi Zero W, a bit risky… I will first try with the Pi powered via its micro USB port and we’ll see…

Edit:

I keep on logging my process here, I hope it’s ok. Installing Node.js and NPM on RPI Zero W was relatively easy (I had to do it manually because the pi Zero has an Arm6 processor), I’ve successfully tested OSC sent from Max, no I2c yet, just console.log.

I need to familiarize with Node.js before I try to write an app that will parse and convert the OSC messages.

While doing more research I’ve also discovered Node-RED which seems to make things even easier, a script installs Node.js, node-red etc. Then you patch nodes in a browser… I’m testing it. Here’s where I am now:

56
562638×1784 473 KB
13
131332×500 20.6 KB

26
261964×1434 315 KB

3 Likes
#3

this reminds me, at one point i was considering putting in my case an RPi 3 with a vertical 5" screen (behind a clear panel, it fits in 3U.)

I remember i briefly checked if using the RPi as an i2c master to control the ER-301 was feasible and indeed it seemed to be relatively easy. I was envisioning something very simple, maybe just sending values with a shell script (or maybe that didn’t work and i had to use python, but in any way i think i didn’t have the time to pursue until communication on the i2c bus actually happened).

this is exactly my problem with the node.js universe. It feels too complicated to me, like having to sysadmin an unknown OS. For one-off projects i find the starting overhead (of getting to understand who does what and where) too high, and very difficult to keep track of things when wanting to run the thing next year (i can’t maintain more than tiny, standalone, few-files projects that execute in the most default environment possible).

Actually just logging my interest in your project with this message :slight_smile:

1 Like
#4

Thanks for your interest :wink:

Yesterday I had no idea how to make this setup work but today it’s different.

Last night I did a lot of research, evaluating all the options and most of all trying to make it work with what I already have, and earlier today I played a little bit with Node.js I don’t want to learn the whole node.js thing because in our case the goal is just to set a little server on the Pi that converts OSC received over UDP and format some I2c messages. It doesn’t seem to be over complicated, node.js works with modules (OSC, Raspi-i2c etc.) then you call these modules in a js file, etc. It’s very modular but I’m far from being a specialist… Just saying that this Runtime env seems to be really cool.

But anyway now that I’ve found Node-Red, it’s so easy to connect things together, honestly it took me 15mn to install it on the PI, then using the visual programming environment (connecting nodes with patch cables like in Max, Blender, Cables.gl) available in a browser, it took another 5min to receive OSC from Max Msp. There’s already an I2c out « node » ready to talk to the Gpio of the RPI. I’ve also found some MIdi nodes and Bluetooth nodes, this opens the way to Roli Blocks controlling the 301 over Bluetooth maybe ? It seems too easy to be true…

Now I think that I just need to parse the OSC messages and format them in order to be sent over the I2c bus. Here comes trouble probably, I don’t know yet, I need to see how they’re made. There might be some caveats I don’t know yet.

Unless something more is needed on the hardware side, I think I’m not far to achieving the goal, fingers crossed. If the Pi Zero is not powerful enough, I’ll have to design a small PCB to power a larger Pi from the 12V rail (I’ll use the schematic of Terminal Tedium) Because my goal is to get rid of additional external power supply, additional cables etc.

Node-red might be something made for beginners like me but honestly if it works and is as fast as in my early tests, that’ll do the job, I’m not going to reinvent the wheel, I want more control over the 301, I want to trigger loopers with Lemur or any OSC capable device :slight_smile:

I hope it will work with this 10€ RPI, but there are other options too like a Teensy with WiFi module, other programming languages etc…

I’ll post the results here, before I go further I would just like to know there’s a risk connecting the Pi SCL SDA directly to the 301. I don’t want to fry the Olimex board :smiley:

P.S: actually using Node-red would also give the possibility to someone else to modify the script quite easily using a web browser, maybe add support for Ableton Link, a Leapmotion etc. Oh, and there’s a LFO node in the Node-Red palette, could be useful too. I do hope this solution will work. The server can start automatically etc, the only downside might be the boot time, I also hope that the latency will be correct.

#5

IMG_0135
IMG_01354032×3024 2.18 MB

Unfortunately, connecting the Raspberry Pi SCL, SDA and GND to the ER-301 just prevents the ER-301 from booting. Only the red LED of the Olimex board is on but nothing happens after.

But, the Er-301 is not damaged, it starts normally if I disconnect the Pi.

I thought it could be a short so I re-soldered the Pi header but nope, it doesn’t work. I’ve tried to compare the schematics of the Pi (GPIO 2 and 3) and the 16n faderbank The Pi doesn’t have protection diodes on its i2c circuit but it has pull-up resistors.

Not sure if it’s related to hardware, I could test with a Pi3 just in case the gpio header is still not soldered properly. Or the two can’t talk together and this bricks the SC. I don’t know much about i2c busses and protocol.

@odevices do you think the 301 doesn’t boot because it is in « power protection », consequence of a bad soldering maybe (I didn’t test the GND) ? Or because something on the I2c bus breaks its startup routine ?

I had everything prepared on the Node-Red side, at least the OSC part is solved, messages converted to a nice JSON and I2C node ready to scan the i2c bus but given the situation I didn’t even try to sudo i2cdetect -y 1. Not as easy as I thought it would be… (the pi is not powered on this photo, but I’m powering it from its 5V adapter, not with its GPIO yet.

#6

It’s curious that the 301 fails to boot. Which revision do you have? If Rev7, then make sure your SDA/SCL match the wiki since it’s backwards from most I2C connections.

The only other thing I can think of is enabling I2C within the Pi first, as it might be necessary to configure those pins as outputs first. Perhaps they are sinking too much current and causing the Olimex to shut down?

1 Like
#7

Thanks for your message.

It’s the latest revision, I’m used to connecting it to Teletype or Crow and haven’t had any similar issue before.

Yes, I thought about delaying the activation of the I2c on the Pi just enough to let the Er-301 boot but I’m not sure if it’s possible, the module needs to be activated on load. And, during this short test the Pi was started before powering Up the Eurorack case.

Yep, you’re right. That’s a serious possibility. There are no diodes on this circuit, the 301 is directly connected to the BCM2835.

I might have to design a very simple PCB, a small circuit similar to the one found on 16n faderbank to prevent that. And if this is all it takes to make this work, I will do that :slight_smile: And I’ll add 5V power protection to the input while I’m there ^^

I think the I2c circuit of the Pi is designed to connect to small sensors also powered by the Pi and not powered from another source.

Edit: now that I remember, this I2c circuit with diodes is present on my Nordhat PCb :slight_smile: so I will be able to test that rapidly. I will just bypass the additional pull up resistors maybeimage

Actually, these pins are dedicated to I2c SCL and SDA on the RPi, aren’t they supposed to work in both directions ?

EDIT (15/06/20):

Tested with the new circuit (the same circuit that the one used on 16n Faderbank for i2c) but I’ve bypassed the additional 4,7k pull up resistors.

Same behavior. The 301 won’t start. It doesn’t work.

If I let the 301 boot normally and then start the RPI (I plug its power source a few seconds after), there’s no visible issue but the Sound Computer is not seen on the i2c bus.

18
18764×364 60.1 KB

Maybe the bus speed needs to be adjusted, I have no idea…

Anyway, It was worth trying :wink:

#8

Do you have another I2C device to test with the Pi?

1 Like
#9

Yes, good idea. I have a Faderbank and some TELEXo. I also have a Teletype and Crow but these are masters.

Also on the list of things to try: using a RPI 3B which uses a different chip than the Pi Zero w.

Edit:

So, I did a few tests. The Txo is easily found on the i2c bus. That’s a good news.

sudo i2cdetect -y 1 returns

34
34744×308 41.3 KB

and in the Node-red flow

09
092058×930 85.4 KB

I tried with the RPI Zero and and with a 3B, no problem. I haven’t try with a Faderbank yet but I guess the result will be the same.

At least, I can continue to work on the Node-Red flow and convert OSC to I2c using this cheap module for the test. Worst case scenario: if I still can’t connect the RPi to the 301 directly, I can use a TXo to act as a bridge between the Pi and the 301.

#10

Very curious. All I can suggest is perhaps trying an I2C repeater IC (e.g. TCA9617BDGKR) rather than a microcontroller for forwarding your messages.

1 Like
#11

Thanks for the part reference. Yes, if I need to design a small PCB for this project I could use a component like this one.

Right now, I’m trying to write commands to a TXo and to read from the Faderbank (and to wrap my head around i2c in general ^^). I want to make sure there’s no particular issue with Node-red before I deal with direct connection to the ER-301.

Ah, it will be easier now that I’ve found this https://github.com/scanner-darkly/teletype/wiki/II-protocol#er-301 ^^

EDIT: I’ve successfully managed to control the TXo from Node-Red over I²C :blush: The OSC to I²C part of the flow is almost already written so, I’m getting closer maybe…
This part is working too: TXo control from Max over OSC and i2c :white_check_mark:

Of course the goal remains to talk to the 301 directly, but controlling the TXo via OSC is already a good step

#12

Nice progress. I’m just concerned that whatever is causing the ER-301 boot failure will recur when you add it back to that bus…

1 Like
#13

have you checked the nerdseq i2c device - its doing what you want (and me too) just waiting for it to be produced
I started doing this as well (adafruit has some great solutions pretty much ready to go) but with Thomas already having done it nd owning a nerds and er301 and all the monomes im dying for this - also new disting does it

1 Like
#14

Ah, I do not own a Nerdseq unfortunately, I wish I had bought this module instead of Hermod but that’s another topic :slight_smile:

Actually, the goal here is to control the ER-301 using a 15$ Raspberry Pi and the controller of your choice wether it’s wired or wireless, possibly without any additional Eurorack module. RPI directly connected to the 301, Pi powered by the Euro case, no additional cable.

So far, it’s been tested successfully with a set of TXo (BPCMusic Telex) but for some reason the 301 doesn’t play well with this setup yet. I hope I can fix that, I’m not a specialist, I’m just experimenting.

The reason I’m mentioning that it’s already working with a TXo is that it brings a « proof of concept ». Using Node.js (and more precisely Node Red) on Raspberry Pi, I’m now able to control the TXo from many sources. It’s been tested with OSC coming from Max but this opens up a lot of possibilities including controlling one or more modules from:

  • Max Msp
  • Roli Device (Midi over Bluetooth) or simple serial Midi.
  • Web Browser
  • Leapmotion
  • TouchOsc and Lemur on IOS.
  • Wiimote (any OSC capable device)
  • and more

It doesn’t even need a lot of programming. I’m just using the input nodes available for node-red, a bit of JavaScript to handle that and a last node to output to the I2c bus. The latency is very reasonable so far.

We can consider all of these sources work with TXo now. Using Node.js / Node-red, the possibilities are wide (even controlling the module with any API, though I don’t see a reason to control the 301 from Twitter yet…). I’m just using the Pi to convert a message to ii protocol/message.

I will do more tests tomorrow. There are a couple of things I need to try to make it work with the “Sound Computer“ because my goal here is to connect to the 301, the TXo is just a bonus :slight_smile:

1 Like
#15

You’re right.
And you just gave me an idea, it’s worth trying to connect the TXo and 301 on the same bus, RPi connected to the TXo. I want to know if the 301 doesn’t boot because of something on the bus it doesn’t like or because the Pi pulls current from the Olimex.

I can try to power the Pi from the 5v rail of the Euro case just in case the lack of common ground (technically they have a common ground, but who knows) could be the cause of the issue. I will also try to lower down the baud rate of the I2c bus …

#16

wow thats very impressive!!!

I reckon it would be worth looking through scanner darkleys docs as he has them all talking via Ansible and sees to be the yoda of i2c :wink:

Can you cross post this on liiiiines?

1 Like
#17

Sure, I will post this on Lines too. I just want to test everything more deeply before I do. If it’s only working with Teensy based modules, it’s not that great. I would like this to work with the other modules too, and most importantly with the ER-301 :slight_smile:

But the concept is simple and anyone can try: RPi + Node.js + I2C

And yeah, without Scanner Darkly’s work and documentation, I would never have had the idea to dive in and begin this experiment :slight_smile:

#18

Just a quick update. I tried many things but nothing new…

I followed an interesting lead : Hardware i2c on RPI3 doesn’t support I2C « clock stretching » due to a hardware bug. The workaround is to use « software i2c » on PI. I had to create another I2C bus, a « software I2C » bus. This uses another set of GPIO) and adds support for « clock stretching ». Many people report issues related to clock stretching, so why not…

I added some external pull-up resistors to the setup. But no, still not working with the 301. (Works fine with TXo)

I’ve read the whole « Monome i2C » thread. It’s not clear if the ER-301 sends things through the UART during startup. (same port used for i2C I believe ?) Anyway, I don’t have the tools for monitoring that.

As far as I know, the RPI doesn’t send anything to the bus if it’s not asked to, but if the 301 sends something and the RPI can’t handle it. I don’t want to dive in error handling etc on the Pi side.

  • In any case, even if I let the 301 boot normally and I start the RPi once this is done, the 301 doesn’t « ACK » in response to a bus scan, it’s not a problem of lost bytes etc.

  • The pull-up resistors value are probably strong enough for this bus. I should try more values but it’s getting too complicated.

  • I lowered down the bus speed to 50k and even 10k, without success. For some people this has « fixed » clock stretching issues, consequence -> much slower bus.

Well, I tried everything I can imagine, it’s probably time to move on ^^

#19

this is where I would be contacting scanner directly - or post on liiiines - consider that Ansible is doing what your trying to do minus the OSC stuff (hes even got idi working) and ASAIK none of them use UART .

All of the functionality is in the II docs - are you checking those?

have a read through that - its all just II OPS via i2c which is already exposed to er301

1 Like
#20

Yes, I checked all the docs and I have read a lot about I2C these days but there’s no problem with the commands actually, the 301 uses the same set of commands as the TXo. This has been tested with the Teensy. I’d be happy if the problem was just setting/formatting the commands correctly :wink:

This seems the be a problem between the Olimex board and the Raspberry Pi, and probably an electrical issue that can only be fixed by designing a small circuit between the two. Imo, the 301 doesn’t even receive the messages and has no chance to send back an Ack because something pulls the line. The fact that the 301 doesn’t boot when it’s connected to the Pi is “problematic“ to say the least.
Scanner Darkly mentioned on this forum that the 301 used to freeze if it received I2c commands from TT during its startup routine, probably because this same port is used for another task during startup (?). Here, it’s not receiving anything, so it must be a different issue. Imo it just doesn’t boot for the reason mentioned at the beginning of this thread: current draw from the Pi GPIO + powered from another source, different ground (that doesn’t help), the Olimex doesn’t start etc.
I wish I could investigate much further, designing a circuit for stabilizing the bus is possible and cheap, unfortunately I don’t have the ee knowledge to troubleshoot that kind of issue and fix that. All I can do is trying out various pull up resistors values :-/ I don’t have an oscilloscope or a logic analyser. If the I2c output of the Pi can’t connect to the 301, well it’s just disappointing but it was worth trying.

Anyone with a Pi could activate the I2C on it, carefully connect the GND, data line and clock to the SC and probably watch the same result following a bus scan aka: no results, no device found on the bus ^^

I will publish the node red flow (It will work with TXo but will add the 301 commands as well, just in case) on my GitHub account in a few days if someone wants to investigate with the 301. I don’t want to bother Scanner directly, he’s probably already busy with the Midi ops for TT.

1 Like