- Sat Aug 07, 2010 6:23 pm
#106944
I recently bought a TDS510 scope from Ebay. However the anti-glare glass was broken. I also didn't like the CRT display very much. But there is hope: the display system in a TDA500 series oscilloscope is nothing more than a VGA monitor. Some models even have a VGA connector to connect an external monitor.
There are kits for sale on Ebay with which you can replace the CRT with an LCD screen. These kits usually consist of a screen, an inverter to drive the CCFL backlight and an analog VGA to LCD converter. The price is a couple of hundred dollars.
I figured there must be an easier way to connect an LCD display using the digital signals. On Tektronix's website I found the TDS520B component service manual which has full schematics. These schematics are also valid for most other TDSS500 scopes. I haven't found any differences for my TDS510A. Back to using the digital signals. It appears the oscilloscope is using two planes with 16 'colors' each. These are converted into analog signals by a RAMDAC. I used a logic analyzer to see how the color indexes are used. It seemes that each index has a certain use. The signal plane is even worse: depending on the display mode it uses 5 shades or 15 shades. The video data going into the RAMDAC consists of 5 signals. Four signals for the color and one signal for text or signal plane.
Now lets focus on the LCD screen a bit. An LCD screen usually takes 4 to 8 bits of color data, a pixel clock, hsync, vsync and data enable. Some older displays need other timing signals as well. We need to figure out a way to take the video, synchronisation and clock signals from the scope and transform them into signals which make sense for an LCD screen.
The problem is that the RAMDAC needs to be simulated in some way. This could be done by using an FPGA which simulates the RAMDAC in the scope (palette snooping) and generates the proper color and timing signals. This is a lot of work and the FPGA needs a dedicated PCB. Besides that, an FPGA usually requires some external storage for its configuration data. Low cost and easy to build tends to get out of sight here. I wanted something that can be build on a prototyping board so I starting thinking about a really simple solution. What if I could take the 5 video signals and use a look-up table for the video data. Some registers and RAM would do the trick. Maybe a microcontroller to fill the RAM and use the microcontroller's timer to generate the timing signals (we need the data enable signal). This solution still requires making a PCB and quite a lot of components. The pixel clock is 25MHz. Even with fast RAM it will take extra registers to comply with the timing requirements of the LCD screen
But... what if some CPLD could be programmed to perform the same function? I looked at several CPLDs until I found a Xilinx XC9572XL. It can be programmed using Xilinx's free version of ISE together with a simple parallel cable and it costs a few dollars in single quantities. The only downside is that it runs from 3.3V but it does have 5V tolerant I/O. But would it be up to the task? I've never used this device before so I'm getting into uncharted areas.
I came up with the following diagram:
The signals can be easely connected to the main-board. The pixel clock can be taken from U190 pin 40 (its on the corner), the inverted video data can be taken from U253 (in0=pin 1, in1=pin3, in2=pin5, in3=pin9, in4=pin 11), hsync can be taken from J88 pin 5 and vsync can be taken from J88 pin 4. The power can be taken from the pads from Y3 (14=+5V, 7=ground).
The output depends on the connector on the LCD screen. In my case it was a 31 pin DF9 connector. I used seperate wires and soldered them directly to an SMD style DF9 connector. I then used hot-glue to fixate the wires on the connector. I tied the wires into a bundle to improve signal integrity using waxed nylon strands (better known as Dental floss). BTW I often use hot-glue as instant strain relief.
This is the VHDL code:
- Making all signals positive logic. These statements are non-registered so it is absorbed into the equations later. Merely a cosmetic thing.
- Edge detectors for Hsync and Vsync.
- Pixel and line counter so we can keep track of where we are on the screen
- data enable signal generator (data enable must be set high for the LCD to accept data)
- Signal plane detector (5 shades or 15 shades)
- Color data generator
The best thing is: the XC9275 is actually way to big for this job. I thought it might run out of logic because of the lookup-tables but those are absorbed in the equations nicely.
As an extra feature I added the possibility to invert the video using a jumper. The planes_out pin is a debug pin to see if detecting the number of planes is working properly. As you can see there are three seperate color look-up tables. I choose the values for a setting which I like but you could tinker a bit more with it. Also note that the intensity settings on the scope no longer work. These modify the RAMDAC settings. The CPLD doesn't see those settings ofcourse. IMHO this is not a problem because an LCD is superior to a CRT anyway. If you want brightness control do so by adjusting the backlight. Also don't hate me for choosing VHDL. It simply was the easiest way for me to get the logic for the CPLD together.
Below the UCF file with pin and timing information:
I've choosen the pinout in such a way so that most of the signals are on the outer ring of the PLCC socket.
The 74HCT573 is used as a 3.3V to 5V level converter. The screen I used required the clock, vsync, hsync and data enable to be driven from a 5V source. The old style TO220 device is a LM1117-3.3V. The TO220 package can dissipate enough heat to supply a 3.3V LCD screen if necessary. The blue jumper allows me to choose between normal and inverted video. It has been a long time since I've soldered so many through hole components on a board. Ofcourse there is some SMD at the bottom. Several 100nf caps to decouple the regulator, CPLD and the '573.
Now on to modifying the scope. I've build the screen into the aluminium frame which holds the anti-glare glass and the contact foil for the rubber buttons. I had to cut a bit of the screen to make it fit though (the little PCB sticking out is not normal
.
Next I removed the CRT screen from the scope. It doesn't look like it but it is possible to take the CRT and driver board out through the front without disconnecting the anode from the CRT. After removing the CRT I mounted 2 vertical aluminium L profiles on the CRT mounting point. I put extra rubber foam strips on them to keep the display in place. I used the left one to also hold the backlight inverter. The backlight inverter is powered by a DC-DC converter (the small black/pink block at the top of the backlight converter) from the 24V supply which is taken from the connector which connected to the CRT driver board.
And here is the end result:
But I like reverse video better. Now it just looks likes a much newer scope!
And this goes on Ebay:
Some remarks: Before attempting to tinker with a TDS500 series scope be sure to download the service manual and the TDS520B component service manual from Tektronix. Also check the user forum at the website from Tektronix for additional information and hints.
Have (spark)fun!
There are kits for sale on Ebay with which you can replace the CRT with an LCD screen. These kits usually consist of a screen, an inverter to drive the CCFL backlight and an analog VGA to LCD converter. The price is a couple of hundred dollars.
I figured there must be an easier way to connect an LCD display using the digital signals. On Tektronix's website I found the TDS520B component service manual which has full schematics. These schematics are also valid for most other TDSS500 scopes. I haven't found any differences for my TDS510A. Back to using the digital signals. It appears the oscilloscope is using two planes with 16 'colors' each. These are converted into analog signals by a RAMDAC. I used a logic analyzer to see how the color indexes are used. It seemes that each index has a certain use. The signal plane is even worse: depending on the display mode it uses 5 shades or 15 shades. The video data going into the RAMDAC consists of 5 signals. Four signals for the color and one signal for text or signal plane.
Now lets focus on the LCD screen a bit. An LCD screen usually takes 4 to 8 bits of color data, a pixel clock, hsync, vsync and data enable. Some older displays need other timing signals as well. We need to figure out a way to take the video, synchronisation and clock signals from the scope and transform them into signals which make sense for an LCD screen.
The problem is that the RAMDAC needs to be simulated in some way. This could be done by using an FPGA which simulates the RAMDAC in the scope (palette snooping) and generates the proper color and timing signals. This is a lot of work and the FPGA needs a dedicated PCB. Besides that, an FPGA usually requires some external storage for its configuration data. Low cost and easy to build tends to get out of sight here. I wanted something that can be build on a prototyping board so I starting thinking about a really simple solution. What if I could take the 5 video signals and use a look-up table for the video data. Some registers and RAM would do the trick. Maybe a microcontroller to fill the RAM and use the microcontroller's timer to generate the timing signals (we need the data enable signal). This solution still requires making a PCB and quite a lot of components. The pixel clock is 25MHz. Even with fast RAM it will take extra registers to comply with the timing requirements of the LCD screen
But... what if some CPLD could be programmed to perform the same function? I looked at several CPLDs until I found a Xilinx XC9572XL. It can be programmed using Xilinx's free version of ISE together with a simple parallel cable and it costs a few dollars in single quantities. The only downside is that it runs from 3.3V but it does have 5V tolerant I/O. But would it be up to the task? I've never used this device before so I'm getting into uncharted areas.I came up with the following diagram:
The signals can be easely connected to the main-board. The pixel clock can be taken from U190 pin 40 (its on the corner), the inverted video data can be taken from U253 (in0=pin 1, in1=pin3, in2=pin5, in3=pin9, in4=pin 11), hsync can be taken from J88 pin 5 and vsync can be taken from J88 pin 4. The power can be taken from the pads from Y3 (14=+5V, 7=ground).
The output depends on the connector on the LCD screen. In my case it was a 31 pin DF9 connector. I used seperate wires and soldered them directly to an SMD style DF9 connector. I then used hot-glue to fixate the wires on the connector. I tied the wires into a bundle to improve signal integrity using waxed nylon strands (better known as Dental floss). BTW I often use hot-glue as instant strain relief.
This is the VHDL code:
Code: Select all
The code consists of several parts:library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.numeric_std.all;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity lcd_conv is
Port ( clk : in std_logic;
video_in : in std_logic_vector(4 downto 0); --video data in (inverted)
vsync : in std_logic; --vsync (low active)
hsync : in std_logic; --hsync (low active)
vid_inv : in std_logic; --0=video normal, 1=invert video
video_out : out std_logic_vector(5 downto 0);
vsync_out : out std_logic; --buffered vsync
hsync_out : out std_logic; --buffered hsync
clk_out : out std_logic; --buffered clk
planes_out: out std_logic; --buffered clk
de : out std_logic);
end lcd_conv;
architecture Behavioral of lcd_conv is
type Tcolor_table is array(0 to 15) of integer;
--Standard color table (used for text plane)
--index 0=background
--index 1=CH1 V/div
--index 2=CH2 V/div
--index 3=CH3 V/div
--index 4=CH4 V/div
--index 5=Trigger source
--index 6=???
--index 7=All text, menus, time/div, trigger level, square brackets screen position
--index 8=??
--index 9=??
--index 10=??
--index 11=graticule
--index 12=??
--index 13=Tek logo
--index 14=??
--index 15=??
-- 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
constant text_colors : Tcolor_table := (0, 48, 48,48,48, 48,15,48,15,15,15,38,15,63,15,15);
--Full gray-scale (used in persistent mode)
constant all_signal_colors : Tcolor_table := (0, 4, 8,13,17,21,25,29,34,38,42,46,50,55,59,63);
--Limited gray-scale (used in normale mode) 0 1 2 3 4 5
constant lim_signal_colors : Tcolor_table := (0, 32, 40, 48, 56, 63,others =>15);
signal video_in_pos : std_logic_vector(4 downto 0); --video in positive
signal vsync_pos : std_logic;
signal hsync_pos : std_logic;
signal vsync_delayed : std_logic; --inverted vsync_pos delayed by 1 cycle
signal hsync_delayed : std_logic; --inverted hsync_pos delayed by 1 cycle
signal vsync_pulse : std_logic; --active for 1 cycle at the start of vsync
signal hsync_pulse : std_logic; --active for 1 cycle at the start of vsync
signal line_counter : std_logic_vector(8 downto 0);
signal pixel_counter : std_logic_vector(9 downto 0);
--counter used to detect whether the display is using 15 shades or 5 shades
signal shades_counter: std_logic_vector(3 downto 0);
signal use_15_shades : std_logic;
signal draw_signal : std_logic; --1 if the current pixel is part of a trace
--this is actually an alias of video_in_pos(4)
signal de_int : std_logic; --internal DE signal
begin
--signal assignments
video_in_pos <= not video_in;
draw_signal <= video_in_pos(4);
vsync_pos <= not vsync;
hsync_pos <= not hsync;
de <= de_int;
clk_out <= clk;
planes_out <= use_15_shades;
main: process(clk)
begin
if rising_edge(clk) then
--edge detector delay
vsync_delayed <= not vsync_pos;
hsync_delayed <= not hsync_pos;
--egde detector
vsync_pulse <= vsync_pos and vsync_delayed;
hsync_pulse <= hsync_pos and hsync_delayed;
--line counter
if vsync_pulse='1' then
line_counter <= (others=> '0'); --reset
--decrement shades counter for each refresh
if shades_counter>0 then
shades_counter <= shades_counter-1;
end if;
else
if hsync_pulse='1' then
line_counter <= line_counter +1;
end if;
end if;
--pixel counter
if hsync_pulse='1' then
pixel_counter <= (others =>'0');
else
pixel_counter <= pixel_counter +1;
end if;
if (line_counter>=27) and (line_counter<(480+27)) then
if (pixel_counter>=(40+96)) and (pixel_counter <(640+40+96)) then
de_int <='1';
else
de_int <='0';
end if;
else
de_int <='0';
end if;
if (video_in_pos(4)='1') and (de_int='1') then
--The scope is drawing a pixel which is part of a signal trace.
--Now detect if it is using 15 shades or 5 shades
if video_in_pos(3 downto 0)>7 then
if shades_counter<15 then
shades_counter <= shades_counter+1; --count up if not at the limit
end if;
end if;
end if;
--make the signal which defines the number of shades to use
if shades_counter/=0 then
use_15_shades <='1';
else
use_15_shades <='0';
end if;
--Create video output. This looks a bit abfusticated with the
--loops but the loop is actually a way to use a signal (vector)
--as an array index.
if (video_in_pos(4)='1')then
--drawing signal plane
if use_15_shades='1' then
--use 15 shades
for i in 0 to 15 loop
if i=video_in_pos(3 downto 0) then
if vid_inv='1' then
video_out <= not std_logic_vector(to_unsigned(all_signal_colors(i),video_out'length));
else
video_out <= std_logic_vector(to_unsigned(all_signal_colors(i),video_out'length));
end if;
end if;
end loop;
else
--use limited shades
for i in 0 to 15 loop
if i=video_in_pos(3 downto 0) then
if vid_inv='1' then
video_out <= not std_logic_vector(to_unsigned(lim_signal_colors(i),video_out'length));
else
video_out <= std_logic_vector(to_unsigned(lim_signal_colors(i),video_out'length));
end if;
end if;
end loop;
end if;
else
--text plane
for i in 0 to 15 loop
if i=video_in_pos(3 downto 0) then
if vid_inv='1' then
video_out <= not std_logic_vector(to_unsigned(text_colors(i),video_out'length));
else
video_out <= std_logic_vector(to_unsigned(text_colors(i),video_out'length));
end if;
end if;
end loop;
end if;
--copy vsync and hsync
vsync_out <= vsync;
hsync_out <= hsync;
end if;
end process;
end Behavioral;
- Making all signals positive logic. These statements are non-registered so it is absorbed into the equations later. Merely a cosmetic thing.
- Edge detectors for Hsync and Vsync.
- Pixel and line counter so we can keep track of where we are on the screen
- data enable signal generator (data enable must be set high for the LCD to accept data)
- Signal plane detector (5 shades or 15 shades)
- Color data generator
The best thing is: the XC9275 is actually way to big for this job. I thought it might run out of logic because of the lookup-tables but those are absorbed in the equations nicely.
As an extra feature I added the possibility to invert the video using a jumper. The planes_out pin is a debug pin to see if detecting the number of planes is working properly. As you can see there are three seperate color look-up tables. I choose the values for a setting which I like but you could tinker a bit more with it. Also note that the intensity settings on the scope no longer work. These modify the RAMDAC settings. The CPLD doesn't see those settings ofcourse. IMHO this is not a problem because an LCD is superior to a CRT anyway. If you want brightness control do so by adjusting the backlight. Also don't hate me for choosing VHDL. It simply was the easiest way for me to get the logic for the CPLD together.
Below the UCF file with pin and timing information:
Code: Select all
In hardware it looks like this:NET "clk" TNM_NET = "clk";
TIMESPEC "TS_clk" = PERIOD "clk" 40 ns HIGH 50 %;
OFFSET = IN 6 ns BEFORE "clk" ;
OFFSET = OUT 6 ns AFTER "clk" ;
#PACE: Start of Constraints generated by PACE
#PACE: Start of PACE I/O Pin Assignments
NET "clk" LOC = "P5" | BUFG = CLK ;
NET "clk_out" LOC = "P29" ;
NET "de" LOC = "P37";
NET "hsync" LOC = "P9" ;
NET "hsync_out" LOC = "P33";
NET "planes_out" LOC = "P39" | SLEW = SLOW ;
NET "vid_inv" LOC = "P11" ;
NET "video_in<0>" LOC = "P40" ;
NET "video_in<1>" LOC = "P42" ;
NET "video_in<2>" LOC = "P44" ;
NET "video_in<3>" LOC = "P2" ;
NET "video_in<4>" LOC = "P4" ;
NET "video_out<0>" LOC = "P18" | SLEW = SLOW;
NET "video_out<1>" LOC = "P20" | SLEW = SLOW;
NET "video_out<2>" LOC = "P22" | SLEW = SLOW;
NET "video_out<3>" LOC = "P24" | SLEW = SLOW;
NET "video_out<4>" LOC = "P26" | SLEW = SLOW;
NET "video_out<5>" LOC = "P28" | SLEW = SLOW;
NET "vsync" LOC = "P7" ;
NET "vsync_out" LOC = "P35";
I've choosen the pinout in such a way so that most of the signals are on the outer ring of the PLCC socket.
The 74HCT573 is used as a 3.3V to 5V level converter. The screen I used required the clock, vsync, hsync and data enable to be driven from a 5V source. The old style TO220 device is a LM1117-3.3V. The TO220 package can dissipate enough heat to supply a 3.3V LCD screen if necessary. The blue jumper allows me to choose between normal and inverted video. It has been a long time since I've soldered so many through hole components on a board. Ofcourse there is some SMD at the bottom. Several 100nf caps to decouple the regulator, CPLD and the '573.
Now on to modifying the scope. I've build the screen into the aluminium frame which holds the anti-glare glass and the contact foil for the rubber buttons. I had to cut a bit of the screen to make it fit though (the little PCB sticking out is not normal
.
Next I removed the CRT screen from the scope. It doesn't look like it but it is possible to take the CRT and driver board out through the front without disconnecting the anode from the CRT. After removing the CRT I mounted 2 vertical aluminium L profiles on the CRT mounting point. I put extra rubber foam strips on them to keep the display in place. I used the left one to also hold the backlight inverter. The backlight inverter is powered by a DC-DC converter (the small black/pink block at the top of the backlight converter) from the 24V supply which is taken from the connector which connected to the CRT driver board.
And here is the end result:
But I like reverse video better. Now it just looks likes a much newer scope!
And this goes on Ebay:
Some remarks: Before attempting to tinker with a TDS500 series scope be sure to download the service manual and the TDS520B component service manual from Tektronix. Also check the user forum at the website from Tektronix for additional information and hints.
Have (spark)fun!
The PCB is the same but in monochrome scopes the color framebuffer components are left out. The TDS500 with a color display series uses a monochrome CRT and an LCD shutter to create color images. This is an interesting article about that (now obsolete) technology: