Frankenstein's Fix: Dirty Signals

When a clock counts too fast, a dirty signal is to blame. How did Will Sweatman solve it?

The idea of time is simple yet complex. In its simplest form, it's the counting of a regular, repeating pattern. On the opposite end, we would have to turn to Einstein. Thankfully, this story resides on the simple side.

You see, before the advent of the real-time clock, electrical engineers scurried hither and yon in search of ways to calculate time accurately in their circuits. One very convenient source of a regular, repeating pattern was the 60Hz line frequency coming from the wall outlet. It was a very stable source in the US, and so long as it was stable, your machine would work fine. But if ever a crack appeared in the stability of the 60Hz source, the entire machine could be compromised.

This was the case on the idle Tuesday morning our story begins. Giant pillars of white smoke soared high in the air from the large, concrete stacks that reached up into the clear blue sky. It was easy to find parking in the large lot when I arrived at the paper-making plant nestled on the outskirts of Richmond, Va. The smell of sulfur was thick, and the rumble of the large trucks carrying trees filled the air as they entered the plant. It was a short walk to the visitor's desk, where I was met by the man who had called me a few days earlier.

"Damn thing doesn't work," he had said. I get that a lot. He led me to the not-working microwave solids analyzer. This simple machine consists of a microwave, a balance, and an embedded computer. It heats a sample to remove all the moisture, and the computer uses the difference in weight to calculate the percent moisture in the sample.

I placed a test sample in the machine and pressed the start button. Immediately, problems were apparent. On the grey scale display, the system clock was counting down the time. The problem was it was counting way too fast. It had counted down more than two minutes, but my gut, verified by a clock on the cinderblock wall, told me less than a minute had gone by. I pressed the stop button, and another problem revealed itself. Instead of the usual single beep, I got three. It acted as if I had pressed the button a couple of times. It appeared I had debouncing as well as timing issues. It was then that I clued in on the A/C line and took a closer look. I was in for a shock.

The above video and scope screen captures were taken directly from the 120V wall socket via a 10-to-1 stepdown wall-wart transformer using a 10x probe. As you can see, the signal is very dirty. I concluded the source of the noise was probably from one of the large paper rolling machines running elsewhere in the plant.

I had identified the problem. But I still did not know how the dirty signal was causing the timing and debouncing issues and how to fix them.

I had to solve a before I could even begin to approach how to fix the issues. Like any good technician, I dug into the schematic. It wasn't long until I discovered a small circuit that appeared to be converting the A/C line frequency into a 5V clock signal. The output was routed to one of the pins of the 80188 Intel processor.

I knew I had to get a scope on pin 6 of the opto-coupler (U7) to see if the noise on the A/C line was getting through.

So the noise from the A/C line was getting through the opto-coupler in the form of problematic leading and trailing edges. It was so bad that the scope had a hard time locking on to the frequency, as seen above.

I did not have access to firmware, but my theory was sound. I believed that the 80188 computer was using this very signal to generate its definition of time -- every 120 leading-edge counts was equal to one second in the firmware. And in this case, all the spikes on the leading edges were being counted, as well. This would cause the system's internal clock to run too fast. Also, I knew the switch debouncing was done in firmware. This code is dependent on accurate delay times. If the system clock were running too fast, that would mean the delay times would be too short, and the debouncing code would not work properly.

Yessss! I had found the source of the problem, theoretically at least. Now, how to fix it. Long story short, I concluded that it would be easiest to simply replace the signal. I would remove the opto-coupler IC and use a microcontroller to generate a clean signal and route it to the processor.

Above is the schematic. (I realized I had taken the scope readings in the previous images off U6 instead of U7. U7 produces a 10 percent duty cycle 120Hz signal, as opposed to 50 percent.) Below is the code to generate the 10 percent duty cycle 120Hz signal.

I made a board using toner transfer. I removed the opto-coupler, and used the empty socket to supply power to my board and route the clean signal to the processor.

I installed it in the instrument the next day, and everything worked perfectly. The timing was accurate, and no more debouncing issues. I had the board done from a board house and installed it a few weeks later. The instrument has been working well ever since.

Submit your product repair or redesign story as part of our Frankenstein's Fix competition on EE Life, and you could win a Tektronix MSO2024B digital oscilloscope. The deadline is Oct. 26, 2013. Submission details and full contest rules here.

@gigavolt (and Andy) - point taken, and very valid. But a more polite request direct to Caleb would probably have got a better result - space in the columns is limited, but they can put click links to bigger versions of images.....

THe machine;s been running for over a year now, WKetel. And no failures yet. I would think it's pretty reliable. I agree a filter would be best, but I could find none that would work. And when you're faced with "make it work or I want my money back", you do what you got to do to make the customer happy.

These comments were the first thing I thought of as well. There was a lot of stuff I couldn't get into because of the word limit. But long story short, I tried various filtering techniques, but none would work. The schematic here is really unreadable, but I posted a link to the original article in a comment above. There, you can see the schematic and other images with better resolution. You will see that there are two opto-couplers converting the line frequency to a digital signal. One is the "phase", which outputs a 60 Hz 50% duty signal. The other is "ISR" which outputs a 120Hz 10% duty. I was able to clean the 50% with a .01 to ground. But when I tried that on the 10%, the computer wouldn't start. Everything I did to the ISR signal caused a boot failure. I'm not really sure why. Replacing the signal was the only alternative left.

I think Andy might be talking about the formatting of the article done by EEtimes, and not the author, which is me. The text has clearly been revised, and very well I think. The problem lies in the resolution of the images. You can not make out the text in the scope images at all, and the schematic is unreadable as well. It's also difficult to take in how bad the signals really were with these low resolution images. They really make the article somewhat nonsensical due to lack of information.

The URL below is the article as I originally wrote it, and much more readable.