#182

@sam - the teensy can go way beyond the 400kbps rate, but I’d locked them all to that in their config during our initial bus testing to rule out the auto-negotiation as a factor. I haven’t measured the real-world rate in any scenario. All I know is that, with the appropriate amount of pull-up, the thing is still screaming fast!

@Leverkusen - from the perspective of the expanders, this isn’t a code issue anymore but one of having the appropriate amount of pull-up resistance for your bus to counter its length past the 4ish devices that the current bus configuration supports.

@tehn’s new bus board should solve it quite nicely for larger configurations as my TX firmware hack really only got things into grenade range.

2 Likes
#183

@bpcmusic I’ve rad this a few times now and I seem to not understand it right - does it mean 4 modules connected to teletype should work or 4 modules as in teletype and three other modules?

#184

I haven’t tested the combinations of various modules to identify where the breaking point is. Different modules, lengths of cable and other details may play a part in where someone will need additional pull-up on their bus. Best I can suggest is to experiment with your own configuration.

For larger configurations, get/make a bus board and you will be off to the races!! :slight_smile:

#185

From reading through your issues across the different threads it seems like you would definitely benefit from the new bus-board / mezzanine / resistor-mod. I know you’ve had issues with Earthsea which I don’t think this will solve, but I believe it will help with your issues involving Ansible.

1 Like
#186

Thanks for the confirmation - I ordered the v1 of the v2 busboard and will try it out.

:+1:

1 Like
#187

I tried the new bus board with the pull pup resistors but it does not solve the issues I have.

Instead teletype does weird things now as hanging outputs (not the ones connected to i2c but its own CV and trigger outs) and display errors.

I am not sure which firmware I should use now with the bus board. Official is 1.4.0 but there seem to be different 1.4.1 versions around.

Can someone point me to a teletype firmware that is supposed to be the one that works with the new bus board?

#188

the bus board is certainly not causing new issues. it’s likely just revealing other issues now that the i2c is working on the electrical level.

i’m sidetracked with a few other priorities before i’ll be able to check back into the state of TT.

1 Like
#189

(continuing the discussion from [another thread][thread])

[thread]: Ii bus board, v2, with pullups)

Looks like we’ve got another i2c bug that needs fixing, as discovered by @trickyflemming, I think @Leverkusen has also confirmed it too.

Minimal failing example:

Scripts 1 through 8 are empty.

#I
M 50
M.ACT 1

#M
TO.TR.PULSE 1

Connect a fast trigger to input 1. The M script just needs to send a packet out over i2c, so it could also talk to Ansible or a non-existent module.

I’ve posted some theories on the [other thread][thread], but let me repeat them here:

Tagging: @tehn @scanner_darkly @bpcmusic, I’m not set up for debugging i2c…

2 Likes
#190

Quick question: is it any i2c command in the M that will cause the problem? In other words, would TR.PULSE 5 also cause the problem (with no Ansible)? Accurate, @trickyflemming?

#191

@trickyflemming tried the following scenarios out for us

  1. Pulse TXo
#M
TO.TR.PULSE 1
  1. Pulse non-existant TXo
#M
TO.TR.PULSE 9
  1. Pulse Ansible
#M
TR.PULSE 5

All 3 fail with a trigger connected to input 1, and work if there is no trigger.

I don’t know if he explicitly tried a non-existent Ansible output. Or even one of the older II commands. Would be worth a quick go if someone has the time.

1 Like
#192

@tehn @sam @bpcmusic

I can confirm the minimal failing script. It runs for over 30 minutes and crashed after 1 minute twice when a trigger gets patched in.

I sometimes experience little hickups in the script when I switch from live to edit mode and back. Also are the hickups on saving scenes expected normal behaviour? Probably yes as the other modules show them too.

Cannot say anything about the regularity of the display glitches yet. Of course when I had the new bus board freshly built in I tried a lot of i2c stuff with M and triggered scripts. They are a bit harder to find though as you have to change the display view for getting them - not just start a script and wait for the crash while doing something else.

2 Likes
#193

just a quick note to say - i’ll be traveling for the next 4 weeks, so unfortunately won’t be able to help until i’m back (traveling super light, so no monome gear with me).

from the description does sound it could be a new bug…

#194

@tehn @sam @trickyflemming @Leverkusen

Ran the script for over an hour with triggers patched. Totally stable for me. Even added corresponding trigger pulses on the TT’s triggers for the script and turned on the TX’s pulse divider to make it more complicated. Solid.

Sigh. Kinda wish it would have locked up - at least things would be consistent.

I have 4 TXo, 2 TXi and 1 Ansible connected to the Teletype.

#195

Poop.

I’ll make some time to try it over the weekend.

#196

I should point out that I’m running 1.4.1. Video was at M 250 - ramped it to M 10 this morning and let it go for five minutes. Keeps on chuggin.

#197

I am carefully following all the threads devoted to these issues, as someone who has all the modules, and hopes to add the expander…

