recovering from a corrupted bus is not a trivial task, and even if teletype supported some form of it it wouldn’t necessarily work with some followers (depends on how i2c is implemented on the follower side).
Ok, I’ll have to trust you on this one,
Ok, I agree it doesn’t sound too promissing (although I’ll try it out), esp if by freezing you mean “locked up, not responding”, cause this has never happened here…
Thanks anyways so far, no high hopes, but maybe the two alternate firmwares will behave better.
In any case, I might have to adjust my coding practices, and keep an eye on the results in the long run…
i thought you meant by this tt locks up until you reboot it. in any case, it should behave better now since i2c bus getting corrupted (or follower devices responding slowly) should affect tt much less, which is the better option that tt misbehaving.
as @zebra said, poor bus conditions can result in clock stretching which would explain what you were seeing. the experimental beta should prevent this from affecting teletype, so you should just get skipped i2c commands - once you have a chance to confirm it works this way now in your scenario (which i can’t reproduce since there are too many variables in each i2c setup) then try using shorter cables / disconnecting some of the modules from i2c and see if you can get a more reliable setup.
Thanks!
As you can see on the first video I posted TT is still running and reacing to input, but messages are totally all over the place. Never had a lock up!!!
One thing I thought, but forgot to bring up: could it be the pullup resistors that might need to be adjusted in size (I have latest 301 + TT + atm 1xTxo from I believe last batch)?
do you have an i2c backpack?
not sure tt alone provides the proper value for pullups in this setup. and it’s not easy to say whether the pullup value is okay without an oscilloscope.
No backpack. As far as I understand, the new-version TT doesn’t need a backpack
in this case you should be good (to confirm, you have a black PCB TT?) - but again, it comes down to a specific configuration, and the only way to confirm i2c bus is healthy that i know of is by looking at it with an oscilloscope. try connecting only er-301 to TT and keep the cable as short as possible and see if you can still repro the issue.
If it comes this far, could you provide a link to where I can read more about how to perform this inspection? I might be able to visit a friend with an oscilloscope…
Thanks, looks great!
Hey!
I did not have time to test the new firmware
someone has tested it?
Just posted a handy tip over on the Orthogonal forum and figured it would share it here to. Basically, if you are driving your i2c bus super-hard trying to read and pass along values from the 16n, you are most likely stressing the heck out of the i2c bus. You are bound to have weird issues over time. (As clearly noted above.)
What has worked for me is reducing the 16n “sampling rate” (number of times I read from FB n ) and implementing slew on the output it is piped to. This reduces the stress on the bus and still gives a smooth-feeling response on the output.
2 Likes
I need to try that. What sampling rate and slew rate would you recommend ? More than 100ms ?
It really depends on the feel you are looking for (how responsive you want it to be) and how much other stuff you are doing. If you make the slew and your read/update rate the same, you should get good results. 100ms is a good place to start. 
2 Likes
Thanks, I will try that
a good way to dial in the feel you want is to use the knob to control the rate.
2 Likes
Where should I change the samplig rate of the 16N? In the wirmware?
I’m using a SWEET SIXTEEN to transform CV values into TELETYPE readable values with the FB command, but the values always doesn’t corresponf with the CV sent. There is some kind of delay updating the values, a thing that doesn’t happen when using the IN jack of the TELETYPE. I don’t know if this is a problem of the SS, so I’ve ordered a couple of TXi expanders to check if they are faster than the SS. But if I can do something to change the code and make it more responsible it would be great …
Since I was the OP, I should say that this bug has been solved by Brian on the er301 a few firmwares ago. Posting this here might be overdue, but OTOH the evasive nature of the bug suggested a longer period of stability should pass before celebrations. But as far as I’m concerned the original bug is fixed, i2c has been running super stable since the fix on the er301!
Unfortunately I can’t edit the original post…
2 Likes
In my reply, I was referring to the read rate of the Teletype Metro script that is used to read + transform the values. Reading over i2c on the Teletype is not continuous, it takes place at a specified interval. You can use a metro script to trigger this. You can speed the metro up to 25 ms with the basic metro command M 25 and go even faster (with risk to stability - depending on what you are doing) with the experimental metro command (e.g. M! 10). The faster you sample, the more “accurate” and responsive your values will be.
1 Like