 |
| Figure 1: The front panel and original green monochrome screen of the 4031. A close look shows the "blistering" on the screen protectors due to delamination, making the display more difficult to read. Click on the image for a larger version. |
As you would expect from a device from the 1990s, the original display used a CRT (Cathode Ray Tube) based monitor operating at something "close" to PAL horizontal and vertical scan rates. While the CRT monitor in this unit is still in reasonable shape - aside from requiring a "re-cap" (e.g. replacement of electrolytic capacitors) I decided to take on the challenge of putting a more "modern" LCD-type display in it - perhaps taking advantage of a minor savings in both weight and power consumption.
This requires no electrical modification of the 4031 itself and only minor mechanical changes to mount the LCD panel and its related hardware. (This may also work for the 4032, a version of this unit that covers up to 2 GHz - see below for comments.)
Is it "PAL"
While the pedants would say that a monochrome-only signal cannot be PAL, the reference is, instead, to the horizontal and vertical scan rates of 15.625 kHz and 50 Hz, respectively which are close to those found in the PAL system used in Europe. As is typical for pieces of non-consumer gear and test equipment, the horizontal and vertical synchronization signals and the video are brought out independently of each other, each being represented as a TTL signal.
 |
| Figure 2: The horizontal sync pulse train showing 25% D.C. pulses at 15.625 kHz, TTL level. Click on the image for a larger version. |
The forgiving nature of the CRT monitor
One nice feature of a CRT monitor is that it can be quite forgiving of deviations from standard video applied to it. Many - but not all - all-in-one sync decoder chips used in CRT monitors are happy with taking horizontal and vertical signals that are "close" to some standard - but not exact - and lock onto it satisfactorily. Such is the case with the 4031: While there are separate horizontal and vertical synchronization signals, neither is quite standard, but it's "close" enough for the old monitor.
 |
| Figure 3: The vertical sync, showing a 10% duty cycle pulse at about 50 Hz. Click on the image for a larger version. |
For example, the horizontal synchronization signal is simply an uninterrupted 25% duty cycle pulse train occurring at the horizontal sweep rate of about 15.625 kHz (e.g. 16uSec long) while the vertical synchronization is a 50.08 Hz 10% duty cycle (e.g. 2 msec long) pulse train. Unlike sync signals found in other applications, the horizontal signal does not contain any sort of blanking (suppression of pulses) during the vertical interval.
Within the 4031's original CRT monitor, the horizontal and vertical synchronization signals are handled completely separately (by a TDA2593 and TDA1170, respectively) so the fact that they are non-standard is irrelevant.
Unfortunately, any modern LCD display device that is expecting a PAL-like signal (in terms of timing) isn't likely to be happy with separate, non-standard synchronization inputs.
Initial attempts:
Initially, I was hoping that an off-the-shelf LCD monitor display like the 7", 4:3 aspect CLAA070MA0ACW with a driver board could be made to work with these signals with no other hardware, but my work was thwarted by the fact that its VGA input - which might handle separate horizontal and vertical sync signals - would not function at PAL video rates - only VGA rates, which have roughly twice the horizontal and vertical frequencies. While it may have been possible to modify the firmware on this board and re-flash it with one of the "customized" versions found in various corners of the Internet, I chose not to do this.
I then attempted to make a simple analog sync combiner circuit and apply the signal to the composite video input, but found this to be unstable - plus there was the fact that the video display board itself did not have the capability of setting the horizontal and vertical size to fully-fill the screen to the edges, something desirable to make the active screen area fully-fit the window on the front and also align with the buttons along the bottom of the screen.
After a bit more research, I decided to get a GBS-8200 video converter board (Version 4.0), a relatively inexpensive digitizing board designed to convert the myriad of video formats from CRT-based arcade video games and computer inputs to VGA which would then be inputted to a standard monitor and the CLAA070MA0ACW display driver board. As such, I presumed that it would be far more forgiving to variations from standard video signaling - and I was, fortunately, correct
Sync (re)processor:
While I was originally hopeful that I could simply apply the horizontal and vertical sync inputs to the GBS-8200, the non-standard sync timing (pulse width, lack of a gap of horizontal sync pulses during the vertical interval) did not produce stable results, so a simple circuit had to be devised to modify the sync signal: This basic circuit is shown below.
 |
| Figure 4: Diagram of the sync processor itself. This circuit will produce a sync to which the GBS-8200 board can lock. The single video output is connected to the RGB input of the GBS-8200 to produce a monochrome (single color) display as seen in Figure 6. Click on the image for a larger version. |
 |
