#196

very interesting. i wondered before if something like this was doable, a device that watches the bus and automatically adjusts pull-ups or whatever when it detects that the rise/fall times are too long. this could potentially be very useful for heavier set ups as well, not just for long distances, or just to increase the rate.

and looks like it’s small enough to be integrated into a busboard or txb.

2 Likes
#197

The big i2c bug was fixed in er-301 firmware 0.5.03

It behaved a bit different than what @Cristian_Vogel mentions, but I still think we need to make sure he’s on 0.5.03 before discussing it further…

1 Like
#198

Sorry if I missed this information somewhere on this thread. How do I tell what is ground on the i2c connection on Just Friends? I am trying to connect Crow and Just Friends. I see it clearly labeled on Crow but not Just Friends.

Thanks!

#199

it’s marked with a thick white line.

1 Like
#200

(meta: if this is answered somewhere, or this question belongs in an existing thread, apologies! I did search for a while.)

I have a green PCB teletype with a backpack with pull-up resistors, which are working as near as I can tell. I was testing my i2c bus setup by trying to use TXi and 16n values to control Just Friends volume and pitch.

I was seeing the setup fail, which I understand can be common with i2c setups, so I started stripping it down to see if I could isolate the problem. What I’m seeing is, well, odd: If I have my 16n on the bus, and I attempt to access an i2c device that Teletype can’t find, the i2c bus stops working entirely.

I’m testing this with only 16n on the bus, and a simple metro script:

M: 
X FB 1

and then watching the live variable on the live edit screen. As I slide the fader, I can see X change values, reading from the fader correctly.

If I try to access something that Teletype can’t reach, i.e. I run something like JF.MODE 1 as a live command, X immediately becomes 0, and Teletype can no longer see the 16n on the bus and can no longer read the fader value.

If I do a similar thing with a TXi - only the TXi on the bus, simple polling in the metro script, then do something like attempting to access JF.MODE 1 - Teletype handles this fine. It continues to see the TXi.

Teletype also handles a more complex i2c bus setup well enough. I’ve had a TXi, a TXo, JF, and two W/ on my bus with no issues. It’s only when I add my 16n to the mix that I have issues.

This is true even if I’m not attempting to access the 16n. With TXi and 16n on the bus, and only polling the TXi, if I attempt to access something that’s not on the bus, Teletype stops seeing all the devices.

This sounds like a non-problem in some ways - just don’t call things that aren’t on your i2c bus! - but what I was finding was that even if I was running scripts that only called devices that were present on the bus, I would still get failures. I am guessing that any momentary inability to reach a device causes it to seize up.

I am mostly wondering if this smells like a particular kind of problem to anyone. I could guess

  • pull up resistance problem (again I am using a backpack but maybe it’s not doing what it should?)
  • i2c length issue (my cable for the 16n is a foot long; that was the shortest I could get it while having it reach the Teletype)
  • hardware issue with the 16n (I DIY’d it; it otherwise functions as expected)
  • Maybe this is normal expected behavior?

Stats:
Teletype: Green PCB, with backpack, running v3.2.0
16n hardware: DIY’d by me; Teensy 3.2; PCB v1.34 as far as I know; no pull up resistors installed (i.e. for 16n-as-leader)
16n software: v2.0.1
16n i2c cable: homebrew stereo TRS 3.5mm joined to jumper wires, total distance between the 16n jack and the backpack is a little under a foot

Thanks in advance for any help or suggestions for more things to test!

#201

normally polling non existing devices should be fine. in my experience if you get issues when doing so it indicates the bus isn’t stable enough. do you have the pullups enabled on the 16n? if you do and they can be disabled easily, try that, or try with 16n connected but not using the backpack.

#202

I do not have pullups installed on the 16n. I can try the 16n connected directly to the Teletype w/o the backpack, though my understanding was the 16n needed pull-ups out of the gate? I may be wrong about that. edit: Tested w/ the 16n connected directly to the Teletype. Same behavior: polling one fader, then attempting to poll something else, causes a drop.

Interestingly, attempting to poll two faders in the metro script also causes the same behavior, so if I start with the first and then add:

M: 
# initial script; works fine, stable
X FB 1

# when I return to M and add the second fader, the bus dies
X FB 1
Y FB 2

# Polling FB 2 and assigning to Y on its own works fine
Y FB 2

So, some issue w/ concurrency maybe? (I am a software engineer by trade but have near-zero knowledge of the workings of i2c, so just reporting “smell”).