I have experienced locking up issues with ES and WW before, so much so that I sort of have given up on trying to use TT in conjunction with the trilogy. @tehn was extremely patient and generous with his help, including shipping alternate modules and even cases!!!

But, I am hoping that this all gets sorted out, and some stability is found/regained.

Something that I was frequently suspecting to be a factor, is the electrical stability/context for the monome modules in these configurations. Are you guys considering the power context for the tests? In terms of for example: is the user case maxed out, or on the edge of available power? Grounding issues and potential affects of other modules in the case?..

Anyway: am grateful you guys are going strong on this, and wishing you all the sweet taste of victory which comes with overcoming mysterious problems!

4 Likes
#198

Hm, firstly I am very thankful for your contribution! While I feel a bit irritated that these issues seem to be known and discussed in disguise to an extend that people stopped using the i2c features whereas they still got promoted and further developed in the open it is somehow relieving to see that there are actually more people experiencing this and the discussion gets more open.

I love the monome system and really hope we can figure out a solution. Since the promised land of complex remote control was the deciding reason for me to get into all this and replace all my former sequencing/clocking/CV control modules I would happily contribute all I can to the process of exploration and debugging to eventually get the ecosystem running stable and reliable. I can’t imagine playing live with it atm which is a shame cause I would love to!

Regarding the power context:

I tried teletype, ansible, earthsea, meadowphysics, switch and a grid in two different cases, one with a linear Doepfer PSU2, one with a Make Noise distro board and the external PSU they sell with their systems. None of both have been stable with i2c and I got lockups and periodical earthsea slowdowns. I even took out all other modules form both cases with no success. I don’t know much about general electricity contexts but I’ve read it is pretty stable in germany - as you might think everything is statutorily regulated over here. For convenience and safety I run everything in my studio from a furman PS-8RII power sequencer.

The current system is extended with a second ansible/arc and sits in the case with the doepfer psu2 now together with Maths, Optomix, Twiggy and a Verbos line (CO, HO, ATC, multi-envelope). It is fully analogue besides the monome modules and uses about 890 mA max of 1200 mA. I have had two digital modules in that case that could not cope with switched power (which made me build the extra case with linear power) but taking them out made no noticable difference.

@bpcmusic

When I get lockups in minutes with the minimal freeze script I seem to use a faster trigger rate into teletype than on your video. But I had a slightly more complex patch (as described somewhere above) freeze after about 30 - 60 minutes that was very slow in every sense (M and trigger input) too. I assume that the probability of a crash just rises with faster rates.

If there is anything I could try over the easter days I have some time and would do it.

@tehn [quote=“tehn, post:188, topic:5861”]
the bus board is certainly not causing new issues. it’s likely just revealing other issues now that the i2c is working on the electrical level.
[/quote]

Could it be that I made a mistake building the new bus board? I would think it would not work at all then instead of being not much of a difference, right?

:rabbit:

#199

i’d not make assumptions about wider issues-- there are people using these features without issues.

have you been attempting to use the remote commands in a musical context? or have you simply been focussed on testing situations of maximal message throughput-- with the assumption that if the full-on test fails that lesser cases will also fail?

previous issues with ES sync (which laborcamp mentioned) are now fixed-- so i’m confused why you’re bringing it up-- is yours not fixed?

the new bus board puts the i2c lines within spec. it does not break anything. it eliminates a likely problem.

i’ll be able to dig back into this next week.

#200

@tehn

Yes, I mainly attempt to use remote commands in musical contexts. But it is not stable enough as it tends to freeze within 30 - 60 minutes. Seems to be related to the used clock speed but I never use unusual high speeds, even when I am just doing a test since we already came to the point in this thread that this would not make any musical sense. I promise I am not just trying to prove your system wrong!

Regarding the ES sync issues: I bring this up every now and then, then you reply that it is already fixed and I reply that it is not. It looks like this with a steady clock on teletype with actual firmware on both. The slow down is not intentional in this video and it appears periodically about every 4 minutes:

Regarding the new bus board: My point was not that it might have been wrong to build one! My point was if it could be that I did not build it properly so it would not fix the i2c issues but still kind of works as it was before with the unpowered bus board?

#201

Not my favorite question :confused: Yes, I’m trying to use it for music and not finding pathologic failure states (and that’s ignoring the deeper implications of what a “musical context” means in an open-source sequencing environment plus whether these aesthetic and computational boundaries should be defined in the documentation).

The patch that I started with is Teletype Studies #1 with an added Metro script for the TXo. The Metro speed is fast, but slower than its limit and slower than what @bpcmusic demonstrated in his tests.

The patch that we’ve whittled it down to is extremely minimal. Literally one line on a Metro script and nothing else (see @sam’s post above: Teletype Firmware i2c Debugging). It fails when a trigger is received on a blank script slot (really, any script slot, but we at least know it’s not because of an over-complicated script).

1 Like