#1

I’ve spend most of yesterday and all of today trying to get closer to my teletype/301/i2c problem (sometimes some i2c triggers are delayed exactly one M cycle), I’m still hoping to produce a teletype scene + an er301 quick save that will trigger the problem, but it’s hard, since it seems it takes some unknown ingredient to trigger the problem.

Anyways, the strange experience was:
Yesterday while working on a track, the problem appeared, and I decided not to reboot (which is what I tend to do since it always fixes the problem and I’m in the middle of trying to make music). I poked around with the two modules for about two hours and found that sending to to all SC.TR with “L 1 99: SC.TR.P I 0” after every metro cycle made the timing correct again. Removing the line and it was all bonkers. I also noticed that while in the bonkers state, and looking at the scope, all triggers (SC.TR.P x from teletype) on the 301 showed up as just a spike (so extremely short, I assume 1 ms or less) and also that it wasn’t possible to adjust the length with SC.TR.TIME 1 20 (or similar). TO.TR worked just fine.

I looked at the teletype firmware, and although I don’t understand everything, it seems like SC opcodes are simply copies of (a small subset of) the TO opcodes, at least I don’t see anything odd there.

@odevices Any chance you could take a look at the i2c implementation in the 301 for me? Does this strange behavior ring a bell with you? Anything I can do to help (I’m still working on reproducing the problem reliably)???

1 Like
#2

It seems like the attached combo will trigger the problem, first a simple rhythm, then it speeds up, let it run for a while, F1 will slow back down to check it rhythm is bonkers or it needs to run some more, F2 will go fast again.

It’s not a real world example, but it should make the problem appear after an hour or two. If it doen’t sound off after a few hours, try loading WITHOUT REBOOTING an actual set of real life quick-save/scene, and I’m pretty sure it won’t sound like you expected.

i2c_reproduce.zip (15.2 KB)

1 Like
#3

Update: Seems that when in a state of bunkers, rebooting only the er-301 (from the firmware menu), makes everything align again.

#4

Here’s another one, this time a real world example, will trip over by it self here after running less than an hour…

every_step_matters.zip (938.1 KB)

#5

Thank you for the test cases. :bowing_man: I won’t be able to give them proper attention for a few weeks though.

#6

Ok thanks, I’ll be switching to patch cables in the meantime. Let me know if you have any questions or need my help in any way!!!

#7

Just wanted to chime in and say that I’ve also been able to get some weirdness with SC.TR.P commands as well.

My setup is using a Cirklon to send MIDI clock to my Transit module, which is then passing along the 24ppq clock via SC.TR.P commands. I’ve been able to send them at very high speeds with extremely low jitter (80Hz, 24ppq @ 200BPM). Unfortunately after some amount of time (seems somewhat random, but usually happens between 15-30 minutes) the clock becomes extremely jittery. I can still send SC.TR(.P) and SC.CV commands, but the timing of things becomes odd.

As far as I’ve tested, it’s an issue with the ER-301, since pressing the reset button on the Olimex daughter card fixes the issue, even with the Cirklon/Transit clock combo continuing to run during the reboot.
Once the ER-301 is rebooted and the quicksave is reloaded, the timing is rock solid again.

I’ve also attempted to just reload the quicksave, but it doesn’t fix the timing issue.

Let me know if there’s any other info I could provide to clarify the issue.

Stable Clock:
0008
Unstable Clock:
00120013

2 Likes
#8

Not liking it, but good to hear that it’s (probably) not my code that’s giving me issues :wink:

1 Like
#9

Obviously I’m also sorry for your troubles, but on the other hand I’m extremely excited that more people than me are facing this!

I hope this means it will be easier to generate enough traction to get to the bottom of this…

3 Likes
#10

Just wanted to (politely) check in to hear if you by any chance had an opportunity to look into this? It’s driving me mad (and we can’t have that, can we? :thinking:)

1 Like
#11

Hi. I can confirm that it happens to me frequently, and that only rebooting the ER-301 fixes it. I switched to 0.5.01 firmware to see if that made a difference but it has not. I have been using the ER-301 and Teletype much more frequently during the pandemic.

To further add, I don’t have to be doing anything with either the 301 or the TT to make the behavior occur. I can turn it on and wait and it will always eventually happen.

I am using the same script I uploaded to a previous thread [Metrotype :wink: ]. The ER-301 is ~51% load. Playing 4 samples triggered by teletype w/ a few different delay effects as well as 2 aliasing saw oscillators for a bassline (with several mixers, VCAs, and envelopes). Nothing too complex or even any custom units.

The incoming i2c triggers are not processed in any way and go direct to the trig slots of the samples.

1 Like
#12

Thanks for chiming in! Question: do you have anything else on the i2c bus besides tt + 301?

#13

Yes, I have a TXi as well. Note that they are not daisy chained but both discretely connected to the TT.

#14

I have tro (used to be one, but one is helping take some relief of the i2c) also not daisy chained. I wonder if people with just 301/tt are also experiencing this…

#15

I’ve been experiencing the issue I mentioned above with only my Transit module and 301, no other modules.

#16

Ok, thanks, good to know (although I’m not the one that’s gonna look at fixing it)

1 Like
#17

Thought I’d chime in with a bit more info that might help if this issue gets looked at for fixing.
Just spent a couple hours using I2C communications via my Transit module. This time I turned off sending MIDI clock so that it wasn’t getting 60+ messages per second, and instead was only receiving an average of 5-10 per second.
In this setup the issues described above (delayed propagation of messages sent to the ER-301 only on the ER-301’s end) took an hour or so to occur, as opposed to a matter of minutes when I was sending MIDI clock. Perhaps this might shed some light on why this issue is occurring.

EDIT: Of course I have to eat my words, the issue happened within minutes as I was typing up this post.

2 Likes
#18

Thanks. In any case, I think you’re unto something. Although there’s not a linear correlation, it does seem that the more busy traffic is on the i2c bus, the sooner the bunkers state kicks in.

1 Like
#19

May I ask everyone to retest their I2C setup with v0.5.02 please?

4 Likes
#20

I have a good feeling! to early to say, but nothing is inverted, missing or delayed