txo missing pulses

I have a txo that I realized sometimes misses TO.TR.P. It takes a while for it to happen, and it seems it involves switching scenes on TT. After reboot everything is fine again…

  1. rings a bell, experienced something similar, found a fix/work-around?
  2. smells a bit like the i2c bug on the er-301 that was fixed a year ago, esp since I seem to remember Brian/OD modeled the code of his i2c units from the txo code.
  3. can we agree that there’s no such thing as “set probability of trigger” on device level on the txo?
  4. is there a way to debug/inspect the state of the i2c bus when the problem happens? a way to “reset i2c bus to same as after reboot”?

sounds like a typical i2c bus being unreliable. i would try and do the regular i2c debugging - disconnect everything else, try shorter cable etc.

no such thing, correct.

you could use UART to print debug messages (or use a variable as a way to communicate debug info and watch it on live screen). you could also use an oscilloscope that can decode i2c if you’ve got one.

not as far as i know.


If I should optimize the cables on the bus, besides making the cables as short (and impractical) as possible + experimenting with different connections/configurations (star configuration seems better here contrary to common recommendations), which cable features would be optimal? For instance should AWG be high or low?

I guess we’re all running i2c on cheap jumper cables meant for bread boarding, maybe getting “special”, more expensive cables targeted at low capacitance data communication would be an improvement?

Ok, this is obviously above my pay grade, so even less idea what I’m talking about than usually, but it seem to me that resetting the i2c bus would be super handy. Like (in my dreams) a tt command: I2C.RESET on the teletype.

I do understand that the problem is introduced by slewed rising/falling edges of pulses on the bus (possibly due to too high capacitance), but I don’t understand what it would take for an “unstable bus” to become stable again. Reboot fixes it, is that more to do each device being in a scrambled state? If so, it’s not the bus as such that’s in an unstable state, but each device. In such a case TO.REBOOT would be helpful.

Note: This is not only to fix my problem, but ways to interact with an “unstable” bus, would remove a lot of guesswork from helping people with trouble potentially originating from the i2c bus. Currently it normally amounts to “too many devices” and/or “use shorter cables”…

Real-life story: I experienced massive problems with triggers being delayed after a while from tt to er-301. Everybody was telling me I had too many devices on the i2c bus. After a lot and back and forth, with me providing test data + other users eventually reporting the same issue, Brian (O|D) stepped up (as he usually does) and found + fixed an issue in the er-301 fw (closed source at the time). The thread on O|D forum is here.

this is a good question but i don’t know the answer - i’m much less familiar with the hardware side of things! might be worth asking in this thread: A user's guide to i2c

not 100% sure but i think the spec doesn’t cover this. if you do a search, there are various solutions being proposed (i recall seeing a blog post somewhere about a sequence of steps you could execute to recover i2c bus) - which to me says it’s not a trivial task, even more so when you consider that different implementations might not cover some of the spec these solutions would rely on.

i don’t know how feasible this is from the hardware side of things, but a dedicated i2c hub could help perform this function and could monitor i2c bus health (measuring fall/rise time and monitoring connections). i mean some custom solution somebody would have to design. and even in this case you might still have a problem if an i2c device is keeping a line low - there is nothing you could do to fix that if i understand correctly.

re: er-301 - without knowing what was the issue impossible to say whether the fix would apply to telexo. were there any other details shared about the fix?

as noted above, this is not a meaningful concept in the i2c spec.
i2c is only two wires and any device can hold them low.
“resetting the bus” just means resetting the state of every device/peripheral that is attached to the bus.

of course one could create a dedicated reset line or something outside of the spec.

1 Like