#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:

#21

i just successfully modded my er301 and used the backpack i2c expander i ordered from @bpcmusic to connect my teletype, w/, and ansible. while i was screwing in modules, half moving them, all connected modules had a power flicker for a bit and freaked me out. i screwed everything in, works fine, but i’m thinking i might just have to zip tie the backpack cuz this is my performance case.
otherwise, it’s working awesome!

i have had my keyboard not be recognized by teletype both before and after this i2c business, as well.

#22

Bumping for an unrelated issue, figured I would spare making a new thread.

My friend has a Teletype running firmware 2.3 beta that has an unresponsive USB port. The module will boot normally and I can select / load scenes with the panel button and param knob, but it will not recognize a keyboard or USB drive to backup scenes. Both the USB drive and keyboard are confirmed to be working on my Teletype.

I just replaced the USB jack thinking maybe it was a hardware problem, but the USB port is still unresponsive. I can access the bootloader so I was going try updating the firmware next (if the module responds), but I’d hate to lose the scenes… does anyone have any alternative ideas for a fix or to backup the flash memory before we attempt an update?

1 Like