Bad capacitors and ESR testing

I have an old Soltek SL-65KVB motherboard. It was taken out of service due to AGP graphics instability which was probably due to bad capacitors. This diagnosis seemed pretty obvious because capacitors right by the AGP slot were bulging, but I didn't bother fixing the motherboard because it was a good time for an upgrade.

Now I would like to repair the motherboard, mainly because the combination of a Pentium 3, 640MB of RAM and an ISA slot could provide a nice way to use old hardware. By now, even more capacitors are obviously bad. However, only the GSC 1000µF and 1500µF 6.3V capacitors with gold/brown lettering have obvious problems and more numerous smaller GSC capacitors with silver/white lettering seem fine.

I didn't feel like unnecessarily replacing the smaller capacitors, so I quickly built a very simple capacitor ESR tester. The basic idea is the same as various other ESR measuring devices documented online: a stepdown transformer outputs low voltage and low impedance pulses which are used to measure capacitor ESR. I built the stepdown transformer from an inductor with a short secondary wrapped around it, and I used a 555 chip to supply low duty cycle pulses at high frequency. The 555 can supply enough current that it's possible to directly drive the transformer with a resistor in series with the primary.

My first attempt with a secondary of just a few turns worked pretty well when capacitors were plugged into the breadboard. However, test leads had enough impedance to make the circuit useless. Reducing the oscillation frequency to around 100 kHz and adding more turns to the secondary improved performance, making the bad capacitors very obvious. Test leads were still a problem however. Adding a 1Ω resistor in series with the secondary improved the situation significantly, so I proceeded to test the small capacitors on the motherboard via test leads.

It seems the small capacitors are all ok. However, among the large capacitors, even most that weren't bulging are bad. Only two of the ten 1000µF capacitors have a low ESR. Of course, considering the other failures, these shouldn't be used for anything either.

g++ dyamic linking fail

I have a DLL which works when built, but stops working later. Simply rebuilding it creates another copy which again works and stops working later. LoadLibrary returns error 998, which mean "invalid access to memory location". In other words, a crash occurs in the DLL being loaded. The crash occurs when calling _initterm from code at the DLL entry point. At __imp__initterm there should be a pointer to _initterm in msvcrt.dll, but the location instead still contains the value that's in the file on disk. As a result, if msvcrt.dll is located at a different location, the program jumps to the wrong location. I guess this happens because msvcrt.dll is imported two times. The first import just uses _write, which is properly dynamically linked. The second import lists all the other functions that are used, and dynamic linking wasn't done for any of those. The _write from the first import is just used to print "pure virtual method called\n".http://www2.blogger.com/img/blank.gif

I suspect that g++ is to blame, but I'm still not sure. The problem is now happening with g++ 4.5.3 from the 32-bit MinGW-w64 Cygwin package, but the same symptoms occurred when using the old Cygwin compiler that is based on GCC 3.

Update: The problem seems to be related to statically linking libstdc++. The duplicate msvcrt.dll exists when using -static or -static-libstdc++ (new in GCC 4.5).

Update 2: Packing the DLL with UPX 3.07 seems to fix the problem. When a packer compresses the IAT, it needs to handle dynamic linking. Apparently UPX is able to properly handle the defective IAT.

No, I can't trust Windows with very rare operations.

While my computer was writing to a 3½" floppy disk via the floppy controller on my motherboard, I pushed the sleep key, requesting S3 sleep. Right after that, I remembered how Windows cannot really be trusted when doing unusual things. I started to wonder if I'll see a bluescreen, but all I saw was sleep being delayed by lengthy floppy activity. When I came back, I was not too surprised to see a bluescreen. The source of the crash was a bit surprising however: usbser.sys had submitted an IRP that was already pending in the USB bus driver. I guess delays from the floppy driver triggered a bug in usbser.sys. This was failure bucket 0xFE_usbser!RestartNotifyRead+73. It was usbser.sys 6.1.7601.17514 (win7sp1_rtm.101119-1850), so this really is a component of Windows, and not a 3rd party driver.

Review of battery and AC adapter from LaptopCharge.com

About a year ago, I got a new LDE203X battery and AC19V90K1 AC adapter for my Inspiron 6400. I ordered from LaptopCharge.com, and I'm satisfied with that choice, the site and the items.

