#155

@tehn
I am not sure if it worse or better now - I just experienced this:

First try with the new firmware, as it was yesterday, TR.PULSE to not existing adress freezes teletype. (just tt and two Ansibles)

Then I went back to the last firmware, tried again with the same outcome. Shifting one of the Ansibles into the requested address range via the button combination and the black teletype immediately starts w/o power cycle.

NOW I reflashed the new firmware and happily shifted one of the Ansibles over the address ranges and no freeze! Even when TR.PULSE reaches for not known addresses. The only difference to the first setting was, apart from down- and upgrading, handily shifting the address range of one Ansible.

Then I got back to the firmware before the new one and it still works. TR.PULSE in a Metro Script to all address ranges and switching on Anisble back and forth through all ranges with now freezes, just different TR outs flashing.

So is it that you have to use the address range adjustment ontime on Ansible and then it can’t break anymore?

:open_mouth:

#156

Keep in mind - I have 7-8 devices on my i2c bus. It is pretty extreme.

I went back to the latest 1.4.1 firmware without pull-ups and had the same problem. I then enabled pull-ups for just one expander (the closest TXi) and my bus is back to 100% stable.

[EDIT]

Just created a script that reads from 8 PARAMs and 8 INs, writes those values out to 16 different CV outputs and pulses 16 TRs. Running the script at 10ms intervals and having no issues. Manually calling to non-existent TR outputs while running does not lock the Teletype.

@Leverkusen - once, I accidentally activated a couple of external modules with pull-ups. In that case, I would find that the calls out would become unreliable. The TT wouldn’t lock - but some modules would stop responding. Resetting the firmware back to my “good” configuration made everyone happy.

#157

…okay, more strange findings:

At first, using the older firmware does not work very good over a longer time, especially when you plug in the arc in one of the Ansibles.

The new firmware seems to be more stable in this. Teletype frezzes though when the script (L 1 17 : TR.PULSE I) ist still firing to a not known address range while reading out the now active Cycles on that Ansible at the same time. Just switching to Levels unfreezes it again (still adressing a not valid address range with no problems).

Now to the strange finding: Switching Ansible to address range four (pressing preset and both keys) shows irrational behaviour as at the first trial with the above mentioned script on every trigger in one of the trigger outs is firing, then the next one and so on - not all at the same time as on teletype and the first Ansible but one after the other.
On a second trial to rproduce this and a loop range with I going up to 20, trigger out 18, 19, 20 are firing, 17 not…

Unusual.

#158

I can confirm now that everything that worked better with the new firmware and/or just two Ansibles does not anymore with Earthsea and Meadowphysics back in the case. A TR.PULSE to not known adress freezes teletype as a little more i2c activity does too.

:disappointed_relieved:

#159

I’ve just tried a TXi firmware build with the pull up enabled that @bpcmusic kindly supplied me. That has fixed the lock ups on non-existent addresses. I haven’t given it a serious work out yet. Next up I’ll have a go at wiring up the remaining Monome modules (Trilogy + Ansible) and see how we get on.

Will new Teletypes be built with 2K instead of 10K?

Otherwise what are options for getting overall resistance down to 2K? A hardware dongle with access to a 3.3V line? Or can we get away with enabling a few additional pull ups in modules? (These would all be in parallel right?)

Do we know the pull up resistor values? I think for the Teletype and Ansible it is ~15K and for the Trilogy it is ~19K (source: page 37). What about the Teensy?

#160

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)

3 Likes
Ansible 1.4.1
Ii bus board, v2, with pullups
#161

So 10K in parallel with 15K would be 6K right? (oblig. xkcd)

Hopefully I’ll have time to give the new TT firmware a test tomorrow.

2 Likes
#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