Sunday, December 24, 2017

Fixing an Eurocolor CTV2146-TXT CRT TV

There's been quite some time since posting on the blog, mainly because I didn't have too much time to fiddle with electronics, at least not as much as I'd like to. There are quite a lot of projects that will soon be finished though, so make sure to check around from time to time.

In this post I'd like to talk about a recent repair job on an old TV set which a friend brought me to fix. I am not an electronics engineer nor do I have too much experience with fixing TV sets but I love a challenge every now and then.


The patient

This TV is a Eurocolor CTV2146-TXT, old CRT technology from early 2000s (I think it was manufactured around 2004). CRTs are still fairly popular in some parts of Eastern Europe, mainly because of their lower cost and relative serviceability. Even though major companies like Samsung or Sony which had a big market share in CRT TVs have since moved on to newer technologies like plasma, LCD or LED displays, there are some smaller firms like Vestel from Turkey (the OEM for lots and lots of cheap CRTs) which still sell them. And they sell well, especially since the people were disappointed with all the planned obsolescence that newer tech has. Another key factor that has discredited the new products in the eyes of some consumers is the capacitor plague which has rendered many of the early LCD TVs and monitors useless after only 1-2 years of use. Sadly, this trend seems to continue, see Samsung's LCD TV problem after they used the troublesome Samwha WB series electrolytics in the power supply.

So yeah, one can't blame the people for wanting to stick to technology that has been proven somewhat reliable, especially with all the latest economic problems and constantly increasing prices for bells and whistles.


The problem

Getting back to the patient, after the workout (getting the thing in the house), I turned on the power and the problem revealed itself right away. The colors looked all mixed up, especially around the edges of the screen. It's like a whole area was showing different colors than it should have, with a magenta / violet tint. Here are a few pictures that explain things better:

Note the color at the top, blue instead of green




Feeding the TV a blue picture via the A/V port showed the problem a little better:


Since CRT TVs are based on analog technology and there aren't many things inside that can fail in order to show symptoms like those, the first suspect I had in mind was the CRT picture tube itself (also because the problem was affecting only an area of the screen). Oddly enough though, when navigating to an empty channel, the black and white image appeared OK:

Had the CRT been the culprit, there should have been problems with a B&W picture as well
So the tube also seemed to be in good working order. And then I remembered I saw these kind of colors somewhere else: when I was little and I got a magnet close to the screen of our first color TV, thinking of what my parents would say. Luckily, the old unit fixed itself after turning it off and on again. Another clue was the fact that most CRTs I know made a loud thud when turned on, thing which didn't happen with this one. The sound is made by the degaussing circuit which involves creating a strong magnetic pulse along the edge of the picture tube with the help of a coil. This pulse resets the stray magnetic fields that are picked up by the shadow mask, a metal mesh that's built in the picture tube. If the shadow mask is magnetized (even slightly), the electron flow through it is disturbed, generating anomalies on the display.

So I proceeded to open the case and have a look inside. The PCB had some signs that suggest that the TV has been repaired before (an electrolytic cap and a resistor were replaced), but other than that it seemed OK, no burn marks or anything suspicious.

The 11AK30 A4 chassis
Exactly as I feared, the board was full of G-Luxon crapacitors (which were a big part of the cap plague). Vestel didn't even bother to use 105 degrees rated capacitors and went with 85 degrees. That's really a big no-no, especially since CRTs can get hot while working.

Not the best choice for caps, but a very cheap one

To make things even worse, some of the joints looked like the one below. I wonder how this TV was even turning on.


Some other details:


ST92195C microcontroller made by STMicroelectronics


STV2248C video processor made by STMicroelectronics

Tuner TECC2949VG28B made by Samsung

Studying the schematic (see the end of the article for download) revealed that the degaussing circuit is made from a 9 ohms PTC (TH800, MZ72AL 9RM) in series with a coil wound around the screen. When powering on the circuit, the sudden inrush of current creates a magnetic pulse and quickly heats up the PTC, which in turn decreases the current through the coil. As long as the PTC remains hot, the current through the coil is very small. The coil itself was fine, measuring around 2 ohms so I proceeded to remove the PTC from the board. Opening its case revealed the following mess:

MZ72AL-9RM PTC used in the degaussing circuit. Note the burn marks.

The PTC pill looked severely burned, and so did one of the springs. I bet this was the result of a power surge, possibly from a lightning strike in a storm. I couldn't find the exact part, so I ordered a generic 9 ohm PTC instead and also got replacement electrolytic capacitors for everything on the board.

Taking the garbage out
After the boring job of replacing each and every electrolytic, soldering in the new PTC and touching up the cracked solder joints, the problem disappeared completely. It's been around a week now and no magic smoke escaped, so I'll consider this repair a success.

Things look normal again

No more discoloration
For anyone that encounters problems with this TV, I have put together an archive with the schematic, the service manual and the EEPROM dump at the link below. They should be good for all TVs equipped with the 11AK30 A4 chassis.

Eurocolor CTV2146 TXT 11AK30 A4 schematic, service manual and EEPROM dump (Google Drive)


To conclude, if I were ever asked an opinion about this technology, I'd say the following:

The good:
  • Good viewing angles amp; contrast, bright colors
  • High lifespan when engineered correctly (I still have in storage a Samsung from 1997 in perfect working order)
  • Reliable (if quality parts are used), proven technology
  • No privacy concerns unlike smart TVs
  • Cheap!

The bad:
  • High power consumption compared to LCDs (but not even close to what plasmas burn)
  • Heavy... This thing weighs almost 20 kilograms!
  • Bulky because of the long neck of the CRT tube
  • Obsolete from a moral standpoint
  • They are becoming pretty rare

Thanks for reading and see you all in the next year!

Monday, February 27, 2017

Communicating with AVRs via serial (USART). Poorman's isolated RS232 to TTL interface

AVR and serial (RS232) communication

I've been trying to build a new project based on the AVR for about a week and I needed to find a way to communicate with the MCU on the breadboard for debugging purposes. Up until now the projects I worked on were quite small and simple so no communication with the PC was needed, but this has changed. One way of achieving my goal is by using the USART capability of the AVR which has some nice features:

  • Full duplex connection
  • Serial frames with 5 to 9 data bits and 1 - 2 stop bits
  • Sync or Async operation modes
  • High resolution baud rate generator
So far so good, the only thing left is to find a way to interface it with the PC.


First try: disaster

Since my desktop computer has a serial port (RS232) header, I decided to use it instead of an USB RS232 to TTL converter. The main reason for this choice is because I had a few ST232 chips in my parts box that I wanted to put to use. The ST232 is a 5V powered multi-channel RS-232 driver and receiver compatible with MAX232.  By following the datasheet, I built this circuit:
First try at a RS232-to-TTL interface

As you can see, it's made up of the ST232 level converter, a few polarized capacitors used by its charge pumps and the DB9 connector. Note that both the ST232 and the ATMEGA share the same power supply and ground. The +5V power comes from my lab PSU.

I have used the above circuit for a few days without any trouble until one time when the microcontroller simply refused to program. Oddly enough, it was correctly detected by avrdude, it accepted all the commands and received the data sent to it, but upon verification the flash memory was completely filled with nulls. Thinking it was just a bad microcontroller, I replaced it with another one (bought in a different store to eliminate the probability of a bad batch) and then with third one (ATMega 8). Again, everything went well until the MCU simply died between 2 power cycles. This is when I understood that the ST232 circuit was somehow responsible for killing the ATMEGA chips. There were no other components on the breadboard, just the MCU and ST232 circuit. ESD is also excluded since I had ESD protection gloves on at all times.

Here all the voltage levels for the circuit while it's powered on and after the lab power supply is turned off and the ST232 circuit remains plugged in the computer RS232 port:


Measuring some points in the above circuit

As you can see from the picture, the circuit is working normally while it's powered, but when the lab power supply is disconnected (and the RS232 connection is still maintained with the PC), the power rail (VCC) dips to -513 mV (-0,513 volts). If you are unlucky to have other ICs on this rail, they could be destroyed.

According to the Absolute Maximum Ratings table in the datasheet of the ATMega8, voltage on any pin except RESET (with respect to Ground) should be between -0,5V and VCC + 0,5V and voltage on the VCC pin 1.8V to 5.5V. Clearly, the -0,513 volts that is leaked by the ST232 IC is out of spec for the MCU, thing that lead to it being destroyed after a few power cycles. While AVRs are pretty tolerant, there are some other ICs out there that are much more sensitive so if you are using such a RS232 to TTL converter chip (be it ST232 or MAX232), make sure to first disconnect the RS232 plug from the PC and only after that turn off power to the circuit.


A solution

In order to communicate with the AVR without risking to destroy it, I made an inexpensive RS232 to TTL interface using only common parts. The interface is galvanically isolated so the AVR will have great protection against power surges or current leaks. One drawback of using cheap components is that transfer speeds will not be too big, but it should be enough for debugging some simple projects.

Specifications:
  • Principle of operation: voltage level conversion with PC817C (or CT817C, EL817C, etc.) optocoupler / optoisolator
  • Operating voltage (TTL side): 3V to 5V (one resistor value needs to be changed for switching the level)
  • Operating voltage (RS232 / PC side): same as the serial port DTR / RTS lines (it harvests power from these lines)
  • Maximum data rate: 4800 Baud half-duplex

Requirements:
  • It needs the software to set the RTS line to logic 0 (which provides +10V) and the DTR line to logic 1 (which provides -10V). The circuit will not work if these lines are not configured correctly. Not all software can toggle these lines. For Linux one can use GTKTerm and for Windows RealTerm.
Schematic: 
Poorman's isolated RS232 to TTL interface

The circuit is pretty simple. The positive part of the Tx RS232 signal from the PC passes through D1 then fed into the led of U1 via the resistor R1. The led sees about 5 mA of current. On the output side, optocoupler U1 is wired as common collector so the signal will be the same polarity as the one in the RS232 port, but at TTL voltage. R2 is chosen with a low value in order to improve the rise / fall time of the waveform and decrease the phototransistor switching time. The signal is then fed into an inverting, common emitter buffer comprised of Q1 and load resistor R4.

On the transmitter side, the signal is fed into the led of U2 via the resistor R5 (which can be changed to work with 2 different voltage levels, see the schematic). On the output of U2, the voltages used for the signals are harvested from the RTS (+10V), DTR (-10V) lines, so the software must toggle the lines accordingly. The phototransistor and the PNP transistor Q2 are arranged in a cascode configuration to get an improved rise and fall time. The cascode configuration is great for a circuit like this because the phototransistor does not see the load resistor R7, it only sees the internal resistance of Q2, which is quite small.

Here's an example transmission on the screen of an old scope:

Sending a letter via GTKTerminal

The waveforms above were created by continually sending the "V" character at a rate of 4800 bps, 8 data bits, 1 stop bit, no parity. The power supply on the TTL side is 5 Volts and the scope is set to 5V / div & 0,5 mS / div for the timebase. The first picture shows the TTL output (that goes to the MCU's Rx pin) and the second one the RS232 output (that goes to the PC's Rx pin).

The voltage levels on the RS232 side are not perfect (e.g. +-12V) because the control lines can only supply 10V a few mA of current and there is also a voltage drop across the diodes. But this shouldn't matter since for RS232 the space (0 or ON) condition is indicated by +3 to +12V and a mark (1 or OFF) condition anything from -3 to -12V.  Judging from the oscillogram above, the circuit should work just fine (not to mention that modern RS232 transceivers are forgiving, with some sensitive enough to work with +-2V signals).


So what speed can this be used at?

First, it should be noted that PC817C (and equivalents) are quite slow (with maximum Tr / Tf of around 18 μs with RL of 100R depending on the manufacturer and sample). To be sure that the circuit works reliably I'll use the worst case scenario for the rise and fall times (e.g. 18 μs) for both optocouplers, but just as an exercise, let's calculate the speed for each of them:

For U1, speed is dictated by the load resistor R2, so the slowest time will be 18 μs (as per the datasheet).

For U2, the phototransistor only sees the input resistance of Q2. Considering that the led of U2 is powered with around 5,5 mA of current and with a failsafe value of 135% CTR for CT817C (taking into account temperature and aging of the device and substracting them from the 200% CTR that the manufacturer claims), Ic will be at

Ic = 1,35 * 5,5 = 7,42 mA. 

To calculate the internal resistance Re of Q2, we use the following formula:

Re = 25 mV / Ic (in mA) = 25 / 7,42 = 3,36 Ohms

This low resistance will ensure good switching time, but I want to be on the safe side so I'll consider it equal with the time above (18 μs), not to mention that the datasheet doesn't show the timing values for load resistors less than 100R. The minimum bit time should be kept to 1/10 of the baud rate so we can calculate it like this:

Mbt = 18 μs * 10 = 180 μs

To work reliably, the circuit must work at a baud rate that has a bigger bit time than the one calculated above. Knowing that the bit time for an arbitrary baud rate can be calculated by dividing 1 second to the baud rate, the following table can be devised:

Baud rate Bit width (μs) Max rise/fall time (μs)
1200 833 83,3
2400 416 41,6
4800 208 20,8
9600 104 10,4
19200 52 5,2
38400 26 2,6
57600 17 1,7
115200 8 0,8


Since the fastest speed with a bigger bit width than 180 uS is 4800 baud, this will be the max rate at which this circuit circuit is considered reliable. Higher speeds would be attainable by using fast optoisolators like 6N137, but much of the schematic would need modification.