| Figure 5: The circuit in Figure 4 built on a prototyping board, the results seen in Figure 6. Click for a larger image. |
During the vertical pulse U3, the counter, is clocked by the horizontal sync pulses and on the 5th count, the timer is stopped, setting the input of U2b, a 4011 NAND gate wired as a simple inverter, high. U2d is used to "gate" the output of the counter - being only active only when the timer has stopped at the 5th count and during the vertical interval meaning that its output goes high only when the timer is actually counting - not while it's stopped at its terminal count or held in reset. The output of this gate is combined with a "re-inverted" copy of the vertical sync to produce a new version of the vertical sync that is about 225 microseconds long rather than the original 2 milliseconds as depicted in Figure 7 (below).
FWIW, I used the 4011 NAND gate because I found a rail of them in my parts bin - but I couldn't find any 74HC00s at the time which would have worked fine, albeit with a different pin-out. Similarly, either CMOS CD4017 or 74HC4017 counter would have been fine as well considering the low frequencies present. I would, however, recommend using only the 74HC14 (or 74HCT14) as it's plenty fast for the video data and it has fairly "strong" outputs (e.g. source/sink currents) as compared to the older and slower CD4069 or 74C14 hex Schmidt inverter.
Note that while it would theoretically be possible to use a one-shot analog timer to generate a new, shorter pulse, doing so would result in visible jitter of the video signal (I tried - it did!) as that timing would neither be consistent or its length precisely synchronous with the horizontal timing: The use of the horizontal sync to "re-time" the duration of this new vertical pulse assures that the timing of the new pulse is synchronous with both sets of pulses and completely jitter-free.
This new, re-timed vertical sync pulse is then applied to U2a which gates it with the horizontal sync: The output is then inverted by U1c to produce a composite sync signal (see Figure 7, below) that, while not exactly up to PAL standards, is "close enough" for the GBA-8200 video converter - configured for "RGBS" mode - to be happy.
Elsewhere in the diagram may be seen inverter sections U1d-U1f: These are configured as buffers to condition the TTL video input and provide a drive signal to the video input of the GBA-8200.
Suitable for a monochrome image!
The circuit in Figure 4 is sufficient, by itself, to drive the GBS-8200 and produce a stable VGA version of the 4031's video signal.
 |
| Figure 6: The monochrome output from the GBS-8200 board using the sync processor seen in figures 4 and 5 via an external monitor. Click on the image for a larger version. |
Figure 6 shows the result of that: The VGA output from the GBS-8200 was connected to an old 4:3 computer monitor that I had kicking around, producing a beautiful, stable, monochrome signal.
Full-color output from the 4031
The SI 4031's video output is a single TTL signal, meaning that there is not even any brightness information, making it capable of monochrome only. Fortunately, it is possible to simulate context-sensitive color screens with the addition of a bit of extra circuitry and firmware as described below.
The portion of this circuit used for processing the sync pulses is based on that shown in Figure 4: A few reassignments of pins were done in the sync re-timer, but the circuit/function is the same. What is different is the addition of U5, a 74HC4066 quad analog switch and U6, a PIC16F88 microcontroller, and a few other components.
How it works:
The video signal is buffered by U1d-U1f and applied to R1, a 200 ohm potentiometer, the wiper of which is applied to Q1, a unity-gain follower to buffer the somewhat high-impedance video from R1 to something with a source impedance of a few ohms and, more important, constant output with varying load. The "bottom" end of R1 is connected to U5c, on section of the 74HC4066 which, if enabled, will shunt some of the video signal to ground, reducing its intensity, adjustable via R1. Via diode D1, this line is also connected to a pin of the microcontroller - the "MARK" pin - more on this later.
 |
| Figure 7: Top (red) trace: The composite sync from the circuit of Figures 4 & 8. Bottom (yellow) trace: The original vertical sync pulse for comparison. Click on the image for a larger version |
The output of Q1 is then applied to U5a, U5b and U5d via 100 ohm resistors. These analog switches will selectively pass the video to the Red, Green or Blue channels of the monitor, depending on microcontroller control. At the outputs of each of these switches may be found a resistor and diode in series (e.g. D2/R6) and these are connected to output pins of the microcontroller: If these pins are driven low by the microcontroller, the diode drop and series resistance of the 33 ohm resistor (e.g. R6) and the 100 ohm resistor (e.g. R3) and the output transistor of the microcontroller will shunt some of the voltage and reduce the amplitude on that channel to provide a means of brightness control, increasing the color palette.
I'd originally intended to place emitter-follower video drivers (e.g. the circuit of Q1 in Figure 8) on each of the R, G, and B outputs, but the very short lead length to the input of the GBS-8200 (e.g. no visible signal reflections) - and the ability to adjust the RGB input gain via its three potentiometers - eliminated this requirement as additional losses through the analog switches and other components could be easily compensated.
 |
| Figure 8: Added to the sync processor of Figure 4, above, is a PIC16F88 used to analyze the video from the 4031 and "colorize" the resulting image. See the text for information as to how this works. Click on the image for a larger version. |
With the combination of the three 4066 gates, the "!BRITE" pin, and the three "dim" pins (e.g. "!R_DIM", "!G_DIM" and "!B_DIM") over two dozen distinctly different colors and brightness levels may be generated under processor control.
The magic of the microcontroller
U6, a PIC16F88 microcontroller, is clocked at 20 MHz, its fastest rated speed. Because its job is to operate the four switches comprising U5 - and the three "dim" pins on the video lines - it must "know" a bit about the video signal from the 4031:
- The "!V_SYNC" pin gets a conditioned sample of vertical sync from the output of U1a: It is via this signal that the U6 "knows" when the scan restarts at line one.
- The "!H_SYNC" signal from the output of U1b is applied to pin RB0, which is configured to trigger an interrupt on the falling edge (the beginning) of the horizontal sync.
- The "!VID" signal is applied to pin RA4, which is the input of Timer 0 within the microcontroller: This is used to analyze the content of lines of video to determine the specific content as the timer is able to "count" the number of times that the video goes from low to high on these scan lines - In other words, a sort of "pixel count".
In operation, the start of each horizontal sync pulse triggers an interrupt in the microcontroller. If this coincides with the start of the vertical interval, the line count is restarted.
Video content analysis:
 |
