TDS540A digital oscilloscope repair
Diagnosing the problem
The pattern of traces and gaps on screen did not change when the horizontal scale or offset was changed, which suggested that the issue was with displaying the waveform rather than acquiring it. Each of the sections of visible trace was not a continuous piece of the original waveform, but instead consisted of four sub-sections, each taken from different parts of the original waveform. Each of these sections consisted of 8 pixels. The pattern of trace sections followed by a gap repeats 8 times, so 8 * (4 sections trace + 4 sections gap) * (8 pixels per section) gives a total of 512 pixels. This correlates pretty closely with the specs (500 pixel waveform area).
To get a clearer image of what exactly was being displayed, I connected the input channel to the scope's calibration output and adjusted the horizontal scale such that, if the scope were working, only one rising edge would be visible on the screen. Since the trigger point indicator was still visible on screen, I knew where the rising edge should be located and could compare it to where it was actually visible. In the animation below, the alternating light and dark strips indicate the horizontal sections of 8 pixels each.
Looking at the leftmost group of 4 sections, we can see that when the edge is visible in section n, the trigger point is located in section n*17:
| Physical # | Displayed # | ||
|---|---|---|---|
| Decimal | Binary (LSB first) | Decimal | Binary (LSB first) |
| 0 | 0000 | 0 | 0000 000 |
| 1 | 1000 | 17 | 1000 100 |
| 2 | 0100 | 34 | 0100 010 |
| 3 | 1100 | 51 | 1100 110 |
| 4 | 0010 | 68 | 0010 001 |
| 5 | 1010 | 85 | 1010 101 |
| 6 | 0110 | 102 | 0110 011 |
| 7 | 1110 | 119 | 1110 111 |
| 8 | 0001 | 8 | 0001 000 |
| 9 | 0001 | 25 | 1001 100 |
From the table, it is apparent that the lower 4 bits of the section number are being duplicated on the upper bits. This is due to the way the data is stored and retrieved from the waveform buffer. The waveform buffer consists of a 2k by 16 bit SRAM array, an address multiplexer, and an address counter. The address counter consists of three 74F161 4-bit counters chained together into a 12 bit counter, though only the first 11 bits are used.
When writing data to the buffer, the CPU loads data in using the D2 random access bus. This part of the process works as expected. However, when the data is read from the buffer to be displayed on screen, the address multiplexer switches over to the counters. The lowest stage of the counter rolls over once per section. Note that the lowest stage rolls over every 16 clocks, but each section was only 8 pixels wide. This is because the scope was in peak detect mode, where both the highest and lowest values sampled for a pixel are stored. In other modes, where only one value per pixel is stored, the sections actually doubled in size, with half as many total on the screen.
Each stage has a ripple carry output (RCO) and two enable inputs (ENP and ENT). Both enable inputs must be high for the counter to count. When the output of the first stage is 15 (all bits set), then its ripple carry output is high. This enables next stage, which counts up on the next clock cycle as the first stage rolls over to 0. However, the third stage has one of its enable inputs connected to the ripple carry of the second stage and the other connected to the ripple carry of the first stage. In my scope, the ripple carry output from the second to the third stage was broken, so the counter only received a signal from the first stage. Thus, the second and third stages both incremented whenver the first stage overflowed, which would have the effect of duplicating the output of the second stage on the third stage.
Comments
Post a Comment