I have a simple rack being driven by a teletype…stock keyboard. After a while the keyboard and front panel switch stops responding and it takes a power cycle to get it to start responding. What might be causing this? I don’t think it’s power…the rack’s draw is within uZeus limits. Power Consumption: 794 mA +12V | 367 mA -12V | 41 mA 5V
I’ve been experiencing a bit of that lately. Not so much that it stops responding completely, but sometimes the CV outputs will stop updating or the Gate outputs will hang high. Switching scenes or issuing a TR.TOG will get the gates to go low - but on the next TR.PULSE they hang high again- while the CV outputs continue to remain unresponsive to commands. Only solution at that point has been a power cycle. I’m running 1.4.1 1.3.2
Odd thing is, I’ve been using Teletype for live performances and composition pretty actively and this is the first time this bug has come up consistently. I just switched over to a new case with the Intellijel TPSW80 - so plenty of power. Only other change I can think of is that I reconnected the i2c bus cable between TT and Earthsea - but in all my recent TT hang-ups I haven’t been using any of the i2c commands. And when I do use i2c to clock Earthsea it’s been very steady and reliable.
I’m seeing that behavior as well (manually toggling to low simply goes low and jumps right back to high.)
I’m running it bare with no connection to other monome modules. I’m using it in an installation and it’s basically running all the time…so a couple times a day I have to cycle it. It’s somewhat annoying.
BUT it’s entirely possible that the scripts I have in it are the culprit…maybe something in my commands is leading to (over time) a weird state in the module?
Yep! So far, we’re in the fifth beta round and it’s pretty stable. @sam is doing killer work. I’ve run scripts for 3-6 hours. The only bugs reported after running scripts for that long is that occasionally the keyboard needs to be reconnected. In one instance, the Metro script turned off after 6 hours for @tehn, but it could then be re-enabled instead of locking up completely. You’ll need to back up your scripts onto a USB stick before updating, though.
Yes, this is a known problem. I think it started somewhere with 1.4 here.
@tehn I did not experience it with the new 2.0 Beta by now.
Though @sam is constantly working on it, reported bugs get a quick fix soon and the discussion on the development seems to be pretty informed ( I don not understand much of it) I would not consider the stability of the new firmware as rock solid atm. But there are some very nice features in it already…
EDIT: After a second thought I think it started with the new powered i2c board and the idea was that it was somehow masked by the i2c bug before.
I need to check , but i think i’ve encountered this issue lately.
I was i the urge of presenting this for an installation and ended up using gate B instead of gate A without further investigation. I’ll check when i have 5 minutes…