Tektronix 468
Hardware problems
Hardware problems
During my research into the inner workings of the 468 digital portion, I ran into some odd issues:
When running in envelope mode over a long time (#of samples set to 9999), you'll see spikes in the resulting waveform, values that are outside of a reasonable range.
When acquiring
waveform at the maximum hardware range (TB20, which is used when the timebase
[TB] is set to 2 μSec/Div), all acquired WFs seem to dance. They are
very unstable. For a while, there also seems to be a triggering issue but
that disappears.
Remember that any TB faster than 2 μSec/Div is actually based on Time
expansion of the waveform acquired at 2 μSec/Div (TB20).
My research initially focused on spike values, when none are expected. For example, a 2V sine wave (4V peak to peak) with an amplitude of say 2 V/Div and a middle (0) value at 4V/Div should span the vertical range of 2V to 6V. This equates to a range of acquisition values from 64 to 192 (setting 0V to be the bottom of the display). The acquisition value (sample) should never be 0xff (255) but the microprocessor finds the 0xff values ("spike values") regularly. This was tested with various function generators. It happens about 2-10 times per 32 seconds. With only CH1 selected and an screen acquisition rate of 60 acquisitions/sec (measured value), we have 30720 acquisitions that make it to the microcontroller (that is, when a trigger pulse is issued and the Display Queue is empty). So 10 out of 30720 isn't a lot but it's not 0 as it should be.
Besides the function generator causing a spike, the other components involved are the AD converter, the many buffers involved in getting the sample value to the acquisition memory and the acquisition memory itself. Luckily the acquisition memory can be read and written to by the microcontroller (even though it is only read by the microcontroller when processing a waveform. Many memory tests were executed on just the Acquisition Memory (as well as memory chips swapped) but no problems were detected. Note, these are 45 nSec per memory access chip, operated at 80 nSec when operating in TB20. However, access to the Acquisition Memory by the microcontroller is much slower.
Tektronix provided a test chip to replace the AD converter chip for testing purposes. This test chip is an 74LS393, a dual 4 bit counter, configured as an 8 bit counter. Inserting this chip is supposed to yield samples values that continually increase by 1, and restart at 0 after 255. The start point is unknown since there is no valid trigger in this mode (remember, the trigger signal comes from the analog part of the scope and it reacts to whatever is coming in through CH1 and CH2, unrelated to the 74LS393 generated values.
Running with the 74LS393, then pushing the SAVE option, takes a snapshot of the last buffer copied from acquisition memory and shows it on the screen resulting in rapidly rising lines. Initial observations show that these lines are pretty clean when a timebase < TB20 is selected but very bad at TB20. See the display of the buffer below.
We know what the sample values are supposed to be but the observed values are off, way off sometimes.
It doesn't look like samples were skipped (there are 512 value in somewhat ascending order) but many samples values are off by 3-5 points, some are off way more (0xBF becomes 0x81). The values that are off by a little cause a jittery image when using TB20 (or faster) because the sample values don't line up. The samples with a large deviation can cause a spike (though most of them are not as visible as expected).
Looking at the 74LS393, it seems this IC should be able to operate at 25 MHz (the sample clock at TB20) but that is only true for each individual 4 bit counter. Since bit3 of counter A is used as the clock for counter B (falling edge so when bit3 is turned off), it means the resulting 8 bit counter will take twice as long to generate a proper result. It seems that the counter value is being used before it is actually valid. Analyzing the dumped data it seems that some higher bits in the upper nibble (bits 2 or 3) are regularly missing, bits that would be carries from lower bits. This however also happens at TB19 (using a 10 MHz convert clock). A true 8-bit counter (74LS590) would have been a better choice but the 74LS590 is not pin compatible with the 74LS393.
However, most of the non-conforming sample bits are in the lower bits (counter A) if the buffer shows incorrect results. Further inspection shows that, with respect to small differences, only the odd bytes in the buffer are off. Note that at acquisition speeds < TB20 (slower than 2 uSec/Div), most sample values are correct, except for the incorrect values caused by 74LS393 counter B carries. Swapping 93422 memory chips did not change these observations.
While testing wit the 74LS393, it is possible to ground data pin 7. As a results, all sample values are now in the range 0..0x7f. Indeed the screen only shows rapidly rising lines on the lower half of the screen. The software testing for 0xff sample values finds NONE. This suggest that the unexpected 0xff sample values are introduced by the AD converter chip. Another experiment is to lift pin 13 of 74LS393. This means counter B is never clocked and it data outputs stay at 0..but they don't. All data lines actually have pull-up resistors of 1K so the resulting value of each output pin of counter B is somewhat unpredictable; H or L dependent on the tug of war of the IC (pulling to 0) and the pull-up resistor. The resulting state doesn't seem to change though so we do get a very narrow (16 values only) band of rising lines, on the same screen location.
According to the datasheet the output pins of the AD converter chip 1007PC are not open collector. The pull-up resistors are recommended however.
Note that, even though U356 (74LS393) pin 8 (line CD7) is connected to GND during this test, TP2 on schematics page <14>, which is connected to line CD7, shows a lot of small voltage spikes (+1V to -1V) every 10 uSec. This seems to be remnants of the QD pin output, pulled to GND.
Even though there are obvious "spike" values in the sample buffers, these spikes are usually not seen on the screen. An exception is running the 468 in Envelope Mode with # of Samples set to 9999 (meaning forever). In that case, occasionally, a spike is visible on the screen.
The 468 vertical display path includes a Third Order Low Pass Filter (in hardware) just before the signal is sent to the Vertical Amplifier. Is it possible that this hardware filter was added to remove these "spike" values - at least most of the time?
You can find un updated report on this problem here.
For suggestions and corrections, please contact me at:
