Telex: Teletype expanders

[sam]

Good idea on the TELEX module, I’d been thinking how awkward all these i2c cables were going to be.

[chapelierfou]

Reading the implemented commands list, i wonder :
wouldn’t it better to use, for instance, CV 5 instead of TO.CV1 ? This would make scripting more fluent, as if you were thinking your expanded TT as one big TT instead of a TT+expanders.

[infovore]

Have a squint at some of Tom Whitwell’s multi-board modules, eg, the new Turing Machine:

TomWhitwell/TuringMachine

You can, although it’s not obvious, cut paste between two schematics in EAGLE. So what I’d suggest is, first, work out what’s going onto what board - that might be as simple as looking at layout and space, or deciding all the stuff to do with the top layer - opamps and output resistors - goes on the top, as it were - and then break the connection at those points with a named net, if that makes sense. So, for instance: all your output jacks, a + and - power jack, a ground jack, all broken out to a net ending in a label - and then another label elsewhere to indicate how those nets join.

Then you can cut one half of the circuit into its own new sch/brd pair, and connect those named points to a jumper on each schematic. Then, all you have to do is make sure the jumpers are in exactly the same place on each brd.

I’d definitely recommend going careful on support - if you’ve got eight pins to connect between two boards, two pairs of four will be much more stable than one big eight, obviously.

Does that help? I’m more than happy to help with layouting - it’s one of the few things I’m passable at now. Is this going to be SMD or through-hole?

[infovore]

OK, I’ve just looked at the EAGLE sch.

I definitely think you can put the jacks, opamp, output resistors and caps for the triggers and CVs all on the top board. I think, anyhow. Then, you can use your bottom layer for power, I2C, Teensy and regulation. So I wonder if your headers are actually in the right place? I think you want them to connect to the TRX/2.3 connectors, and then join things there.

Of course: I might be talking utter shit and somebody like @Galapagoose will be a much better bet. If so, I apologise!

[infovore]

(ok, now I’ve tried to 4HP that: I’m not sure I can get all those polarised caps onto the top board after all! It’s hard to tell without properly routing it - you can get a cap and the relevant resistors behind a CV out, but it’ll be the routing that’s the challenge.) It’s certainly easier the more off-centre the jack sockets are.

[bpcmusic]

Yup. With the work going on in the Teletype V2 thread around opening up II devices to a more varied syntax, this whole area (and how multiple modules are addressed) needs a rethink. I’m really into your description of it feeling like one big Teletype.

Here is an excerpt of a discussion from the aforementioned thread about deprecating the II operator:

Teletype v2 proposals

So there is nothing particularly magical about the II op. Here is the entire source code for it: static void op_II() { int16_t a = pop(); int16_t b = pop(); update_ii(a,b); } At the moment, the II op takes 2 numbers and transmits them both over the i2c bus, any 2 16bit numbers you like. (WW.PRESET, etc, are just constants, you can type numbers in instead if you want to save characters!) Essentially the way the op works is tied directly to the i2c implementation. I propose that we separate …

Teletype v2 proposals

this is exactly my intention. there are a couple new modules coming up (not all made my me, note) that will use multi-length i2c messages. these will do exactly what you mention-- break free from the II op and be their own standalone ops. the II op is good however for very simple parameter transaction-- and i think it makes sense to spell out the entire param name ie WW.RESET for code readability. i also have bidirectional i2c working, though i haven’t written a test op. just tested via backe…

With this added latitude in the Teletype codebase, we could perhaps do something like this:

TO 3 CV 1 N 7
TO 1 TR.TOG A
TO 2 CV 4 N RAND 12

Where TO is the TELEX_O’s replacement for the II operator, the next digit is the module number (1-8) and then the rest of the command set is exactly the syntax of the Teletype. That last part would make me very happy.

Thoughts?

b

[bpcmusic]

@infovore - thanks for looking at this and the advice!

Right now, I’ve planned to put the jacks, LEDs and LED resistors on the front board and everything else on the back. This way, I’m sending 16 signals over and a couple of redundant grounds. This should keep the routing around the jacks to a minimum.

That does, however, make things unbelievably tight on the back board - especially with the room taken up for the through-hole Teensy, euro-power, i2c, and jumpers. I’m an optimist that it can all fit in such a way as to keep the signals well-isolated, but after playing with it a bit started feeling that I may be underestimating the routing rats nest that is about to ensue.

I certainly am going to give it a go - but am open to a little growth in HP if it means I can avoid compromises in optimal routing … as a last resort @laborcamp ;).

[laborcamp]

Personally I like the TO n syntax.
Simple, and shaving off some characters is always a good idea.
And the expanders do feel a little different from the monome Trinity standalones, so perhaps it makes sense to differentiate from || syntax.

[laborcamp]

oh, no!
Please keep these as 4HP!

[sam]