| Figure 9: Mounted inside the 4031, the sync processor board is on the far left, the six pins of the ICSP (In Circuit Serial Programming) connector being easily accessed. The buttons and controls for the other two boards are also accessible. Click on the image for a larger version. |
Visual inspection of each of the screens on the 4031 will reveal that
they contain unique attributes. Most obvious is the
title of the screen located near the top, but other content may be
present midway down the screen - or very near the bottom - which may be
used to reliably identify exactly which screen is being displayed, having determined the "pixel count" for certain lines on each of these screens beforehand.
For each subsequent horizontal sync pulse and corresponding interrupt, the count contained within hardware timer 0 is read - and the timer is immediately reset. For a number of specific scan lines, their unique counts are stored in RAM.
Attention to detail is required!
Determining the pixel count consistently requires a bit of care in the coding. As mentioned, this count is based on an interrupt-driven routine that reads the content of hardware timer 0 - but this also means that the code must be written in a way that guarantees that the time between the start of the horizontal sync pulse (and subsequent entry into the interrupt service routine) and the read and reset of timer 0 is as consistent as possible, considering the asynchronicity of the timing of this interrupt and the CPU clock.
What this implies is that the reading this timer and its resetting must not only be done in an interrupt, but that it also be the first thing done within the interrupt function prior to any other actions, particularly any conditional instructions that could cause this timing to vary, resulting in inconsistent pixel counts - something that would preclude the use of anything other than a quickly-responding interrupt. Another implication is that this interrupt may be the only interrupt that is enabled as preemption by another one would surely disrupt our timing.
Immediately following this action is the setting of the color and brightness attributes by ANDing a copy of the current content port/pin registers to remove the brightness/color bits and then ORing that data with the pre-calculated color/brightness bit mask data into those same registers so that any changes in these attributes occur to the left of the visible pixels in the scan line.
A limitation of this hardware/software is that it is likely not possible to satisfactorily set different colors horizontally,
along a scan line - it is possible only to change the color of complete
scan lines: To do this would, at a minimum, require extremely precise timing within the interrupt service routine, adding complexity to the code - and it's not certain that satisfactory results would even be possible. To do it "properly" would certainly require more complicated hardware - possibly including the regeneration of another clock from the horizontal pixel rate - but doing this would be complicated by the fact that the pixel read-out rate is asynchronous with the sync as noted later.
Using the pixel counts:
At the beginning of the vertical interval, outside any interrupts, the previously-determined counts of low-to-high transitions is analyzed via a series of conditional statements and a variable is set indicating the operating "mode" of the 4031. This "mode" information is then applied to another look-up table to determine the color to be used for that screen.
One complication is that like other analog video, that coming from the 4031 is interlaced meaning that for certain scan lines - particularly those with diagonal elements - that the pixel count may vary for a given scan line. Unlike "true" video, the sync pulses from the 4031 contain no obvious timing offset (e.g. "serrations" in the sync) to offset by half a line or identify the specific video field, but with an analog monitor, this wasn't really much of an issue as it would simply paint a line on the screen in "about" the right place, anyway.
For most screens, simply looking at pixel counts of between four and six different lines - most of them on lines from 4 to 15 - was enough to uniquely identify a screen, but others - particularly the "Zoom" screens - sometimes require even a greater number of pixel counts and other techniques to reliably and uniquely identify the screen being displayed.
In particular, differentiating between the "SINAD" and "RMS-FLT" Zoom screens was problematic as both resulted in the same pixel counts for all of the lines usable for unique identification: The only way to detect the difference was due to the fact that for some lines, the pixel count for the "SINAD" screen would vary due to the aforementioned video field differences - or possibly due to interaction between the asynchronicity of the pixel clock, the CPU clock, and the way counts are registered on a counter input without hardware prescaling. It was the fact that the count of the SINAD screen varied that allowed it to be reliably differentiated from the "RMS-FLT" screen, which had a very consistent pixel count.
Coloration of the screen:
Many screens on the 4031 have different sections. For many screens, the upper section contains the configured parameters (e.g. frequency, RF signal level, etc.) while the lower portion of the screen shows the measured values or an oscilloscope display: Simply by knowing which screen type is being displayed and the current line number, those sections can be colored differently from other portions.
Deciding what color to make what is a purely aesthetic choice, so I did what I thought looked good. Because about two-dozen different colors are possible, I chose the brightest colors for the most commonly-used screen segments, setting these colors by the function to which they were related.
Finally, all screens have, along the bottom, a set of labels for the buttons below the bottom of the screen: These may be colored separately as well - and I chose gray (a.k.a. "dim white").
Analyzing the video to determine "pixel counts":
When writing the firmware, a few simple tools were included, notably some variables, hard coded at compile time, that would display the pixel counts. If, for example, one needed to determine the pixel count for line #14, the pixel count display variable would then be loaded with the pixel count for line 14. For example, the oscilloscope screen capture shows a pixel count capture: The left-most pulse is 4 units long followed by a single-unit pulse (meaning "10") followed by a 2 unit long pulse with three more pulses - for a pixel count of 13.
 |
