#14

For a weekend project I may try implementing something similar to all (OSC over wifi) this using an ESP8266 microcontroller or a Teensy+ESP32 breakout.

I don’t have a ER301 to test with, but can try to get something working to my Meadowphysics as a demo.

2 Likes
#15

I’m afraid to say it’s time for the logic analyzer, or at least a scope.

If it didnt work after hot plugging then there’s likely something up.

3.1V doesnt necessarily seem like a problem to me. Test with txO to see if it is lower in voltage too, then you’ll know if it’s RPi or ER causing the droop.

1 Like
#16

Thank you both for your replies.

I would like to own a nice Rigol oscilloscope but it’s more than I can pay right now and a Logic analyzer is even more. The cheap analyzers found on Amazon might be a bit weak compared to Saleae devices, but maybe they’d work too for a “normal speed” bus ? There’s also this software Oscilloscope which works with Pigpio that I’m planning to try later.

I’m testing a few other things before giving up with the RPI.

It turns out that the drool was caused by a mistake of mine, a bad connection on the breadboard … :face_with_hand_over_mouth:

New tests today revealed that the voltage is very close to 3.3v in both scenarios (module on or off). One more time, I let the 301 boot and hot plugged the two lines and ground. No drool with the Txo either.

At this step, the voltage is still 3.3v. But right after the bus scan, the line is held low by the follower, and stays at 0v…

The I2c specs mentions that when this happens, the solution for recovering the bus is to send 9 clock pulses…

If the data line (SDA) is stuck LOW, the master should send nine clock pulses . The device that held the bus LOW should release it sometime within those nine clocks

At the moment, I’m trying to figure out how to send 9 clock pulses from the terminal :smile:. Such a bus_recovery method or “bus clear” doesn’t seem to be implemented within i2ctools (or maybe it is but there’s no documentation, so it’s hard to know) This feature is not implemented in the BCM2835 driver…

I’m experimenting one more day with the Pi and if it doesn’t work I’ll probably switch to another method.

@okyeron The ESP8266 is an option I have considered. Teensy + ESP32 is also a great idea :slight_smile: There won’t be Node.js and node-red in this scenario but there are a lot of libraries available for Arduino and the code for talking to the ER-301 is already written, so… Yep, I’ll definitely get one if the RPi experiments fail again today.

#17

What is the “bus scan” and how does it work (is there source we can look at?).

Perhaps you could try sending a ‘real’ command to ER301 and check for response. AFAIK there is no specified i2c protocol for scanning the bus (a lot of us have spoken about how to do it). I’ve also not seen that 9-pulses thing anywhere, though admittedly I’ve never read the i2c spec.

2 Likes
#18

Yes, sorry I said bus scan but the command is i2cdetect It’s part of i2ctools It is documented here https://linux.die.net/man/8/i2cdetect

The nine clocks thing is documented here section 1.3

Yes I can try to do that, I’m going to search how. python probably.

Result :

Python equivalent of i2cdetect 
#!/usr/bin/env python

import smbus

bus = smbus.SMBus(1) # 1 indicates /dev/i2c-1

for device in range(128):

      try:
         bus.read_byte(device)
         print(hex(device))
      except: # exception if read_byte fails
         pass

It returns nothing and pulls both lines down.

#19

Oh… Now it’s working. :champagne:

  1. Apparently, the ER-301 needs 4.7k pull-up resistors and nothing else. This solves the “boot issues”.

  2. It absolutely hates the i2cdetect command.
    Thanks to your suggestion @Galapagoose I sent a simple tr.pulse to the ER-301 bus.write_byte_data(0x31, 0x05, 0x01) and it’s working.
    Every i2c on RPI tutorials encourage you to do this bus scan with a force command. When you remove the -f from i2cdetect -f 3 the console shows the following advice :expressionless: > WARNING! This program can confuse your I2C bus, cause data loss and worse!