TO 3 CV 1 N 7
TO 1 TR.TOG A 
TO 2 CV 4 N RAND 12

I was going to say that might not be doable… but I’m not sure, I’ll need to think about it.

Things that would be more doable would be to use TO as a PRE command, i.e.

TO 3 : CV 1 N 7
TO 1 : TR.TOG A 
TO 2 : CV 4 N RAND 12

Technically, this is because PRE a.k.a MOD in the code can accept a command as a parameter, so in this case using TO in the pre slot would change the destination for all output commands on that line.

Another option would be to allow multiple statements per line with a ; as the separator.

TO 3; CV 1 N 7
TO 1; TR.TOG A 
TO 2; CV 4 N RAND 12
TO 1; CV 1 N 8; TO 1; CV 2 N 20

While they might look similar, semantically they are completely different though, as in this case using TO will change the output for all statements on any line (or any script).

[scanner_darkly]

using it as a PRE would prevent using it with other PRE commands though…

[sam]

Hmmmmmmm, good point!

[Galapagoose]

One suggestion for keeping everything small and easing routing is that every single capacitor on this board could be a non-polar ceramic cap. Yes, even the 10uFs in the power supply filtering!

You’ll need to go to a larger 1206 package for values above 2.2uF, but everything smaller than that can be found easily in either 0805 or 0603 packages. This will make the layout easier, and generally lowers the parts cost too.

Final suggestion is to keep both pcb layouts in the same file, and do them side-by-side. That way you don’t have to switch between files, which Eagle is terrible at.

//

A final aside - I’ve been thinking about whether it makes sense that ii-supporting modules would have 2 headers, not one, so as to allow for daisy-chaining rather than more and more complex ribbon cables. I know @tehn was thinking up another solution for the existing modules, but perhaps for newly designed ones it makes sense to think more about the expandability.

[tehn]

With this added latitude in the Teletype codebase, we could perhaps do something like this:

TO 3 CV 1 N 7
TO 1 TR.TOG A
TO 2 CV 4 N RAND 12

i’m voting against this as the syntax (to me) feels cluttered.

if you want to support multiple TO units, just have the inputs/outputs mapped accordingly.

ie TO#1 is outs 1-4. TO#2 is 5-8. that way you’re not addressing. then

TO.CV 7 N 2

automatically resolves to TO unit #2, ch 3

this means we don’t have to modify the existing CV commands, and the TO commands will all be contained in a set-- even if you’re basically just replicating the CV/TR commands-- adding TO. is a good signifier of what you’re doing-- and the line will be shorter.

[tehn]

A final aside - I’ve been thinking about whether it makes sense that ii-supporting modules would have 2 headers, not one, so as to allow for daisy-chaining rather than more and more complex ribbon cables. I know @tehn was thinking up another solution for the existing modules, but perhaps for newly designed ones it makes sense to think more about the expandability.

yes. put two headers on there.

[bpcmusic]

Love it! That is a great idea and really cleans up the mess.

Do you think we would be able to handle the trigger syntax similarly given where the parsing code is (or where it is planning to go)? (I haven’t seriously dug into this part of the effort yet since the option of moving away from the existing II behavior opened up.)

Is this what you were thinking?

TO.TR.TOG A

Thx!

b

[bpcmusic]

everything smaller than that can be found easily in either 0805 or 0603 packages

That is a great tip; I’ll make sure that all the parts are set for those package sizes!

Final suggestion is to keep both pcb layouts in the same file, and do them side-by-side. That way you don’t have to switch between files, which Eagle is terrible at.

That’s how I’ve set it up for now - but I’m not sure if I have configured Eagle properly to do this. Couldn’t find any tutorials on the side-by-side approach - only on panelizing.

Thanks again for all of your help; you have been an amazing resource!!!

b

[Galapagoose]

There’s not really much to it - just two separate dimension outlines in the .brd. You’ll need to duplicate the finished version and export gerbers for each board separately, but that can come later.

[bpcmusic]

That’s what I’m doing. Great!

b

[infovore]

I get what you’re getting at, but god, that back board is tight.

I started sketching - by which I mean, no traces yet, most resistors/caps not in place, just seeing how big things fit together:

and I really think life gets easier if you bung the opamps and all those ICs for the top board on it - whilst there’s space above the Teensy, its pinouts make it very hard to route around, so it’s basically dead space. Power header and fuses/caps/diodes and PSUs are all taking up a pile of space. And you need space around the DAC for routing.

Also: you need to place a lot of things around your front/back connectors. I staggered them because you can’t fit the jacks all around them nice and evenly - so I also staggered the jacks. LED resistors nicely go onto the front, because you can route top layer traces straight from LED pins to top resistor, to LED. And of course, once you put the ground planes in, life gets saner.

I definitely think anything that can be an electrolytic cap will make life much easier!

I appreciate this is playing, rather than real layout, but it’s how I tend to have to begin. It does feel doable across two boards, for sure.