| Figure 10: An example of the "pixel" count: The 4-unit wide pulse followed by one pulse represents 10 and the 2-unit wide pulse followed by 3 pulses represent a pixel count of 13 on the selected line. Click on the image for a larger version. |
Another variable may be set to visually identify which scan line is being counted. When the scan line being counted occurred, the "MARK" pin would be set high causing an on-screen indication of which line was being inspected, offering a "sanity check" and a visual reference to know which line, exactly, was being checked.
During the vertical interval, pin "RB3" would then be strobed with a series of pulses to indicate the pixel count - a "long" pulse lasting four CPU cycles followed by pulses of 1 CPU cycle, each to indicate the "tens" digit (if any) and a shorter pulse of two CPU cycles followed by the requisite number of 1 CPU-cycle pulses to indicate the "ones" digits.
Using an oscilloscope triggered on the signal on RB3 (pin 9) these pulses could be read visually on the oscilloscope and by switching between the different screens on the 4031, the "pixel count" of this line for the various screens could be determined: Repeating this for several different scan lines allow unique identification of all screens. In the event that there is false detection of a mode, this "pixel count" output could also be configured to show the number of the current modes (in a "#define" statement) when they are detected to aid in debugging.
In producing this firmware, I have only one version of the 4031 (with Duplex option) available to me. Different versions of the 4031 - and the 4032 - may have "other" screens not included in the analysis, or slightly different layout/labeling that will foil the analysis of the scan line.
The way the firmware doing the screen analysis is written, if the scan line analysis doesn't find a match to what it already "knows" about it will cause that screen's text to be displayed in the default color of white.
At present this "scan line analysis" can only be done by setting certain variables in the source code and recompiling - but this was made easier by the inclusion of the "ICSP" connector (noted on the diagram in Figure 8 and visible in Figure 9) to allow in-circuit programming, while the unit is operating. In theory, it may be possible to come up with some sort of user-interactive means of setting individual screens' colors which could be used to set the colors on screens of different firmware versions or with features that I don't have in my 4031, but this would require significantly more work on the firmware.
 |
| Figure 11: The 4031 with the retrofit LCD operational. This isn't a perfect photo because it's very difficult to take a picture of an operational electronic display! Click on the image for a larger version. |
Color mode selection:
With the lack of the CRT monitor, there is no need for an "intensity" control, but rather than leave a hole in the front panel a momentary switch was fitted at this position. Connected between ground and pin RB7, using the processor's internal pull-up resistor, this switch is monitored for both "short" and "long" button presses.
A "short" press (less than 1/2 second) toggles between "bright" and "dim" using the same color scheme, but a "long" press (1.5-2 seconds) changes to the next the color mode. At the time of this writing, the color modes are:
- Full-color screens. The screens are colored according to mode and context as described above.
- Green. All components of the screen are green.
- Yellow. Like above, but yellow.
- Cyan. Like above, but cyan.
- Pink. Like above, but pink
- White. Like above, but white
In some instances (e.g. high ambient light) selecting a specific color (green or yellow) may improve readability of the screen. These settings selected by the switch are saved in EEPROM (10 seconds after the mode was last changed) so that they are retained following a power-cycle.
* * * * * * *
The hardware
Several bits of hardware are required to do this conversion and if you are of the ilk to build your own circuits, nothing is particularly difficult. Personally, I spent at least as much time making brackets and pieces and mounting the hardware in 4031 as I did writing the firmware.
Sync processor:
At a minimum, the "simple" sync processor mentioned above (Figure 4) is required to provide a synchronization pulse that is recognizable by the converter board. If one doesn't wish to have different color modes available, this is certainly an option.
Having said that, the "colorized" 4031 afforded by the circuit described in Figure 8 is quite nice - perhaps a bit of an extravagance. If the 4031 were originally equipped with a color monitor, I can imagine it looking something like the the images in the "Gallery" section of this article, below.
"Where's the PCB?"
As can be seen in Figures 9 and 21 the circuit in Figure 8 was constructed on glass-epoxy perfboard - the type with individual rings around each hole: I did not design or lay out a PCB as I could build 2 or 3 of these in just the time that it would take to do so - and that wouldn't include the revisions or debugging.
Constructed in this way, I could easily try out new ideas - one of which was the later addition of the "D_RED", "D_GREEN" and "D_BLUE" brightness controls which were included on a whim fairly late in testing: This was trivial to test and add to the perfboard, but I would certainly have not bothered with this significant enhancement if I'd already "frozen" the design in the embodiment of a PC board.
Unless I feel inclined to build a bunch more of these, I'm not likely to design a PCB, but if YOU do, let me know so that it may be shared.
 |
