Many of us know that locking malfunctions are due to undesirable transistor gain properties due to differences in different transistors (their "beta coefficient" if you will.) With faulty transistors the gain is so high that it will cause glitches in the comparator circuitry that is responsible for locking, creating little spikes on the comparator output that will cause the TM to flip a bit. Currently there are 2 common ways of fixing this:
1) choose a new transistor until you find one that locks properly.
2) reduce the gain of the noise circuit going into the comparator by soldering a 1M resistor across R31.
Normally I dont even solder the transistor in to the circuit, I save it for last so that I can try out a bunch of different transistors until I find one with good characteristics.
Concerning option 2 I don't like doing this because it will reduce the range of the prob. knob that will yield randomness, effectively making large dead-zones on the sides of the prob. knob travel where locking stays active.
But here is my problem: on a new Turing Machine that I am building I always get locking working on one side and locking not working on the other side no matter which transistor that I choose.
Below is a copy of the noise amplifier circuitry followed by a picture of the switching/ comparator circuit that the noise circuit is feeding.
The circuit is pretty straightforward. Basically you should have noise going pretty close to the rails feeding the op amp comparator, then the prob. knob sets the threshold for the comparator to give a sort of random logic signal which determines whether or not the next bit will be flipped whenever a clock signal advances the bits in the shift register.
Looking at the noise transistor you can see a capacitor going into the amplifier circuitry which is supposed to remove the DC bias being applied to the signal. Therefore the transistor (at least to my understanding) should have NO dc bias and should be a completely symmetrical signal. This would contradict the behaviour that I am seeing on the scope when I look at the output of the comparator.
This is the comparator output (pin 14 of the TL074) when the prob. knob is all the way CW (locked):
Here is the same output when the prob. knob is all the way CCW (anti-locked) :
I have noticed that pressing my finger on the transistor makes a small difference but does not completely clean up the signal.
As you can see, the comparator never completely achieves anti-lock. I have tried a whole slew of things in order to fix this issue. All of the scope shots taken are on a Turing in which I have removed the CD4016 and T2, so the comparator circuit is not driving any other circuitry. I tried replacing R29 with a 1M pot to see if any other resistor values would cancel the DC bias. I shorted R23 so that the comparator threshold would get as close to +12V as possible for anti-lock (I tried R35 first but then realized that the circuit was backwards compared to how I imagined it, +12 is anti-lock and -12 is lock.) I raised the value of R22 to provide more gain for the comparator threshold. I messed around a whole lot with the transistor gain circuitry in terms of changing the resistor values.
Also it is worth mentioning that I noticed different tl074s act differently. I was trying some out that would give me locking glitches on the lock side of the prob. knob, but none that made the anti-lock issue go away. I will try to find that TL074 again and post some pictures.
I am at a serious loss as to how to fix this issue. I think as a last resort I can place a trim-pot across R31 and trim it so that the noise just barely doesn't touch the rails and the the locking dead-zones are kept to a minimum but I would much rather fix the source of the problem.
Thank you for reading and for any advice you can give.
. These days when I fix a turing the locking issues all require a different soLution. I chock it up to minor differences in the chips/ transistors being used. Recently I had a big order of Bytes expanders + upgrades: 5 turings, 5 different locking issues, 5 different solutions. Im excited to think that the new turing has fixed a lot of these bugs