#108

Sorry to hear your poor teletype got injured in the line of duty. We are all grateful and excited for your endeavors.

#109

Still works - just no voltage on the II port. I think it was a combination of the hour, a little wine, a little more frustration, an inadvertently flipped rainbow cable, and the probes on my oscilloscope. Red-stripes from now on! :wink:

1 Like
#110

what happened to the teletype? it should be pretty difficult to hurt-- it’s quite protected electrically.

i’ve found that if you flip the i2c cable that basically TT will hang on commands, and resume once you flip or disconnect the cable.

#111

Honestly, not sure. I was attempting to get it communicating with my Teensy. Coded up the little guy to log some commands that were sent to the White Whale. It did not sense any data coming down the line. Disconnected and then probed the lines to make sure everything was cool with my voltmeter and oscilloscope. ~3.3v - check. Bouncy lines on the scope - check. Reconnect to Teensy - nothing.

Hit the sack with a plan to resume in the morning. Upon a quick check after waking and walking the dog, the Teletype was no longer emitting the 3.3v on the SDA or SCL lines. I must have inadvertently done something bad the night before. Don’t think the dog had anything to do with it. :wink:

Could just be bad luck. Re-racked my rig the other day and, during the turn-on test smelled an acrid, electronics frying smell coming from somewhere. After some sniffing around identified that it was one of my two White Whales; power connector was properly oriented, but it was only half on the last 4ms bus strip (right side of pins plugged - left side hanging out over the end). Wouldn’t think that would matter as the pins are duplicated - but apparently it did. The unit runs now, but the tempo and param knobs only are reading full. I can clock it to an external source and utilize the attached monome - but can’t set any of the cv values. When I took it out for the sniff test, the strongest smell was around the crystal…sigh. Glad that I have two of them.

b

#112

a little cooking doesn’t necessarily kill a chip-- i’ve done it several times and modules have survived without issue, so don’t worry too much. if something is killed, it’s usually the USB power supervisor chip, which is easy to replace.

#113

Just posted some Teletype output expander related stuff in another thread. Check it out: Teletype v2 proposals - it talks about some of the extended functionality that I’m planning to put in the unit (which has been hinted at above). It is a great thread for Teletype lovers, regardless, due to all of the other interesting ideas about future functionality.

Things are progressing with the Telex-O schematic - thanks to @Galapagoose’s amazing help. I should be ready to share it in just a few days. Then, it will be on to layout of the boards.

I’ll update more when there is more to say.

2 Likes
#114

Lfooooooooooh yeah ! This is going to be sick!

#115

Update Time

The alpha of the TELEX-O (output expander) schematic is done. I’ve used this milestone to create a Github repo for the project and post some of the information shared above as well as a PDF and Eagle version of the schematic. I’m now jumping into layout - which for me means more Eagle tutorial videos.

Massive thanks to @Galapagoose for being so patient with me through the 5-6 revisions to shake out my errors and ignorance. Also, as noted in the read.me up at Github, thanks to Oliver at Mutable and Tom at Music Thing Modular for more than helping lead the way with their open sharing of their designs.

Please don’t be shy with any feedback you may have. I want to make sure this thing ROCKS for everybody - which means ensuring that I don’t screw it up. :slight_smile:

As mentioned above, I’m on to layout. Due to the narrow width, it will be on two layered boards. If anyone has advice on the best way to do this in Eagle, I’d love to hear it. Feel free to share here or send me a PM.

Thanks!

b

5 Likes
#116

Reading the docs. Multiple tele-o’s?! Be still my heart!

#117

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

#118

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.

#119

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

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?

1 Like
#120

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!

#121

(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.

#122

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. :slight_smile:

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

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

1 Like
#123

@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 ;).

1 Like
#124

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.

1 Like
#125

oh, no!
Please keep these as 4HP!

2 Likes
#126

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).

1 Like
#127

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

3 Likes