| Figure 12: The GBS-8200 video converter board. This is "V4.0" of the GBS-8200 which includes an on-board voltage regulator allowing it to run from 5-12 volts. Click on the image for a larger version. |
There appear to be several versions of the GBS-8200 around - possibly from different manufacturers and some of these are designed to be operated from a 5 volt supply ONLY, but many have on-board voltage converters, allowing them to be operated from 5 to 12 volts: The version that I have is the "V4.0" board with a "5-12 volt" input which eliminates the need for yet another voltage conversion step. If you look carefully at the photo of the GBS-8200, the inductor for the buck converter is visible near the upper right-hand corner of the board, between the power connector the white video-out connector marked "P12" - but the silkscreened "DC 5V-12V" is also a big give-away!
This board, readily available via EvilBay and Amazon for well under US$40, is specifically designed to take a wide variety of RGB video formats - typically from 70s-90s video games and computers - and convert them to VGA format. There are several connectors for video input seen along the bottom edge of the photo: The three phono plugs for component video, an input on a VGA connector, and next to the VGA connector, two white headers for cable: The unit that I purchased included a cable that plugs into the header between the VGA input and the three potentiometers.
At the top of the board, the VGA connector outputs the converted video - but there is also a white header next to it with these same signals. As mentioned elsewhere, I simply soldered the six wires (R, G, B, H, V, and Ground) to the board, at this white header as I didn't happen to have another male HD-15 cable in my collection of parts.
This device can accept YUV and RGB inputs - and the latter can have either separate or composite sync inputs. As the sync signals from the 4031 are non-standard, it's required that the sync processor described above produce a composite sync and the GBA-8200 be switched to the "RGBS" mode (using the "mode select" button) where the composite sync is fed into the "H-Sync" input and the "V-Sync" input is grounded.
The RGB inputs to the GBS-8200 come from the 4031, either as a single video source that is connected to all three inputs in the case of the "simple" (monochrome) version of the sync processor or from the RGB lines of the color version. On board the GBA-8200 are three potentiometers visible in the photo above (near the lower-left corner) that are used to scale the input levels of the RGB signals to provide color tint/balance as desired. In the lower-right corner can be seen the buttons used to configure the GBS-8200.
The "Splash" screen:
I've been asked how to get rid of the "splash screen" with Chinese
characters when the unit is powered up. This is from the GBS-8200 and (apparently) cannot be removed without flashing new firmware to it - which may be possible in theory. The easiest way to suppress this screen would be to have a power-on delay of the LCD itself (or its back-light) that would wait until this screen had been displayed. Such a device could be as simple as a 555 timer driving a relay with a 5-ish second delay. Because this is a such a simple circuit - and a simple circuit board that can do this may be found on EvilBay and/or Amazon - I'll leave the implementation up to the reader.
External monitor:
The use of the GBS-8200 has an interesting implication: It would be perfectly reasonable to use an external display with a VGA input (or VGA to HDMI converter) with the 4031. This has the obvious advantage of being larger and the possibility of being placed conveniently when making adjustments where the 4031's itself may be too distant or awkwardly placed and small monitors like this are relatively inexpensive. Additionally, it offers the possibility of being able to display to a larger group of people (e.g. teaching) and being digitized and recorded, as was done with the images at the bottom of this article.
Simply connecting a monitor to the VGA output of the GBS-8200 in parallel with the built-in LCD monitor would work - perhaps even as a short, permanent cord mounted to the rear (somewhere?) or hanging out of the 4031 should this be frequently required. With a short (8", 20cm) "extension" cable permanently connected, any degradation caused by having an unterminated cable (when the external monitor was not connected) could likely be ignored and the rather low resolution of this display - as could be the slight diminution in brightness - when two monitors were connected at the same time (e.g. "double terminating"). Practically speaking, a buffer amplifier could be built to isolate the R, G, B and sync signals (using the simple emitter-follower circuit of Q1 see in Figure 8) to feed the external monitor.
Because there's no obvious place on the back panel to mount such a connector - and since I don't envision the frequent need for it - I did not so-equip my '4031.
Navigating the GBS-8200's menus
The four buttons used to configure the board are seen on the corner of the board at the top of the photo above. Initially, the GBS-8200's menu system may be in Chinese, but the 4th menu allows the selection of either English or Chinese and it is changed to English with the following button-presses:
- Menu - > UP -> Menu -> Menu
At this point the text is now in English.
Other screens include:
- "Display" - Which sets the output resolution: A setting other than 640x480 is suggested.
- "Geometry" - Which sets the position and sizes, along with how the blanking interval is to be treated. Suggested initial settings are:
- H position: 94
- V position: 26
- H size 56
- V size: 66
- Clamp st: 83
- Clamp sp: 94
- "Picture" - Which sets other display properties. A setting of 50 is suggested for Brightness, Contrast and Saturation and a value of 05 is suggested for Sharpness.
The CLAA070MA0ACW display:
This is a 7" diagonal VGA screen of 4:3 aspect ratio and is available with a driver circuit board on EvilBay for around US$50. Be sure that you get the version with the display controller board and not just the bare display panel, by itself.
This unit is rated to operate from about 6 to 12 volts, and it comes with both an infrared remote and a small daughter board and interconnect cable that replicates the functions of the remote: The remote is not required for this project as the daughter board and its pushbuttons will suffice.
 |
| Figure 13: The driver board supplied with the CLAA070MA0A0ACW LCD panel. At the top is the VGA input while the TTL to the panel is at the bottom, the back-light power connector being in visible in the lower-right corner of the board. Click on the image for a larger version. |
This unit will accept composite analog, HDMI and VGA, but it is VGA that we require, fed from the GBA-8200 via a short cable: I constructed a very short (3", 7.5cm) cable, soldering one end directly to the GBA-8200 board itself (I could find only one 15 pin HD connector) just long enough to reach the VGA input connector of the display. If desired, one could install a switch/distribution amplifier and provide a VGA connector to feed an external display - or likely get away with "double terminating" it as noted elsewhere.
This LCD came with a small board taped to the back of the display that is used to convert to a the flat ribbon cable supplied with the unit, used to connect to the display controller board via the "TTL OUT" connector: This PC board should be glued to the back of the LCD panel with RTV or other rubberized glue (but not cyanoacrylate!) to mechanically secure it or else it is likely to work its way loose and tear the cable from the LCD panel. When connecting to the "TTL OUT" connector on the main driver board, one must carefully lift up the locking lever (the black plastic piece that runs its width) from the back on the connector, slide in the cable, and push the lever back down. The cable itself isn't marked as to which way is "up", but putting it in upside-down won't damage anything - but you'll see nothing on the screen: Mark this cable when you determine its proper orientation.
There is also a short cable provided for powering the LCD panel's back light: You won't likely see anything on the panel if this is not connected!
 |
| Figure 14: The original delaminating screen protector with EMI shield, held in place with 10 screws and two brass angle pieces around its perimeter. This holds the front bezel in place. Click on the image for a larger version. |
The display is mounted "upside-down" (the wider portion of the metal border around the LCD panel being on top) to clear mechanical obstructions around the front panel of the 4031. Fortunately, configuring for this display orientation can be accommodated via a menu on the display driver board as follows:
- Select the "Function" menu
- Go to "Mode"
- Use the up/down buttons to select "SYS2"
The ONLY modification required of the 4031 to use the LCD display is mechanical. Unlike the original CRT module - which was mounted in a large cavity behind the front panel - the LCD itself is mounted to the front panel of the 4031 while the other circuit boards (sync processor, GBA-8200, CLAA070MA0ACW controller board) are mounted in the cavity formerly occupied by the CRT.
 |
| Figure 15: The original screen protector (center) and copies, sitting atop the laser cutter. These were cut from 0.060" thick poly- carbonate plastic. Click on the image for a larger version. |
Unfortunately, over the years, this sheet tends to de-laminate and "bubble", making viewing the screen rather difficult, so I duplicated a replacement using 0.060" polycarbonate using a laser cutter. The use of polycarbonate over other types of clear plastic (like acrylic) is recommended due to its resiliency: It can be bent nearly in half without breaking and is likely to stand the occasional impact from the connector of a cable or a bolt without cracking. Acrylic, on the other hand - unless it is quite thick - would crack with such abuse. For convenience, the dimensions of this screen protector are shown below.
While the original screens had EMI/RFI mesh embedded within them, these replacements will not. The "need" for such shielding may be debated, but its worth noting that many similar pieces of equipment have no such shielding. I did a bit of searching around for plastic windows with embedded mesh, but other than a few random surplus pieces here and there, a reliable source could not be found - but if you know if such a source, or even thin-wire widely-spaced mesh, please let me know.
 |
| Figure 16: The dimensions of the screen protector - just in case you might want to make your own! Click on the image for a larger version. |
The LCD, on the other hand, is a flat panel with low voltage and backed by a grounded metal plate, so the opportunity for it to radiate extraneous RF is arguably reduced.
The front face of the 4031 comes off as a unit by removing the "Intensity" control knob, the two screws on either side that hold it into the unit's frame (the "second" screws from the top/bottom) and carefully unplugging three ribbon cables. Inspection reveals that the screen protector is, itself, mounted to a bezel held in by several screws.
In my 4031, the original the (de-laminated) front screen protector is extricated by removing the ten small screws around its perimeter (Figure 14) and noting the way the pieces of brass angle that may be included are mounted - which allows it and front bezel to come out: It looks to me like this screen protector may have been replaced in the past and it could be of slightly different construction than what was provided from the factory - but this is only a guess.
 |
| Figure 17: After fully-tapping the 2.3mm screws, these aluminum angle pieces with slots were attached to the aluminum bars seen in Figure 14. It is into these bars that the LCD panel, with attached brackets, mount. Click on the image for a larger version. |
Removing the front screen protector will reveal two aluminum bars on either side - each with metal "finger stock" on the "inside" of the screen area - mounted to the front panel by countersunk screws hidden by the bezel that holds the screen cover. Inspection will reveal that there are three holes along these bars that are not tapped all of the way through. I removed these bars and purchased a 2.3mm tap and completed the threads so that I could insert 2.3mm x 6mm screws from the "other" (back) side. It would have been about as easy to have drilled entirely new holes and tapped them for 4-40 screws (or your favorite Metric equivalent) and, in retrospect, I should have probably done so.
Using scrap pieces of aluminum, a pair of angle brackets were fashioned, held to the aluminum bars by the newly-tapped screws in those bars as seen in Figure 17.
To accommodate the momentary switch, I had to file away a portion of the bracket and bar on the left side ("behind" that in Figure 17 and this not visible) as well as countersink the back side of the plastic lens bezel so that it would accommodate the mounting hardware of the momentary switch and sit flush.
Into the brackets, slots were cut with a saw - also visible in Figure 17 - and it is into those that the angle pieces - now attached to the LCD - slide to allow adjustment of depth and very slight adjustment of axial rotation. The LCD was located about 3/8" (10mm) behind the polycarbonate lens for clearance to protect the LCD panel itself should something be dropped on it - like a cable, RF connector or tool.
 |
| Figure 18: The two brackets and new screen protector mounted in the front panel assembly of the 4031. Click on the image for a larger version. |
As seen in the pictures, there is no obvious way to mount the display itself so a section of right-angle aluminum was cut and these were glued using "Shoe Goo" (a resilient rubber adhesive) to the back of the display itself, using the mounts fabricated to hold the display itself in position (described below) as a positioning guide: It's likely that RTV (silicone) would have worked as well but I would not use an ineflexible adhesive like epoxy or cyanoacrylate ("Super Glue").
As this is done, it's very important to make sure that these brackets
are installed correctly so that the display is both centered and square
with the 4031's window: I recommend actually mounting the display in place while the adhesive sets so that it perfectly fits the mechanical environment and there is no stress on the display itself as screws are tightened when it is mounted. When I did this, I put some "painters tape" on the front of the display and lightly marked it so that I could precisely set the horizontal and vertical position of the display with reference to the front bezel before the glue set.
Electrically connecting to the 4031:
 |
| Figure 19: Two aluminum angle pieces with holes were glued to the back of the LCD panel, now mounted in the front panel. Click on the image for a larger version. |
- 1, 2: +15 volts
- 3-6: Not connected
- 7: Vertical sync (positive-going pulse, TTL level, 50 Hz)
- 8: Ground
- 9: Horizontal sync (positive-going pulse, TTL level, 15.625 kHz)
- 10: Ground
- 11: Video (positive-going, TTL level)
- 12: Ground
- 13, 14: Not connected
It's perhaps easiest to empirically determine these pins by stripping a small amount of insulation from the end of the wires and using a combination of volt/ohmmeter and oscilloscope to positively identify them, the ground pins being identifiable plugging in the other end of the cable and using continuity to the chassis with the unit powered down and then (carefully!) verifying them with the unit powered up, being very careful to avoid connecting the +15 volt wires to anything else. Once identified, the wires that are marked as "not connected" were trimmed back slightly, the two +15 volt and three ground wires were (separately!) connected in parallel and the wires themselves colored using markers to aid in later identification.
Mounting the boards:
 |
| Figure 20: The "stack-up" of the boards on the mounting sled. Hidden by the ribbon cable is the sync processor, above that is the the GBS-8300 with its output VGA connector and above that is the LCD controller with 4-button daughter board. At the bottom, on the sled, may be seen the 7812 regulator used to drop the 15 volt supply to 12 volts. Click on the image for a larger version. |
While I happen to have a bunch of stand-offs in my parts bins, I could have just as easily mounted the boards using long screws or "allthread" along with an assortment of nuts and washers. These days, a more elegant custom mount could also be 3D-printed to hold these boards in place, although the metal "sled" and stand-offs offer a solid electrical connection to the chassis that may aid in RFI shielding and mitigation.
The only critical things in mounting are to provide access to the ICSP connector and R1 ("gray" adjust) on the sync processor board, the buttons on the GBS-8200, and the buttons on the daughter board on the LCD controller: All of these should be accessible with just the top cover of the 4031 removed, without needing to disassemble anything else as depicted in Figure 21.
 |
| Figure 21: Installed and powered- up, the stack-up of boards and connected LCD panel. All controls - and the ICSP connector - are accessible simply by removing the top cover of the 4031. Click on the image for a larger version. |
Powering the boards:
As noted above, the GBS-8200 is available in a version that may operate from 5-12 volts. Similarly, the LCD panel's board can also accommodate up to 12 volts - but the 4031 supplies 15 volts. During development, I ran both boards on the 4031's 15 volt supply directly with no issues, but I noted that 16 volt electrolytic capacitors were used on the inputs, so 15 volts would be pushing their maximum ratings.
Despite having no issues, I decided not to take a chance, so I added a 7812 voltage regulator, bolting it to the aluminum "sled" for heat-sinking (see Figure 20) and powering both the GBS-8200 and LCD panel from it. As seen from the diagram above, the sync processor includes its own regulator (a 7805) and it may be powered from either 12 or 15 volts.
Overall results
 |
| Figure 22: Under the shield of the "Monitor Control" board is R16, the "width" adjustment that may be use to optimize video quality. Click on the image for a larger version. |
The results of all of this work look quite good as can be seen in the picture gallery below, but there are slight visual artifacts owing to the fact that the VGA conversion is from a device (the '4031) that does not have its pixel clock synchronized with the sampling clock of the GBS-8200 - or even the horizontal sync pulse. The inevitable result is - if you look closely - that you may see some slight "glitching" on the leading or falling edge of vertical lines.
This effect can be reduce somewhat by adjusting the read-out pixel clock from the 4031's Monitor Control board. Located on this board, under the shield, is potentiometer R16. Nominally set to 11.0 MHz (as monitored at test point "Mp10") the frequency of this clock output may be reduced by turning this potentiometer slightly clockwise, reducing the effects of this aliasing somewhat by increasing the "width" of the display by making it output the line of video "slower".
If this adjustment is done, it should be done iteratively: If it is set too low, the beginning of the line will start before the current line has finished drawing causing you to be able to see the left edge of the screen along the far right edge. By adjusting the "Horizontal Width" on the GBS-8200, some of this overlap can be moved off the right edge of the screen so a balance between this and a low clock frequency must be found. The approximate frequency set by R16 after this adjustment is between 7.75 and 8.0 MHz.
As mentioned earlier, trying to set a color horizontally across a scan line is not really practical: The fact that, as we have seen, the pixel read-out rate is a free-running oscillator that is not synchronous with any of the the video sync pulses, so there is no "easy" way to synchronize a clock signal to set color attributes along the scan line from the video information alone. To do so would require a sample of the pixel clock itself from the Monitor Control board!
In theory, it may be possible to tie the internal pixel clock to an already-existing clock signal on the Monitor Control board (e.g. the 8 MHz clock) to allow this and to reduce the "glitching" that is sometimes visible: This modification is open to investigation.
The following are screen captures obtained by first connecting a VGA-to-HDMI converter to the VGA output of the GBS-8200 board, and then connecting the HDMI output to a USB3 HDMI capture device meaning that the image is re-sampled several times in the process, accumulating artifacts.
 |
| Figure 23: The main "RX FM" screen. The top portion is colored as light magenta to indicate an RX-FM screen while the center portion is colored in yellow. The "soft" buttons on the bottom of the screen are given the attribute of a "gray" color. Click on the image for a larger version. |
 |
| Figure 24: The TX FM screen, the top portion color-coded as light-cyan. Click on the image for a larger version. |
 | |
| Figure 25: The "duplex" screen, the top portion color-coded as light-green. Click on the image for a larger version. |
 |
| Figure 26: The "oscilloscope" screen. Because it is an "RX FM" screen, the top portion is colored with light-magenta, with the portion with the scope trace is colored light yellow. Click on the image for a larger version. |
 |
| Figure 27: The analyzer display, color coded as light cyan as it's one of the "TX FM" modes. Click on the image for a larger version. |
 |
| Figure 28: The Modulation Monitor "Zoom" screen, color coded as light magenta as it's one of the "RX FM" modes. Click on the image for a larger version. |
Video captured from the 4031:
Here is a short video,captured from the output of the GBS-8200, as the various screens are selected on the 4031:
At the end of the video, the monochrome modes (green, yellow, etc.) are selected in sequence.
Remember: The video on the LCD mounted in the 4031 looks quite a bit better than is represented in the video - not only because it's a smaller screen, but the capturing of the video from the VGA output added yet another stage of analog digitization/degradation - plus there are artifacts from the YouTube video compression as well.
* * * * * * * * * * * * * * * *
Why use a PIC?
One might ask, "Why did you do this with a PIC rather than an Arduino or a Raspberry Pi?"
First, I've been using the PIC Microcontrollers since the early 1990s, making good use of the CCS "PICC" compiler - (LINK) for much of this time: This compiler is capable of producing fairly tight and compact code and I'm very familiar with it. The PIC16F88 was chosen because it has the necessary hardware peripherals, it's easy to use, has plenty of RAM, program space and speed for this task, and is still available in DIP (and SMD) packages - a real plus in these days of "supply chain" issues.
The code running on the PIC uses interrupts and as such, it's possible that its same function could be done on a lower-end Arduino UNO as that processor sports similar hardware capabilities - but it's unlikely that this could be done using the typical Arduino IDE sketch environment, which does not, by default, lend itself to latency-critical interrupt processing. You would have to get much closer to the "bare metal" and implement lower-level interrupts and some careful coding (possibly in mixed "C" and assembly) in order to have the code operate fast and consistently enough to do the pixel counting.
Another possibility is to use an ESP8266 or ESP32, but again one would need to get closer to the "bare metal" and optimize timing of the code to handle this sort of task - and you would still need to have the same sort of hardware (sync reprocessor, control of the RGB) signals.
Finally, a Raspberry Pi - if you can get one - would be overkill - and it would take MUCH longer for the RPi to boot up than the service monitor, which is up and running in under 15 seconds from power-up: You would still need to interface the same signals (sync, video), but to 3.3 volt logic, and you would still need the same hardware (analog switches, etc.) to modify the video attributes - not to mention the time-critical code on a non-realtime operating system to do the pixel counting but this task could be done with additional hardware if needed.
Where can I get the code?
You may find the source code (for the CCS "PICC" compiler - I used version 5.018) and a compiled .HEX file for the PIC16F88 at the following links:
The .HEX code above is suitable for "burning" into a PIC16F88, and I use the PicKit3 programmer's ICSP (In Circuit Serial Programming) for this: It's possible to reprogram the device in a powered-up 4031 - but because the code is written to detect when the ICSP is connected, it won't resume normal operation until the cable is disconnected.
As mentioned before, I have only one version of the 4031, so if your device has "different" screen signatures that result in pixel counts that don't match what's in the code, that screen will be rendered with white text. Due to the complexity of the screen detection via pixel counting, making the recognition of the screen an automated process so that one could provide user-defined configurations would require a significant addition to the code - and likely the need for much more code space.
With the information provided it should be possible to apply this technique using other hardware platforms/microcontrollers - provided that one has either the speed to reliably count pixels at MHz rates and/or is able to get close enough to the "bare metal" of the processor to use on-chip peripherals to aid in the task. In either case, close attention to the way the code operates - possibly a bit of optimization - will likely be required to pull off this task.
Final comments:
The most obvious change in the appearance of the 4031 after the modification - other than the colorized screen - is that of readability. Clearly, the replacement of the degraded screen protector improved things considerably!
One advantage of the CRT - assuming that it is in good condition - is that it can be very bright, meaning that the LCD is at a slight disadvantage where high ambient light might be an issue: In this case, one of the available "monochrome" modes may help.
The most obvious disadvantage of the LCD is that unlike the CRT, which has essentially a Lambertian emission profile from its surface (e.g. it radiates light hemispherically from the plane of the surface of the CRT), the LCD, by its very nature, has a comparatively reduced viewing angle.
When faced with viewing difficulties one would, in practice, simply relocate or reposition the 4031 so that it was more favorably oriented - and in some instances switching to one of the large "Zoom" screens may help when reading from a distance and/or awkward angle: If you wish to do so, you could take advantage of the ability to use an external LCD monitor (small 7" units are fairly inexpensive) as described above.
Installing an LCD panel - with a blemish-free screen protector - and having "colorized" screens is a nice "refresh" of the 4031, particularly if you have been dealing with an ailing CRT for which there is no modern, drop-in equivalent.
* * * * * * * * * * *
This page stolen from ka7oei.blogspot.com
[END]
