Hi - I wish I could remember exactly what we did. I thought I’d kept the file safe and was going to document it properly on here, but for the life of me I can’t find the firmware now. (If @goatfarmer is still on here, he might have the file somewhere perhaps…).
But I do remember it was a trivial thing to do once we figured out what the problem was. Basically just hard coding the address in the firmware I think (which is obviously not the best way of doing things, but all I wanted at that point was something that worked 
). I do remember it didn’t take long to walk through the code and see where the problem was. Sorry to not be of more help, but maybe it’s useful enough to know that it was very easy to fix in software!
1 Like
Okay, thx, thats a starting point! So I would need first this being installed to be able to do the necessary edits (in the Txi-Firmware as well in the teensy at least - as described here: GitHub - bpcmusic/telex: Open source modules designed to interface with and expand the capabilities of Monome's Teletype.), right? GitHub - bpcmusic/telex: Open source modules designed to interface with and expand the capabilities of Monome's Teletype.
After installed everything the uncompiled Txi-software which I have to load is the one on github in the software folder, right? I have to search for something like adress pin… delete the reference to the teensy pins and add a fixed binary value I could imaging? And how do I get access to the teensy to change the values in the delay calls?
1 Like
I honestly don’t remember the steps (sorry!) but someone else on here will probably be able to help with what’s needed to edit and upload the firmware. My recollection is that we only had to change a single line, but that might be my rose-tinted recollection!
1 Like
Setting up my euclidean chord generator I was surprised how wonderfully complete the TXO oscillators are. One additional command would render them nearly as ideal as a Just Friends. TO.OMAP 1234 1234 that maps each oscillator to a selectable output. TO.OMAP 1234 1122 would map oscillators 1 and 2 to output 1, 3 and 4 to output 2. A software version of the TXN!
1 Like
grey
1709
Hey. Yeah, I needed to hard code the address. They are aware of the problem, but I know they’re busy with other things these days. There is a design problem with the board.
Message from bpcmusic
"If you are referring to the jumpers that set the address - then I am aware of this. Something seems to be up with the latest Teensy, Pusherman PCBs, and some environmental factors that is causing a different behavior from the units that I have built to date.
To be fair, there is a substantial design flaw in the jumpers that set the units address that I didn’t catch until it was way too late. It worked reliably on all of my units to date (hundreds built) - but needed some slight adjustments for the Teensy 3.6, which is when I did the facepalm.
It was certainly a major dufus move on my part - literally the first thing you learn when figuring out microcontrollers. Sigh.
The only real solve is to use a firmware build that hard-codes the address. Easy enough to change in the code - but would it be helpful to have some pre-compiled builds that do this?"
I suggested it would be helpful, but it looks like they haven’t found the time.
The firmware change was trivial. If you comment out: /*configID += cfg;*/ that will skip the pin detection assignment and leave the device at the first address.
It tries to use pin detection but it doesn’t work correctly, and ends up addressing it to 8 by default, if I recall correctly? That for loop before it doesn’t do what it’s suppose to on self produced units, so feel free to comment that out too.
(As a side note, if you end up getting drop outs once it’s working, I suggest making your own cables if you haven’t. That fixed something that was seemingly impossible to track down via debugging for me.)
1 Like
@grey: If you still have that modded firmware ready compiled somewhere, I would be of course very happy, if you would post it here. Otherwise I will have to install everything need on the software side I do my own mod… which would be of course also an interessting adventure Thanks so far!
grey
1711
I don’t have it handy, and honestly it’s worth going through the motions. Having the Arduino IDE installed and compiling the firmware is a useful bit of experience to have in Eurorack land.
2 Likes
Good luck @KitKatAndy! Sorry I don’t still have the firmware handy. However, if you do manage to get it working, maybe post it here if you can for folk who come here in the future? (I’m kind of kicking myself that I didn’t do that at the time!)
@grey Also thought so and happy to took this experience! Installed everything as explained on github and it was quite straight forward to change the firmware and compile it. I did initial tests with both built units and it seems to work fine now! Big thanks for your hints! Will do further tests this evening and would report any issues.
Maybe your connection issues were caused due to this?:
@SimonKirby @desolationjones Also thank you for your support with this!
Here is the modified hex-file based on the latest TELEXi.v.021B fixed to unit nr. 1. With this firmware version it is no more possible to change the unit nr. with dedicated jumpers on the module. But this solves the problem of “randomized unit nr. behaviour” at each power up which is caused due to the newer teensy version (or maybe pushermans pcbs).TELEXi.ino.hex (156.7 KB)
5 Likes
grey
1714
My issue was specifically that the device would randomly stop communicating during use with my crows, but a reasonable suggestion! I haven’t had the issue since making my own i2c cables (much posting about it previously).
Glad to hear you’ve got it sorted!
1 Like
Necroreplying here but do you happen to have part numbers for those flat head LEDs? Seems like it’s easy to find the flat yellow on Mouser but didn’t get any hits for whites.
Also - does anyone have any recordings (I.e. bandcamp or other high quality) of the Txo+ Oscillator in a musical context?
Not really i bought like 500 of each colour 5 years ago here locally 
1 Like
moogah
1717
I’m using these diffusers on mine with domed LEDs and they look great. A bit pricey, but diffusers tend to be.
They don’t snap in to the panel super tight, so I dabbed a tiny bit of glue to each on the back of the panel. Seems fine to me.
https://www.mouser.com/ProductDetail/Bivar/PLP2-3MM-D?qs=%2Fha2pyFaduiD1kdqypuSvXrXeE6QioSnF3Jav3wwcQV5mqxj7XFmxA%3D%3D
1 Like
These look perfect - thank you!
moogah
1719
worth a note: those are diffused whereas the teletype uses a clear LED (actually a smt led with clear pipes), so if you’re looking for an exact match these won’t quite be what you want.
Edit, but the diffused has a more even viewing angle to my eyes, so I really like them.
1 Like
yams
1720
Are TxI inputs expected to take a moment to stabilize when receiving continuous input?
moogah
1721
I bet this has been discussed, but I was wondering the same thing too when testing mine the other day. I didn’t have 10K pots around so I used 100K since it usually doesn’t matter with a voltage divider, but I see that there is a capacitor placed between the wiper and ground, which could likely be creating a little lag circuit (made worse by my choosing a resistance thats 10x the spec).
Having not taken the time to really understand the circuit, I can’t say for sure, but it’s certainly possible this is the nature of it.
1 Like
yams
1722
I haven’t seen anyone talking about it and the only other people I know with the module just never applied it in contexts where they would matter so much (although the idea that it was fast was key in my desire for one).
Thanks for this anecdotal confirmation – hopefully we can get more information on this!
Hm. The settling time of that pot circuit design is [EDIT: not that high, whoops bad math]. But that shouldn’t affect the CV inputs, which I believe was @yams’s concern.
yams
1724
Yes, I’m thinking of the CV ins! Great catch
1 Like
