#162

This 1.4.1 build with pullups, on my large configuration noted above, still hangs on addresses that aren’t on the bus (e.g. TR.PULSE 9). To be honest (and to echo something @Galapagoose has rightly mentioned several times), I/we need to get systematic about these tests so we understand the boundary conditions.

@sam - the teensy, according to the Teensy i2c Library Page, has the following internal pull-ups:

Teensy 3.0/3.1/3.2 - ~190 Ohms (this is believed to be a HW bug)

3 Likes
#163

So that makes the effective system pull up ever so slightly less than 190 Ohms right? Thus on a small system we might not be able to pull down then?

If I get a chance I might see if I can have a go with an Oscilloscope, I found a nice right up with pictures that I can follow along with.

#164

ok. pullups enabled on ansibles and tt. honestly even with all of them on, the collective pull is not very strong.

basically when i get above 4 modules on the bus (all monome) i start to get freeze on non-existent addresses.

soldered on 4.7k parallels on the SDA/SCL to TT, all is well. it’s not a clean fix. changing the actual resistors requires disassembling the TT, which i don’t have time to do right now.

so. that’s that.

i guess i should put together a tutorial for replacing your TT resistors, for us people with tons of modules.

again, to chill this out a little bit-- if you just have few modules there are absolutely no problems with the current scheme.

1 Like
#165

What about a powered II bus board with a 3.3V regulator on it to supply the pull?

Maybe a couple of jumpers to allow for a configurable resistance.

1 Like
#166

@sam - that is exactly what I’ve been thinking about! I just honestly haven’t had the time to fiddle with it. Too many modules to build right now.

I’m thinking we could take the bus board concept and extend it down so it could grab some 3.3V off of either the button or programmer solder points on the module. (That is assuming there is 3.3V down there.) Put a couple of different resistors on the board and some jumpers and we would have a solution that could work for everyone that wants to grow beyond the current few module limit.

1 Like
#167

Oh well, so we have to solder something onto the teletype - is it something one can do at home? After practicing SMD soldering on a TXi/o is that.

I assume placing resistors somewhere on the expander board would not do the trick?

#168

Why not just have something that connects directly to the Eurorack power bus and uses a 3.3V regulator? Regulators are pretty cheap.

From a personal point of view, I’d prefer something separate from the Teletype anyway, module to module cables are awkward at the best of times, and my Teletype has 4 of them hanging of the back of it at the moment.

Conceivable a ‘powered II bus board’ could have a 2x8 female header on the rear so that it can be directly attached to the Eurorack power bus, and then the 2x3 II headers could go on the front side.

I guess we would need to be more wary of short circuits with something that is not directly connected to the rear of the Teletype module.

4 Likes
Ii bus board, v2, with pullups
#169

powered i2c board is intriguing for sure.

we’ve obviously hit a point where the i2c territory needs to be reconsidered, as it began as a wouldn’t-it-be-great afterthought on the White Whale.

main issues at hand:

  • which module or where the pullup gets set
  • how do we bus or daisychain connections

there aren’t any sensible 3v3 solder points on the back of the TT.

i’ll think more about this but we should hear a few options.

2 Likes
#170

m[quote=“tehn, post:160, topic:5861”]
i could do that, but there’s still a pile of TT stock, and it’d be better to find a solution that works for all existent TT’s out there rather than having a split solution.

the test tt w/ pullups build was wrong. here’s a corrected version, which works well for me with 2 ansibles. anyone with a huge chain, please test this:

EDIT: here’s a version with the newest 1.4.1 features, i neglected to upstream merge first:

teletype-1.4.1-pullups.zip (83.1 KB)
[/quote]

I just tried this (it is different from the one you linked to in this very post from the Ansible 1.4.1 thread, right? I am getting a bit lost with the versions…) and 1 L 1 12 : TR.PULSE I immediately freezes teletype when switching the second Ansible (9 - 12) to Levels. It does not wake up again when switching back to teletype mode.

Setup is teletype, earthsea, meadowphysics and two Ansibles on the bus with a fresh and empty teletype firmware.

#171

+1 for a powered i2c board solution. perhaps even with some LED indication of when the current pull up value is outside of the optimal range? [disclaimer - no idea how doable something like this would be, just thinking outloud]

2 Likes
#172

AFAIK it’s not if it gets to 3.3V, but how long it takes. Check out these oscilloscope plots I posted earlier.

1 Like
#173

yeah, understood. perhaps some easy approximation could be built that would measure “spikiness” specifically (looking for higher frequency content specifically or measuring it against lower frequency content?)

1 Like
#174

Is it fair to say that we’ve got to the bottom of the main i2c problem then? (i.e. the resistance / capacitance issues)

If so, I’m going to merge monome/master into my samdoshi/parser branch this week and open up a PR with the parser improvements, the operator aliases and the sub command work that I did.

2 Likes
#175

@sam I don’t think it has been sufficiently and successfully tested yet to be able to say reliably this.

#176

Are you saying this from an empirical rather than a theoretical point of view?

#177

The theoretical point of view is that this is how I understood the new bus board thread: as a proposal that probably will fix the issues but is not yet tested. Plus there seem to be differences in working with a lot of TX modules vs. a few of the original monome modules as the @bpcmusic’s testings suggest.

The empirical part would be that i2c is supposed to work reliably with four modules on the bus but does not for me, while it generally does with two Ansibles.

So I am not sure if it is fully understand how those pull up resistances have to be set and contributed. And if they fix all of the issues or if there is something left to do in the code. I hardly understand anything of all this and my impression comes solely from common knowledge and the experience that we have been on several “it should work know” points by now.

All this is not meant to be rude - I know I might sound like that sometimes. It is just very important to me to have the ecosystem in a stable working condition. So I am a bit afraid that we might overlook something as it had taken a while until the i2c issues have been taken seriously and tracked down that far as they are now, which is great!

:slight_smile:

1 Like
#178

IMHO, go ahead and land it. If it turns out that there’s more to the issue than the pull up, then reverting to the current revision in github for further investigation is always an option.

2 Likes
#179

you should be able to go ahead.

i just pushed libavr32, with pullups/etc disabled-- this is what we want.

#180

I think I’m going to get the PR opened. Even if it’s not merged immediately. Mainly I’m worried about it starting to bit rot if too many other changes come along. It shouldn’t really affect the i2c stuff anyway as it’s all on the programming language side of the teletype rather than the hardware side.

@bpcmusic given the monstrously large pull values that the teensy has, have you tried running the i2c bus at 400kbs (or higher)?

3 Likes
#181

avr32 is limited to 400kbs so it won’t go higher, but it’d be great to test at this speed with a full bus!

1 Like