I think to do reliable connection-detection, you need to send a known signal to the normalisation pin of the socket, then monitor the input from the socket to the MCU and compare the two.

This obviously relies on the correct circuitry to work. If the normalisation pins of the socket aren’t connected to the processor, it’s not going to be possible.

Sorry this is a bit vague. I’m not an electronic engineer myself, but remember reading @pichenettes explanation of the principle on the Mutable Instruments forum a while ago.

The jacks have an extra lug that is in contact with the tip/signal lug when no cable is inserted. When a cable is inserted the shaft of the plug pushes these two lugs apart, breaking the connection.

The most common ways to use this are:

  • for something simple like “this jack normals to +5V”, wire the detect lug to +5V (probably through a weak pull-up so that 5V isn’t immediately shorted to ground or whatever’s on the other end when a cable is being inserted). Inserting a patch cable breaks the connection and instead the signal is connected to the tip of the patch cable plug.
  • for detecting if a cable is plugged in, do some kind of impedance measurement between these two pins. If there is close to zero impedance, there is no cable plugged in, if there is a very high impedance a cable is present.

More complex or specialized schemes are sometimes used depending on the application.

My read of the TXi schematic indicates that the detect pin isn’t connected anywhere, so jack detection is probably not possible.

Much more detailed discussion here.

2 Likes

Something like that was my suspicion. Drat.

Thanks for taking the time.

@a773

Not sure if you have solved your LED problem. I’ve had a few units that had this issue when I built them.

I was able to resolve it consistently by a) making a bit more space for the LED by filing out some additional room in the panel and b) ensuring that the LED is cut to the proper size (not being smashed up against the panel). Tolerances. :slight_smile:

You can also check the headers that pass the LED voltage from the back board to the front board. If they are loose (and sometimes can be if you are using the machined/precision headers), you could have spotty connectivity.

Agree. It shouldn’t work as designed - very embarrassed by it, but I was overwhelmed with details when I was putting these together and not surprising that I got tripped up by literally the first thing I learned when starting to work with microcontrollers. Isn’t that always the case? :wink:

So weird that it worked for the gazillions of units that I built. That certainly lulled me into a false sense of security.

Something must have changed in either the Teensy itself or differences in the manufacture of the Pusherman boards (though, I doubt the latter as I’ve built it successfully with three different board manufacturers). Could just be that the state of the voltage in your case causes issues? Maybe the phase of the moon? Who is to say with a floating pin…the chaos of the universe is at play here.

If it doesn’t work as designed with your components, you can always change the firmware detection value or simply hard-code the address. Apologies. If I ever make a 2.0 version of these things, this is top on my list of corrections!!

2 Likes

I wish that I didn’t have another issue to post, but I do!

Both of my units have stopped communicating during use a few times. It seems to take a while, but I’m playing with my system so tracking time is… difficult. :sweat_smile: This time I dragged a computer over, and verified that druid could no longer recieve a response from TXi. The crow script is still running happily, but it can no longer read for updates. I’m hesistant to leave the TXi’s in debug mode as I’m unsure of how the added overhead effect things, but I guess that will need to be my next stop when I try to get to the bottom of this.

If anyone else has had issues with their modules ceasing to communicate after using them for a bit, I’d appreciate any insight you may have observed.

Has anybody sequenced their TXo through Crow/Max? I’d like to try and get something like that rolling.

1 Like

TELEXo C102: says in the BOM it should be 1206/180pF/1%.

Is it vital the part is 1%? I can only source 5% versions locally.

I had TXi drop off the bus in a multi-leader setup with crow and TT. So I can echo the stability concerns but my setup was obviously out of spec.

The TXo has pretty low-tolerance parts in that section to ensure CV output accuracy. I’d be more concerned with the values for the CV being consistent across the outputs - which you may be able to compensate for using the software calibration routines. Any changes to the cutoff of the output’s lowpass filter should be indistinguishable due to it being only a single-pole filter (and thus very gradual).

Given that SMD caps and resistors are relatively cheap (and sometimes less expensive in greater numbers), you might want to grab a bunch and then measure their capacitance to see which one is closer to the target value. While the lot may vary by 5% - there may be some capacitors in there that are closer than others (and within the 1% tolerance).

1 Like

I can find 0805 180p 1% caps. I should be able to solder those onto the 1206 pads, I think.

1 Like

Absolutely! I’ve done the same myself. :slight_smile:

1 Like

I’m about to build my TXO modules -

What’s the purpose of having 110p caps instead of 180p?

I want to build mine to work with the Teensy 3.6 so I understand I need the europower helper as well. Anything else I need to build with the 3.6 in mind?

Thanks

The TXo+ runs at a higher sampling rate; the change in capacitor moves the cutoff of the reconstruction filter to match the rate. This is sorta pointless due to the extremely soft slope of the filter (it is single-pole). So, you should consider it optional. In other words, it is an OCD test. :wink:

2 Likes

hi @bpcmusic - love your work - i’m not sure if this is the best place to ask but I was wondering if you had updates about availability of modules in your store. i’m really keen to buy a few! hope you’re well x

I’ll copy a bit from my post above from last year:

Still playing catch-up here - so no timetable for when I might get around to building out the TXb and TXn bits I have in various states. I have a tremendous amount of life ahead in the queue at the moment.

For the TXo and TXi, I don’t plan to bulk build any of these in the future again. I have a pipe dream of revamping the design as things that are more easily bulk manufactured. But I wouldn’t be starting that until 2021 at the earliest.

4 Likes

thanks for the response, sorry I couldn’t find that post in this long thread! i guess i’ll need to look into diy options for TXo and hopefully snatch a TXb at some point!

1 Like

Given that both hardware and software appear to be open source, I hope this isn’t out of line, but has anyone approached the people who build clones of the Mutable Instruments modules to see if they are interested in building these ? I know the market for Teletype expanders is probably a lot smaller than the market for Rings et al, but if you were one of a very few providers your share of that market would be huge !

@mattsb Afaik, Pusherman is already selling TXO and TXi PCBs and panels. It’s the same community that used to build M.I modules :wink: i think they started building these after Teletype was open sourced.

1 Like

Cool, although I was hoping to have someone build the modules themselves rather than just the PCBs and Panels (not feeling up to doing the DIY myself). I suppose I could find a local builder, but not really what I was thinking of.

Thinking specifically of people like Michigan Synth Works.

1 Like