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?
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.
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.
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…
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.
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?
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 - 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.
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.
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)
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.
+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]
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?)