In terms of the ergonomics, I found trying to get 3 modules connected to TT and the previous I2C board tricky enough with my current set of I2C cables.I’m wondering if the bus board would be better than a mezzanine solution? Of course, I could also just make myself some longer cables.
I actually think the ideal is to have both designs available. The best very much depends on the design of the case.
It’s also important to emphasise that whichever solution you choose, beware of short circuits.
Yes, dummies on the not used males could be smart - would be a bummer when it falls off the tt in a portable case and then touches the power distribution…
That’s the good thing about ribbon cables!
So, I ordered a v1 bus board just a bit ago. Sounds like the limit for that is 4 devices?
If I wanted to use 2 Ansibles (1 for grid, 1 for arc), a White Whale, a TXo and a TXi, do I need the v2 bus board? I suppose I might add Earthsea at some point as well, oh, and Just Friends, almost forgot about that…
Definitely interested in the v2 bus board!
I’m wondering if you could connect the mk1 board to the mk2?
ok-- i think this will be the “final” teletype ii expander. connects directly to the back of the TT. 12 headers. power pass-through. i2c pullups set at 2.2k, bringing total i2c pullup resistance to 1.8k. notched for access to reset switch (if you’re programming the firmware and added the switch, that is)
the regulator and resistors are in the middle of the sandwich:
$15 for 3. i just ordered a batch for testing.
here are the source files: tt-i2c-v3.zip (18.7 KB)
of course, now that i’ve ordered, it seems like this board should have the i2c connectors rotated to 90 degrees so cables escape vertically, not stacking up in layers horizontally. opinions?
I’m having a hard time imagining the orientation of the board relative to the teletype because I’m not looking at the back of my teletype right now. But it would be nice if the cables were oriented the same way on all devices, with the ground in a consistent position. (Though I believe Ansible is the odd one out on the position of ground if I remember correctly?)
that’s a good point. perhaps each row could be a different direction. i find a single fold tends to make routing easier…
@tehn - thanks for putting these together. I’ve ordered a set of each from OshPark to test out. Both look great - I’m excited to experiment with them.
Just adding myself to the list of interested people. I don’t need this white yet, but once the txo/txi are ready I’ll be up to 5 modules on my tt.
Wondering if I’m in a risk zone when using TT with JF + 2x txo + txi…
Maybe I missed something, but there seems to be vague info if any particular devices do affect this issue more or less… or are they all the same?
It seems to be a bit try and error with all individual configurations.
I think for the price of the new bus boards everyone just should get one, at least when it has been confirmed solving the issue.
Mine should be ready to ship in 2 weeks according to Osho.
And as the smaller ones only come in packs of three there should be a lot of spare boards pop up in a few weeks, finished by some happy DIY’er.
When/how can we order them?
Just finished building my backpack…
It hasn’t fixed my Teletype lockup issues unfortunately. I have 1x Ansible, 2x TXi, and 2x TXo connected.
My Teletype freezes after about 10-15 minutes of running. I’m testing with the Jumpy Edges TT Studies patch, but with different M and I scripts.
Script I sets M to 50 and sets TXo’s CV outputs to 0. M runs every 50 milliseconds and sets the speed of the TXo’s gate outputs.
I’m using Sam’s beta 2.0, as it’s the only firmware where I have access to the expanders and working USB read/write. I had lockups on 1.4 as well before I upgraded.
Replying here rather than on the other thread.
What messages are you sending over the i2c bus? Can you post your script?
Sure thing!
I:
L 1 8 : TO.TR.M.ACT I 1
M 50
M.ACT 1
L 1 8 : TO.TR.M I MUL I 150
L 1 8 : TO.CV I V 0
M:
X SUB 320 RSH PARAM 6
L 1 8 : TO.TR.M I MUL I X
(Yes, I could remove the last two lines from the I script. That shouldn’t affect anything, right?)
I’ve ran your script on 1.4.1 for 30 minutes with the param knob at 50% (after wiggling it around a bit). I’m not triggering any of the jumpy edges functionality as I’m not sure how you have it patched. But, just the metro script running is not causing any issues whatsoever.
I’d investigate the following questions to determine if it is your bus, the 2.0 firmware or the interaction with the TXo:
Q1: Is the bus board working properly?
You can check this by plugging only the bus board into the europower supply. With no devices connected, check the voltage on the two i2c pins.
In the above diagram, pin 3 is the ground pin. You want to measure pins 1 & 3 and pins 2 & 3. Each should read around 3.271 volts.
Q2: Do simpler scripts fail
Try simply blinking your TR lights and setting random CV values.
I Script:
L 1 8 : TO.TR.TIME I 50
M 75
M Script:
L 1 8 : TO.TR.PULSE I
L 1 8 : TO.CV I V RAND 10
Try running that at rapid M rates and see if you get the same locking behavior. This will help you identify if there is a problem with your specific script or configuration.
Q3: Do calls to non-existent ports fail?
This was the revealer for me. Calls to ports that aren’t on the bus (either TELEX or Ansible) would cause the Teletype to quickly lock when the pull-up values weren’t proper. Send commands outputs greater than 8 (TO.TR 8+ / TO.CV 8+ / TR 8+ / CV 8+) and see if you don’t get a near-immediate lock up.
Q4: Does your TT lock on the 1.4.1 release?
This will help us rule out 2.0 vs 1.4.1 differences. Downgrade your TT to 1.4.1 and then try to run the same script. Let us know what happens.
Q5: Does wearing a hat help??
Try wearing a number of different hats while using your teletype. Not just any old baseball cap; really dig deep into your closet. Get out that old Fez and/or Ushanka. Bonus if you wear mismatched socks as well. (Stripes and polkadots are usually very revealing in these cases.)
Kidding.
Let us know what you learn!
Thank you so much for the extremely detailed troubleshooting checklist. I’m going to run through these throughout the day.
I just tried out Q2, and it failed after about 15 minutes. I added a script to 1, triggered by one of the TXo outputs. It simply called:
TR.TOG 1
Two interesting notes…
-The light on TR 1 seemed to stutter. It didn’t appear to be perfectly metronomic like the TXo output.
-When the Teletype finally locked up, the TXos somehow reset to my previous I script. My basic clock divider + Jumpy Edges script is in the post above, and is saved on TT address 8. I saved your basic testing script on TT address 9. It’s almost as if TT address 8 Script I was called on failure, if that makes sense. Oddly, only the TXo TR outputs seemed to be moving. The TXo CV outputs were held at their last CV value when the TT crashed.
I’ll try Q3 next.