Now that the i2c works with both TXo AND ER-301 I can continue to work on the node-red code :slight_smile: The only downside is that the setup will need an external circuit. Given the fact that the ER-301 apparently requires the usage of specific pull-up resistors, I cannot use the default i2c pins. I used a Teletype backpack for this experiment but I will design something.

IMG_4001
IMG_40013024×4032 3.33 MB

5 Likes
#20

If the issue is the resistors are too small (ie too much pullup current), it probably just means the signal is taking too long to hit the Low state. The other solution is to use a slower clock speed as it gives the clock pulses longer to settle to the low state (and be registered correctly by ER301).

2 Likes
#21

Thanks. I should do more tests based on these informations. From my experience, with the 1.8k resistors it is also preventing the ER-301 from booting. The Olimex manual strongly recommends 4.7k resistors on the i2c bus. This needs to be tested once again, I need to confirm that :slight_smile:

1 Like
#22

I just want to say; this is a really really REALLY cool project. I have been looking at the OD store every day, looking for shipments to start again, and matching my Polyend Tracker and norns with a 301 via OSC sounds divine. Not To mention potentially translating a Twister Fighter and Arc to OSC commands and further control over the 301 would be a paradigm shift on top of the 301 to begin with.

Thanks for taking up this cool project and I truly hope you get all your questions answered, because you work could be a game changer for a lot of folks.

1 Like
#23

Thanks ! :blush:

I hope not to disappoint anyone if the latency is not that great for example. I’ll work on the Node.js part and we will quickly see if the concept is functional and reliable or not. I also need to have more control over the 301, that’s why I started this, the 16 inputs are not always enough. A solution like this could also be cool for euro setups with just a 301 in a Pod for example, mobile Eurorack. At this point I cannot guarantee anything but I’m glad I got the Pi to talk to the 301.

By the way, during my “researches” I’ve found that the Olimex board the Er-301 uses has two Ethernet ports… they are not physically present but…

1 Like
#24

I mean, at the rate COVID is going (not to mention the amount of interest I’ve seen on the OD boards for the unit) it’ll be about 4 to 6 months before I get one to try this out with. Guess that gives minds greater than mine a chance to really dig in and see if this works. If it does, I can imagine a lot of cool, bonkers things that could be done with Max/MSP and this. Haha

1 Like
#25

Ah yes, loads of people seem to wait eagerly for the OD shop to re-open and I can understand that, I hope Brian has been assembling a lot of 301 while the UPS/Fedex system is blocked in Japan . For ultra reliable connection from Max etc there’s Crow. Once again I cannot guarantee that a wireless connection will be perfect :smiley: My goal here is just to put the 301 solo in a USB powered pod, no additional cables, controlling some faders and start/stop some loopers from my phone or iPad. But there are a lot of possibilities once the the RPi sits in the case, is connected to the module via I2c. The node-red interface remains accessible from a web browser for additional tweaking etc

2 Likes
#26

just catching up on this thread - really cool project, thank you for the commitment to make it work!

this could be super useful for other followers, especially those that have many parameters to control. and could have some generative/sequencing scripts running right on the device itself.

2 Likes
#27

That’s true. I really haven’t dug much in to crow and max. I just finished the PCB portion of an arc build, and am in the process of machining/cutting out the rest of the parts. Using Max and crow will be really exciting then, especially with the TXo.

But yeah, I keep thinking ‘maybe I’ll just get a Japanese address/shipping service to get the 301,” but keep realizing that it’s still a 4 week lead time and then we’re looking at FedEx shipping cost and receiver fees! :wink:

But dang, even something like Fugue machine on an iPad, or other types of programs then sending to the 301 could be wicked cool.

I’ll be keeping an eye on this project, for sure. I’ve got a PiZero from an old AI/wireless video project just kinda chilling in a box somewhere.

2 Likes
#28

