#41

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?

#42

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.

:+1:

#43

they arrived, they work.

IMG_3137.JPG1200×1200 247 KB

IMG_3135.JPG1200×1200 373 KB

IMG_3136.JPG1200×1200 337 KB

12 Likes
#44

When/how can we order them?

#45

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.

Telex: Teletype expanders
#46

Replying here rather than on the other thread.

What messages are you sending over the i2c bus? Can you post your script?

1 Like
#47

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?)

#48

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.

busboard.png920×861 497 KB

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.)

:wink: Kidding. :wink:

Let us know what you learn!

3 Likes
#49

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.

#50

Tested Q3 by slamming it with out-of-bounds calls in live mode. No immediate crashes there. I sent the following messages about 30 times each with no lockups:
TX.TO.TOG 9
TI.PARAM 9
TI.PARAM 18

#51

The importance of a large wardrobe of hats and socks is critical for debugging. Little known fact that really should be much more emphasized in today’s computer science and electrical engineering programs.

2 Likes
#52

Can you try writing an M script with those and leave it running?

#53

Well here’s an interesting data point… I’ve been running an M script with the following:

TR.TOG 1
TO.TR.TOG 9

It’s been chugging away for a solid hour without crashing.

1 Like
#54

@trickyflemming - interesting. But, what hat were you wearing?? :wink:

My gut feeling is this isn’t bus related, but something else. Especially since your Q3 test came up clean.

I had worried that there was something with the TO.TR.M implementation in the expander that was unhappy with the high frequency manipulation (updating every 50ms) - it might be able to hang the TT with a catastrophic error. That you still got the hanging with the simpler command (via Q2) suggests that this isn’t the case (as well as the fact that I couldn’t get it to hang).

Might want to try the tests with one of those vizors with the integrated spiky blonde hair and see if that helps / hurts.

–

I should point out that the expander’s implementations of metronomes and oscillators run externally to the Teletype once initiated. The TT can hang and the oscillators and trigger metronomes will continue to go on forever. They also do not reset on preset swaps on the Teletype. You need to either turn the features off or initiate a reset command to turn them off.

1 Like
#55

No hat, but I switched from striped socks to solid. My Teletype is currently facing East, if that matters.

What I meant by the TXos continuing to function was not that they should have crashed, but that they strangely changed scenes, if that makes sense. It’s almost as though the I script on the previous TT scene was called when it locked up. They went from simultaneous blinking with random CV (scene 9) to clock division and static CV (scene 8). I’m wondering if something is overflowing somewhere, and scene 8’s I script is getting triggered as a weird side effect.

Is Q1 still useful at this point, or should I investigate Q4?

#56

I haven’t had time to build mine by now but I wonder if there are any positive experiences too where the new bus board solved issues that have been there before using it.

We could tell then if this case is some kind of singularity and an individual solution has to be found or if there still are issues that don’t get solved by the changed pull up resistance.

Anyone tried changing the resistors on teletype yet?

#57

I don’t understand why you are suggesting this, when the powered bus board has been developed by people that understand more about the issue :slight_smile:

#58

I do not understand what kind of suggestion I made to anybody with my post?

The bus boards have been introduced as not tested but expected to solve the remote issues. So what is wrong about asking for more feedback to understand if they really do?

#59

@bpcmusic and @sam: I tested Q4 (downgrading to 1.4.1) tonight. It crashed after 8 minutes of running the TO + Jumpy Edges script.

There’s not an official 1.4.1 binary on the Github release page, so I used the one posted by @tehn here: Teletype Firmware i2c Debugging

#60

The most helpful you could be is to build your bus board and provide another data point! That will certainly push us towards clarifying that the bus board does indeed solve the problems people have been having.

3 Likes