Would a somewhat dodgy cable to the 16n potentially contribute to an unstable bus? My skills at splicing and soldering wires together are pretty questionable. I am planning on ordering a TXb from Pusherman, since they’re offering those pre-built now.

Thanks for response!

#203

in this case you should definitely use a backpack, and a txb might help with your issue as it will have additional pull-ups. i should mention that it’s not a question of having more pullups necessarily but rather the combined value of them being correct, so in some cases you’ll get better results by reducing pullups. unfortunately, there is no easy way to check unless you have an oscilloscope.

it could be a bad cable but my guess would be that your i2c bus isn’t stable, which would result in what you’re seeing. and when the bus isn’t stable, you’ll see i2c ops being dropped or causing freezing and you’ll get issues when calling non existing i2c devices.

#204

What voltage values am I looking for, across which points? Is a multimeter sufficient or does it need to be recording voltage changes over time?

Thanks again!

#205

voltage does matter but likely is not the issue. it’s the rise/fall time. a good example here: https://electronics.stackexchange.com/questions/102611/what-happens-if-i-omit-the-pullup-resistors-on-i2c-lines

and some more detailed info here: https://www.analog.com/en/technical-articles/i2c-timing-definition-and-specification-guide-part-2.html

1 Like
#206

I can have Crow on the bus and activate the pull-ups there, if adding more to the mix might be helpful. I will try that.

qq: is crow pullup state setting volatile or does it persist between power cycles?

Thanks for the direction!

#207

Crow pullups are on by default, but the state is not persistant. They will always be on at startup, unless you explicitly turn them off in your script.

That said, crow pullups are very weak (~40k ohms), and will likely only support a single attached device. As of the most recent Just Friends firmware (and the forthcoming W/2 firmware), both of these devices also have pullups enabled (again, weak ~40k ohms). So with a Whimsical Raps & Monome only setup, you should be able to get by without anything external.

The Teensy used in 16n and Telex modules is known to require additional hardware pullups.

1 Like
#208

My bus contains:

  • Teletype w/ backpack w/ pullups
  • TXi
  • TXo
  • JF
  • Crow (on a slashes; shouldn’t matter, I think?)
  • W/ x2 (same)
  • 16n, without pullups

It sounds like I may not have enough pullups for this, even with the backpack in place. Unfortunately I don’t have an oscilloscope handy to troubleshoot.

Currently I only seem to be having instability when add the 16n to the bus. Would it make sense for the 16n to bring its own pullups? I had read that you were only meant to install pullups on the 16n for use in leader mode, which isn’t going to be my use case, so I didn’t install them.

ii on Crow seems to be a bit more stable than Teletype - Teletype will stop seeing devices, while Crow will continue to operate for a while. I do tend to get the ‘lines are low’ message eventually from Crow though.

ii: lines are low.
  check ii devices are connected correctly.
  check no ii devices are frozen.

I can always leave the 16n out of the i2c mix, and probably will in the short term, but it would be lovely if it worked.

Again, any input is appreciated; I’m understand a single user with a single problem.

#209

it is my understanding that enabling more pullups might actually make things worse. it would be handy to have some mechanism to identify what pullups you need exactly but unfortunately in the absence of an oscilloscope it basically comes down to trying various configurations and seeing what works best.

one more thing to try - if you have all devices connected to the backpack, try daisy chaining at least some of them instead.

#210

Thanks. I’ve been considering a proper oscilloscope for a variety of reasons, so this is one more for the pile.

I mostly daisy-chain, but not entirely. I’ll try few different configurations. I’ll also update JF and one of my W/ to latest (other W/ is already running the firmware) since that will change the “topology” again.

Thanks!

#211

I just want to put this here in case it helps others. Intellijel released a 1U tile that should be able to be used to connect TRS i2c (i.e. bring in the signal from a 16n). They even indicate it as a possibility in the manual.

Might have to make some cable adjustments but should be easy – anyone done this yet?

#212

Yup, it’s fine. Also, I used this with midi for Disting.

1 Like
#213

Did you need to change the header on the cable going into i2c?

#214

Sleeve is in the middle so I’d recommend single pins or making your own cable which isn’t too difficult.:slightly_smiling_face:

2 Likes
#215

I have a question about the use of ANSIBLE and TXi modules to control the ER-301. The problem is that I have created some script in Teletype to control parameters in the ER-301 using the SC.CV and SC.TR commands. However, when I use ANSIBLE to sequence patterns and fire triggers or cv via I2C to the ER-301, TELETYPE stops responding and the ER-301 stops receiving data from the TXi.

I understand that the use of ANSIBLE via I2C and TXi at the same time is incompatible?