Basically, there were three choices for getting a battery and AC adapter: Dell, eBay, and other stores like LaptopCharge.com. Dell ridiculously overprices these things, so I didn't want to buy from them. However, I noticed that some people didn't trust third party batteries, and many people said third party batteries wear out more quickly. I also noticed that most eBay sellers didn't list a brand or part number for their batteries, which seems shady. I chose LaptopCharge.com because is a store that has been around of some time, and they sell Dr. Battery brand products. The price wasn't much higher than the best prices on eBay.

After placing my order, it arrived promptly and in good condition. Everything was packaged well inside, and the battery and AC adapter were in their own boxes. I was however unsure about whether the Dr. Battery brand meant anything. The logo only appeared on hologram stickers which were haphazardly stuck onto the battery and adapter.

The battery is a good, though not perfect fit. It takes slightly more force to engage the latches, and the thicker side sticks out a fraction of millimetre. This is totally inconsequential.

The battery charges properly and only gets very slightly warm. When it's done charging, the battery light keeps flashing occasionally, like during the topping up part of a charge. Also, if the battery is discharged to 98% or 99% and power is plugged in, Windows reports that the battery is charging but the level doesn't increase. In both of these situations, BattStat shows about 11 mW of power input, and a voltage which is well below 4.2V per cell. This seems like a very slight miscalibration of the current gauge. None of these things are a problem. (It is normal for lithium-ion batteries to require more than a few percent discharge to trigger charging.)

Just like the original battery, the replacement battery has a LED bar graph for checking battery level. It works, although the button that activates it requires more pressure and doesn't have a nice clicky feel. This is a bit of a disappointment, but certainly not a big problem.

Low battery shutdown works perfectly. The capacity decreases smoothly, and hibernation is triggered appropriately. I did not test discharge to the point of power cutoff.

During the last year, I was careful with the battery. I took it out when using my laptop on AC power for extended periods, and whenever I stored the battery, I kept it at around 40%. I still don't see any capacity degradation.

The charger looks very similar to the Dell charger, but it is bigger. This may be because it is 90W, while my Dell charger is 65W. It has a longer AC power cord, but a shorter DC cord. This is less convenient than the Dell charger. The AC cord doesn't bend where it exits the charger, which is nice, considering that I don't want to wrap the cords on the charger because of the stress that it causes.

I don't like the original Dell charger because it is noisy. It makes chaotic buzzing and beeping noises when the laptop is running and especially while the battery is charging. When in sleep mode, it produces a chirping sound as the power LED pulses. When I'm going to sleep in a quiet place, this sounds kind of like night crickets, except it's kind of annoying. The Dr. Battery charger is much quieter. I need to be closer to hear the sounds it produces, and there are no bothersome sounds in sleep mode.

Even though the Inspiron 6400 shipped with a 65W charger, it properly recognizes the new 90W charger and makes use of the additional power. With the original charger, charging slows down when the laptop is on and doing demanding tasks, and with 90W available, charging does not slow down. (BattStat can show these things.) However when charging and doing ordinary non-demanding things, the charger gets so hot that it is on the verge of causing 1st degree burns. Because of this, I wouldn't like to do constantly demanding things while charging or use the charger with a laptop which is designed to require 90W.

When I was wondering about the bar graph on the battery, I contacted Dr. Battery and LaptopCharge.com and got prompt replies. Based on this, it seems that the technical support and warranty can be trusted.

A quick OS comparison

Windows is the de-facto standard OS. Over time, it has been enhanced to the point where it's stable and it contains practically all the features one might want. Its main advantages and disadvantages relate to its popularity. It has the greatest selection of software and support for a very wide variety of hardware, but it also has the greatest variety of malicious and deceptive software that users have to watch out for.

Mac OS X is pretty and it provides a pleasant user experience. However, it has various limitations, some of which can force one to use Windows for some tasks. It's also tied to expensive Apple computers, and it has worse hardware support. It's a good choice for those who don't do stuff that runs into the limitations and don't mind paying extra for computers.

Linux is free and there is a large selection of free software that can run on it. Some of that software is incomplete, buggy and/or ugly, but there is high quality free software. Linux has some limitations due to not being the de-facto standard, but the situation is better than with Mac OS. The main disadvantage is that a lot of GUI software is kind of awkward and not pretty, as if it was designed by programmers rather than skilled user interface designers and graphic designers.

Getting a TLC5940 to retrigger itself