Thank you @scanner_darkly :blush: it’s made possible thanks to your work, all the I2c commands, the ii protocol etc. This week I‘ve had the chance to finally understand how the I2c protocol works. I’m far from mastering it and as mentioned earlier it would be helpful to have an oscilloscope for troubleshooting, but it seems to work so…

Yes, absolutely some devices have so many accessible parametersand even with TT it’s sometimes difficult to set something up to control all of these easily (the TXo can be a cool (4) oscillator(s) module but it’s difficult to set it up, loads of lines needed within TT) Some param won’t need ultra low latency to be set, I wouldn’t recommend Wireless OSC to I2c for a step sequencer for example but who knows? Node.js is quite fast after all.

The node-red environment is also easily accessible and super simple, it would be a good place for writing JS functions, recall presets on various modules, I don’t know :man_shrugging: Everything’s possible. One thing i know Is that I really want to add Midi BLE to this setup, and… there’s a “node” for that :slight_smile:

Edit: there’s a major downside to this project, the RPi is a leader too :confused: If it takes place in the bus with TT or Crow, it’ll probably want to drive it. I’m not sure how it will react with other leaders, I have read that a multi leader bus is entirely possible but it might need ee and software adjustments to work.

1 Like
#29

Let’s hope the Pi Zero is fast enough, I’ll do some tests soon, especially the wireless part of it, otherwise we might have to use a larger device, it would not be great because the plan is also to reduce the cost at max but I’m planning to make a kind of “hat”, the size of a RPi zero, directly pluggable to a free 12v header in the Eurorack case maybe (? I need to borrow some parts of a schematic) it’s probably too soon for planning that though :wink: Some people will prefer a 1u with a USB port (for connecting a Leapmotion or Midi device). I’ll try to work on the code in the meantime… first, let’s see if it’s reliable/stable and fast :slight_smile:

P.s: designing a small external circuit was absolutely not part of the plan but since it seems to be needed (for various reasons like clock stretching support, possibility to use various pull up resistors values etc) why not add 12v to 5v conversion to it instead of “dangerously” powering the pi from the 5v rail with two wires?

image
image1536×2048 649 KB

I have something like this in mind, the components are not valid, sorry for the poor drawing :grimacing:

1 Like
#30

Yet another bump in the road, the ER-301 responds only to the TR_Pulse command. I’m trying to troubleshoot this issue.

TR_Pulse is the only command that has only one argument - Port -

Option 1 - at some point the module doesn’t Ack anymore and the additional bytes are lost. Unlikely, but who knows ?

Option 2 - The issue is linked to the integer type conversion happening within Node.js (see below). Probably.

TXo responds well to a command with multiple args like TR (port + state), it also responds well to CV. The integer type conversion within Node.js is a bit weird right now, I’m investigating. The CV out is at 0v for an int 0 sent from Max, 10v for 127 and 0v again at 255. It should receive a signed integer and be at 10v for a value of 16383, am I right ? Funny because the TXo handles this quite well (probably not as precise as a signed integer but it works) But the 301 doesn’t like that and expects only a S16.

I hope I can solve that soon, I’ll speak with the maintainer of the I2c node.

Expect some delay :wink:

#31

it should be exactly the same for txo CV and er-301 CV - the only difference is the i2c address.

both expect the value to be a signed int16, most significant byte followed by the least significant byte. what you describe leads me to believe that you’re only sending one byte and txo is more forgiving and uses 0 for LSB, while er-301 doesn’t.

CV values are based on the fact that tt has 14 bit DACs so 16384 maps to 10V.

1 Like
#32

Ahh, this would explain why TXo responds and not the 301, interesting. I was afraid this could be another hardware issue.

In that case, it’s linked to the “node”. It is supposed to send two bytes, but some users reported some issues in the past and I’m not sure it’s totally reliable at the moment. I’m exploring it’s code right now and have started talking with the new maintainer of the repo.
Hopefully, this can be fixed easily.
Thanks :slight_smile:

#33

to clarify, not sure this is actually the case, just my guess based on what you described

1 Like