#1

I’m preping for a gig tomorrow and my Teletype has started crashing within a few seconds of restarting. By crashing I mean that the keyboard stops working, in some cases the patch appears to still function, othertimes it seems to lock up completely. I have TXo and TXi hooked up to it and Ive double checked that they are all intact and correctly attached. I’ve had very few issues in the past with Teletype in this exact configuration and am wondering if others have come across this issue? I am running an older version of the OS 2.0b10:5427406 - I’ve been meaning to update but can’t find a usb that it will read to save my patches and haven’t gotten around to it as yet - it has run very stable for the past 8 or so months though.

Just wondering if others have come across a similar issue and if there are any known issues I might be triggering?

Any help is very appreciated!

#2

most of the teletype crashes i’ve experienced seemed to be caused by bad i2c connections, usually if my TXo or TXi’s second PCB became unseated. Have you tried completely disconnecting all the i2c devices and seeing if that gets you up and running without a crash?

#3

are you using a tt busboard? how many i2c devices?

#4

have you recently change your scene? do you have any remote i2c commands in your init script? if so, try disabling them and see if that makes a difference. if it does, try moving them to a different script and then call it from init with DEL 2000:

1 Like
#5

Do you think it may be the same thing I discovered with the i2c commands in the I script?
Were you able to reproduce this?

#6

yeah, i thought it might be similar to what you experienced. i think i saw something similar once as well but didn’t investigate much.

#7

I see.
I wonder how this could be addressed (IF it can be addressed).
Would that be the way TT handles things or the way the i2c devices do.

1 Like
#8

hard to say. investigating something like that is difficult (as you can tell by the previous threads discussing i2c issues). i recently did a scene that initializes 4 TXo modules, sending 48 remote commands, with no issues.

if the problem is indeed i2c related there is an easy fix, as mentioned, put it in a different script and call it with a delay. alternatively, a delay could be always applied to the init script so that it executes a couple of seconds after loading a scene but this might be undesirable for other reasons.

1 Like
#9

Right.
Totally understand, especially if something is hard to reproduce. But reading this here made me think that perhaps others experienced the issue.
The delay, and/or moving commands out of the I script seems more like a “workaround” than a “fix” though. I certainly am glad that there is a way to avoid the freeze in this instance anyway.

#10

It’s a shot in the dark, but is it possible that you’re reading past index 32 on either a TXi PARAM or IN? That would explain why it takes a few seconds to lock up if it was something like a counter that wasn’t getting reset. This bug was fixed recently.

#11

ooo - just caught this. @alexwhite - did you figure out the issue? The others offer some good suggestions (unseated i2c or out of bounds call to the TXi with your firmware). You can also try disconnecting the i2c and/or quickly typing M.ACT 0 to see if you can stabilize the Teletype so you can troubleshoot.

Once things are less stressful, I recommend you back up your scenes, verify the backup, and then get everything upgraded to the latest firmware (maybe even the grid beta). If it is an address bounds issue, there definitely are fixes in place in the latest TT firmware to protect you from calling unsupported inputs and outputs.

#12

Thank to everyone who has had a crack at this. I’ve worked out that the crashing only occurs when I had cv from the TXO controlling more than one thing via a stackable (likely a mult could produce the same behavior but haven’t had a chance to test yet). I would get continuous crashes or even failure to start with screen still blank with power on.

Could this be an earth loop issue or power draw?

I’ll update to the latest and let you know if the behavior persists. Thank you for all your help!

#13

Sorry to answer your questions:

No busboard in use
No I2c commands
The TXO and TXI do seem to lose their 2nd boards after travel sometimes but have been double checking them and they seem securely seated.

#14

Very strange. I’ll look into replicating - though I need to get a passive mult as I only have buffered ones. Give me a bit to swing by Analogue Haven or to order something.

You could solder them down or put string, zip tie, or equivalent around them to secure them together better. My road units (in the lunch box) are zip tied together. :slight_smile:

#15

Gave stacking a shot on a non-busboard Teletype with a TXo and a TXi. 3 TipTop cables patched from the TXo to the TXi and O’Tool. Lots of random voltages going all over the place. No issues. Baked for 30 minutes.

I’ll test a busboard enabled rig tomorrow.

:slight_smile:

3 Likes
#16

Ok; I took a Teletype with a loaded busboard (4 TXo and 2 TXi) and passively patched the everliving snot out of the 4 CV outputs of the TXo using stacking cables and a passive mult (16+ destinations). The thing ran super-stable for over an hour.

I have a feeling that something else might be going on with your system. I’m guessing some bad grounding or messed up voltage mixing that was going beyond the rails in the patch.

1 Like
#17

I just experienced a “freeze at startup” even with the DEL 2000 “workaround” moving everything out of the I script, and delaying it for 2 sec.

This on a patch that worked well repeatedly for few days.

The only thing that changed is that I added a cross-case connection from Pamela’s New Workout in one case (same case as housing the TT in question) to 4ms SCM in another case. No idea if that has anything to do with the freeze or not.

But it did happen. :neutral_face:

#18

what was er-301 doing when the freeze happened? is the freeze reproducible?

it probably makes sense to wait for the updated er-301 firmware before investigating further (i’m not sure the latest er-301 firmware release has the fix brian mentioned he was going to do).

#19

Thanks for testing and for the zip tie trick, I’ll definitely give that a go! I suspect you are right and the issue is more about some kind of ground issue. Incidently the module that I was connecting to when the issue occurred was a 4MS QCD. I’ll hopefully get it fired up again next weekend and see if I can narrow the issue down a bit.

#20

I have a few of the 4ms units from a similar time period in their build history - including some early DIY that I muddled through. I’ll throw them in the loop soon and see what happens. :slight_smile: