OK, I promise this is the last post to this thread, but I just had to add this final note due to an unexpectedly great outcome.
I thought I'd take one more kick at the can before junking this turkey, so I added both a dummy load and zener clamping to the 12V rail and replaced the few small blown semis on the motherboard. Incredibly, the Dell logo came up again and it looked promising, but alas, it stopped at the same blanking point, this time just shutting the TV off rather than going through audible, destructive power cycling. The clamp and dummy load were protecting the rail converter, but something was still going wrong. Watching the 3.3V rail during this event, it would sharply collapse to about 1.5V at the moment the display blanked, as if it was suddenly overloaded. I scanned the schematic for any power switches on the rail but it seems everything is fed directly. I wondered then if the switcher was going unstable due to load transient as the set enables all the power hungry RF and receiver/decoder engines.
Playing a hunch about the seriously inadequate input decoupling, I replaced the 3 paltry 22uF electrolytics with a couple 10uF ceramics and a large 1000uF low ESR electrolytic. Powering up this time, the backlight stayed on when the set blanked the logo, then the input select dialog box came up. I quicky connected an antenna COAX feed and selected the Digital Air mode. When a broadcast picture appeared and the sound came on, I was elated. The set has been in use now for the last few weeks without signs of any problems.
At serious risk of flogging a dead horse here, some new findings make this epilogue warranted. I realized my earlier conclusion was premature, and it troubled me that rail bouncing alone could have killed the TV. The real cuplrit turns out to be something far deeper than the simple design issue I initially uncovered. If I'm right, this sheds some light on the terrible reliability this TV model and its variants reportedly suffer. Most of the threads posted about this TV in the Dell community forum are written in far less charitable terms than mine.
During bench testing the PSU, I encountered the tricky issue of voltage tracking between multiple output windings of a flyback transformer. This PSU has two main secondary windings, one for 24V and the other for 12V. The main regulation loop watches the 24V output as it has to deliver most of the power(backlight). There is a minor feedback branch from the 12V, but just enough to keep it under the 17V overvoltage trip threshold. Perhaps due to poorly coupled windings, when the 24V is under heavy load with backlight ON while the 12V is at "sleep-mode" load, the 12V rail rises to just below 17V. At 100mA load and up, this rail settles nicely to around 11.8V. The 25V rated electrolytics on the 12V rail of the PSU board seems to anticipate regulation mis-tracking under asymmetrical loading.
Unfortunately, looks like the motherboard designer didn't talk to the PSU designer. The logic power converters fed from 12V are based on the ON-semi 2-channel NCP5422 controller, whose "Cry uncle!" voltage, along with all the input caps around it, is only 16V. The overvoltage I measured is not at a level that would immediately destroy the converter, however, expose it to this condition over a few years of use inside a hot TV chassis, and Poof! the smoke escapes. There are several ways this situation could have been avoided without undue expense.
I may have uncovered the problem. Initially misled into thinking it was a light-load issue, I pulled the PSU out and powered it up on the bench; all rails were steady at nominal levels with NO load. Any light loading on any rail, the supply went into hiccuping, a complete reversal of its behaviour in the TV. According to the NCP1377 datasheet, the chip executes a shutdown and restart cycle with timing based on its Vcc decoupling cap. The hiccup interval was in the right ballpark, so with nothing to lose, I disabled the trigger of the main OV/OC circuit. The supply continued to hiccup under any load, becoming stable as soon as the load was removed.
My suspicion shifted to the NCP1377 Vcc undervoltage shutdown. The Vcc is fed 15VDC from the line side of a separate off-line standby converter. The OV/OC circuit on the LV side disconnects the Vcc with an optocoupler controlled high-side PNP transistor. A 15V zener on the base appears to try to keep it from enabling Vcc until the 15V is up, but with the zener voltage so close to the rail level, the transistor won't saturate under all conditions. The collector voltage measured under 10V, perilously close to the NCP1377's undervoltage threshold. Playing a hunch, I replaced the 15V zener with a 10V to ensure the PNP saturated. The PSU was now steady with loads, so I rigged it back into the TV with a dummy load on the 12V and 24V to the 75W backlight. The backlight lit up steady with no noise from the PSU, the 12V rail steady at 11.9V.
Regrettably, the new motherboard was shot before all this, punting the set well past "worthwhile" recovery. Clearly, the zener voltage error conspired with seriously inadequate input decoupling on the motherboard's DC converters to doom the big LSI chips getting 1.2V core power when the converter MOSFET failed short.
Bouyed by success in reviving an LCD monitor last year, I now find myself having spent $80 on an LCD TV with little hope of recovery. I'd like to learn a bit about a subject I believe is at the heart of the problem; off-line flyback converters. I would be very happy if any EETimes reader with flyback converter design expertise could offer some hints on what may be happening here.
The set, a 5 year old Dell w2607C LCD that I received for free, exhibited the amber flashing LED symptom commonly complained about on various websites. After finding the full service manual with schematics on the web along with availability of third-party capacitor replacment kits for the PSU board, I figured the set could be restored with little more than $10 and a couple hours work. I did find an open fuse on the motherboard, caused by a shorted upper MOSFET in a local 1.2V DC converter. Although this hinted at potentially serious damage, the 1.2V rail itself did not measure short, so I took the gamble since the PSU caps, blown fuse and MOSFET replacement amounted to under $20.
After repairs, the rails of the PSU came up steady, all logic power on the motherboard was stable, backlight was bright, no smoke or smell but nothing on screen. Motherboard obviously didn't survive the MOSFET failure. I found and ordered a replacement motherboard on the web for $60, since the PSU was now apparently working with the new caps. Weeks later with the new motherboard in, I was please to see a steady blue power LED and the Dell logo up on screen. However, after 5 seconds, the set blanked the backlight and became unresponsive, making an audible "...ZZT ZZT ZZT..." noise. Power cycling the set several times, it powered up exactly like this each time. After about the 10th power-up, the noise ceased and the power LED started flashing amber again. Rats!! The same fuse on the new motherboard had blown and the same MOSFET was damage, measuring about 8-ohms D-S.
At this point, it's a lost cause unless the new motherboard somehow survived major damage. I'm pretty sure that the main flyback converter has an aging issue where it eventually loses stability under light load. During the brief time when the set powered up and displayed the Logo, all the main rails measured steady at nominal values (24V and 12V from the flyback secondary, plus the 16V rail generated from the 24V rail). When the backlight blanked, removing about 75Watts of load from the 24V rail, the supply went into rapid hiccupping where I could measure the rails bouncing all over the place. The converter uses the ON semi NCP1377 current feedback critical conduction mode controller. This stage, runs from around 350-400VDC, fed from a PFC circuit based on the Fuji FA5500. From the ON datasheet, the converter should be stable from 0 to full load. The schematic revealed reasonable conformance to the manufacturers' suggested designs, except for the rather elaborate SCR based OC/OV protection latch circuit. It's a different story on the motherboard, where I'm quite sure inadequate input decoupling to the local converters largely contributed to its destruction by the bouncing main rail.
Blog Doing Math in FPGAs Tom Burke 23 comments For a recent project, I explored doing "real" (that is, non-integer) math on a Spartan 3 FPGA. FPGAs, by their nature, do integer math. That is, there's no floating-point ...