At first glance, the TLC5940 seems quite nice. It offers 16 output channels, each with 12 bit PWM and a 6 bit current limit. Unfortunately, the chip doesn't have an oscillator and when one PWM cycle ends, it needs to be retriggered. This is kind of annoying and it partly defeats the purpose of using an extra chip for PWM. It means that you have to supply a jitter-free clock for PWM and you need to count cycles and retrigger the chip via BLANK when necessary.

I wanted to get it working quickly, so I devised a hack. By capacitive coupling OUT15 to BLANK, the rising edge of OUT15 at the end of the PWM cycle became a positive BLANK pulse which started the next cycle. I used a 4.7 kohm pullup at OUT15 to create a signal there, a 22 nF capacitor between the pins, and a 100 kohm pulldown at BLANK. At BLANK, I also added diodes to the power supply rails, to clip the signal. I'm not sure if those were needed.

I never checked to see if the signal was within or close to specs, but it was perfectly reliable once started. To start it, OUT15 had to be set for the desired length of the PWM cycle, and BLANK had to be pulsed high. Sometimes, it started by itself, but that was unreliable, especially because the initial contents of TLC5940 registers are undefined.

In up mode, all output modes are useful for TACCR0

The MSP430x2xx Family User's Guide, the section on Timer_A output modes claims that "Output modes 2, 3, 6, and 7 are not useful for output unit 0, because EQUx = EQU0". However, the output example for up mode states "The OUTx signal is changed when the timer counts up to the TACCRx value, and rolls from TACCR0 to zero, depending on the output mode." Based on this, it seems those output modes are useful: they could create a one cycle pulse. This does actually work; I used it to drive the BLANK input of a TLC5940.

Video capture

I recently used VirtualDub 1.9.11 to capture video with audio.

I captured video via an ATI TV-Wonder VE card, which is based on the BrookTree/Conexant Bt878 chip. Windows 7 drivers are not available from Microsoft or the Manufacturer, but the version 5.3.8 btwincap open source driver works pretty well. In VirtualDub capture mode, overlay never works and resolutions can't be set via the capture pin, but preview works, and resolutions can be set via "Set custom format". Spending many minutes in (nonfunctional) overlay mode can cause a bluescreen or crash, but that's easy to avoid by switching to preview or "no display" mode. When previewing or capturing, the card is perfectly stable. Video quality is great.

The TV-Wonder VE doesn't capture audio, so I recorded audio via Realtek ALC889a line in with driver version 6.0.1.6235. The audio quality was good, but since audio and video were recorded via separate devices, they weren't in sync. My first capture was a major disappointment, perhaps due to Windows enhancements for line in. After I disabled those, things got better. I discovered that VirtualDub could perfectly sync if "Correct video timing for fewer frame drops/inserts" was not checked in "Capture timing options". If the option was checked, no frames were dropped and fewer frames were inserted, but VirtualDub did not synchronize the audio very well. There was both an offset and a drift. Fortunately, in most cases the drift was insignificant, and so I could simply correct for the offset. I captured most video this way to minimize frame drops and inserts.

I spent some time wondering whether to extend the luma black or white points. It seemed like there was information beyond the luma white point, but extending it didn't help, perhaps because that information was distorted. There was also a bit of information beyond the black point, but extending it increases noise. Extending either made properly exposed scenes seem washed out. I decided to never extend the white point and only extend the black point for a few scenes which would otherwise be excessively dark.

All the frame inserts I got happened before scene changes or severe noise. This makes me think that the card simply didn't record frames where a usable signal wasn't available. When an insert happened before a scene change, what followed was either one frame of the old scene followed by the first frame of the new scene, or one frame of the old scene and one frame of the old scene interlaced with the new scene. In such cases, I removed those frames.

I gave up on deinterlacing to 29.97fps because all algorithms are a compromise between blur and artifacts, and I didn't want to encode that permanently in the video. Deinterlacing to 59.94fps produced good results, but it also increased compressed video size substantially. Because of that, I decided to encode interlaced MBAFF H.264 video with x264. It plays acceptably in Windows Media Player 12 and excellently in MPC-HC with ffdshow Yadif deinterlacing.

Before encoding I considered various forms of denoising, but I never found one that really improves the end result. Denoising could decrease the slight noise, but it would also blur some subtle patterns like distant grass, asphalt, and slightly dirty walls. Also, the file size decrease from denoising is offset by the greater visibility of artifacts in smoothed areas. The most bothersome effect was that areas which show motion due to subtle patterns could stop showing motion. Finally, I noticed that x264 seems to perform some denoising itself, so denoising isn't needed after all.