Repairing A Lamp – The Reverse Engineering Way


This article is about one occasion where I had to use the concept of reverse engineering which is the method of breaking things down to understanding its design and working. Although reverse engineering is a skill that an engineer should posses, I was always so focused on my own designs that reverse engineering never crossed my mind. That was until one day when my LED lamp suddenly blew. Naturally, I was curious to know why. So I removed the mounting screws and dismantled it to pieces. The main  circuit board actually had all the LEDs and the side on which the wires come from the power supply was intensely charred.

20151208_211424 20151208_202003

Most of the board except this was almost untouched. So, I wiped out the soot and examined the board’s PCB traces to understand how the LED’s and other components were connected.


In the first glance I saw that the LEDs were in series. So, I knew that it had to be a constant current circuit. A quick search using the IC (on the left) number – CYT1000A which is a Linear Current Driver showed me that I was right. So the circuit was very simple – an array of LEDs connected in series to a constant current driver and then all that would be required is a DC supply. It is only logical that the charred IC on the right had to be a rectifier of sorts so as to convert the AC supply into the DC version required by the circuitry. When I desoldered and cleaned the IC to took a very close look at it, there was the number MB6S etched on it. MB6S is a 600V Reverse voltage tolerant bridge rectifier from Fairchild semiconductors. Thus, I had reverse engineered the circuit. It turned out that it was a circuit given as a typical application in the current driver IC’s datasheet.


But I still didn’t have the answer to what I was actually curious about – what went wrong? I used my multimeter in continuity mode to check the connections between the wires and the components. The AC (input) terminals of the MB6S were short-circuited. However, there was no electrical connection between the wires attached to the board and the MB6S input terminals. If the lamp was to work, there had to be a connection so that the power can be supplied. So patiently from the input terminals I kept check continuity to see where the break in connection was. And not surprisingly the break in connection was exactly above and below the circular hole (the hole is there to provide space for the mounting screws). Like a detective, I had enough evidence now to judge what went wrong. This is what I think happened – An abnormal transient in the AC supply made the voltage higher than what the diode is capable of blocking. Therefore the diode breaks down creating a short-circuit between the supply lines. This draws a lot of current through the wires to the IC input terminals through the PCB trace around the circular hole. The huge current produces most heat where the PCB trace is narrow (above and below the circular hole) since the resistivity is comparatively higher there.  The huge current burns the plastic solder mask resulting in the charring and the narrow metal film ‘melts or vaporizes out of contact’.

If my deduction was right, simply replacing the bridge rectifier would make the lamp work again. So, I used the commonly available W10 bridge rectifier which is more bulky but has far greater tolerance (1000V) than the MB6S (600V).

20151216_194513   20151216_200604

I soldered the supply wires to AC terminals of the W10 and then soldered the DC terminals of the W10 to the correct DC terminals on the lamp. After all the soldering, came the moment of truth. I connected the AC supply to the mains and switched it on.


It worked and I was right! Then it was a matter of finishing things up with some hot melt glue to insulate all the metal terminals and prevent the wires from excessive movement (which will eventually cause any soldering to wear away and break contact). Then I tucked the wires and neatly assembled it back into the recognizable lamp.

20151216_202540   20151216_203048

Finally, the mounting screws went in place and the lamp was as functional as it used to be. As simple as the lamp might be, it was still interesting to reverse engineer it. Only when I understood the circuit, did I find what could have gone wrong and only when I understood what went wrong, did I find a way to undo it. The end result is that, I basically salvaged a lamp but this is one of those cases where the process is much more rewarding that the result itself.



Working with the 16-bit PIC24F


I started my microcontroller (uC) journey with the ‘AVR’ and then made it a point to diversify into other awesome uCs. Naturally, the next stop is the famed Microchip’s PIC – Peripheral Interface Controller. Now, when I say PIC it is almost always assumed (in India especially) to be the PIC18F series mostly the PIC18F4570 etc. It so happens that these chips are 8-bit architectures like the AVR (they are classic competitors).

A lot and I mean a lot has been done with this PIC series (18F) to the point that virtually any circuit that can be done has been done and posted on the internet. So, to spice things up a bit I chose to work with the relatively unknown PIC24F series. This series features a 16-bit architecture with superior features (PPS – Peripheral Pin Select is the most remarkable in my opinion) and performance than the 18F. Specifically, I chose the PIC24FJ64GA002 and the best thing for me was, there is not much ready reference circuits or programs available for this microcontroller.

What have I done? I repeated the exact same experiments that I did with AVR. The output is the same but to achieve it was a task, my word, far more difficult to accomplish. And since the output is the same it might be a little boring to see the videos of the hardware implementation, so instead I have posted screen recordings of the simulations (using Proteus).

Since descriptions of the experiments were already written in my AVR article, I would not like to repeat them here. So onto the experiments then.

Simple I/O:

The simulation shows an LED blinking (output) and when the switch is pressed (input) the LED is held on which is truly a simple case of input and output.


As a part of only output programming, here is an LED matrix display that is programmed to display ‘hp07’. The hardware part for this is too straight forward that I stopped with the simulation. 


Curiously, Proteus is capable of simulating LCD displays too. As the potentiometer is moved from the minimum to maximum resistance position, the voltage varies from 0-5V and that is read by the microcontroller using the ADC and it is displayed.

DSC03992   DSC03991


Proteus can also simulate oscilloscopes that show waveforms. Therefore instead of showing a variation in LED brightness and motor speed (that can barely be seen), the simulation shows it better. You can notice how when ON time (in the waveform) is longer, the motor rotates faster and slow during shorter ON times.


I recently got an instrument called logic analyser that can be used to practically visualize the waveform too. I have a computer interface based one and therefore the screenshot of the waveform:



Ofcourse, I have to end with the same button presses counting game. When the count button is pressed, a counting interrupt routine is executed with the red LED glowing that counts the number of times the button has been pressed.

And when the transmit button is pressed the data is transmitted through the Universal Asynchronous Receiver Transmitter (the green led glows during this routine). The other microcontroller receives the data and displays it with the help of IC 7447 and a common anode 7 segment display.


The count is re-initialized to zero after every transmission.

And therefore I finished my experiments with PIC. Yea, I did the same experiments as with the AVR microcontrollers. It is easy for me to use a thermistor instead of a potentiometer and post it as a digital thermometer in the ADC experiment. But all that is technically trivial manifestations of the base which is the ADC module. What matters is the program and the base circuit to get it to work and I have done that – therefore mission accomplished!

The videos of the hardware implementation using PIC is on my youtube channel:

The AVR Microcontroller Journey


I love circuitry and programming. Therefore, microcontrollers are literally heavenly to me. Though, the long time industry standard of microcontrollers has been the 8051, I really took to Atmel’s AVR microcontrollers. Especially, the combination of Proteus (for simulation), WinAVR(for programming)   and most definitely the microcontroller itself – ATmega16 was sublime to work with. I worked out almost all of its major features from simple I/O to UART communication. In this article I will post the photos of simulation while the videos will be of the actual hardware implementation.

Simple I/O: 

This is as simple as a microcontroller circuit can get. For output, all it does is make an LED blink. To add a little input to the circuit, I added the push button switch. So the LED blinks normally but when the button is pressed (input) the LED is held ON.



The LED matrix display actually contains 7×5 LED’s. Each of these 35 LED’s can be individually switched on or off. This circuit is also all about outputs but here I selected particular LED’s to be switched on in every column. Then, it is programming the microcontroller to display all columns but one column at a time rapidly creating the letters.



DSC03772 DSC03771

One of the best features of the AVR is its in-built analog to digital converter. This circuit converts the anolog value of voltage applied through the variable resistor (10k pot) and displays it using a 16×2 Character LCD Display. The video shows the entire range of values from 0 to 5V as the pot is turned from one end to the other.



DSC03952 DSC03955

AVR has some pretty neat internal counters and timers. Using them, Pulse Width Modulation of almost any duty cycle can be obtained. I used the PWM to reduce the brightness of an LED and also to control the speed of a DC motor. The motor was a 150 rpm motor and I even removed the motor shaft to see if the internal gears should appreciable change in speed. For the eyes they did, for the camera I am not sure. So the difference in speed isn’t obvious but careful observation will clearly show a change in speed if the LED’s brightness is used as a reference. When the LED is dim, the speed of the motor should be low and the opposite (bright and fast) is also true.




It is a protocol by which a microcontroller can communicate or transfer data to another device. In this case, the microcontroller transmits data to another microcontroller which displays it. This is what happens, everytime the lower button is pressed an interrupt is raised and a count value is incremented. This count value stores how many times the lower button is pressed. Each time the red light arises, a count has been registered. When the upper button is pressed, the green light is seen and the data is transmitted to the other microcontroller.

If you look closely, the only link between the two microcontrollers is the one single yellow wire. The data is received by other microcontroller and displayed. Everytime the data is sent, the count is made zero again and if the transmit button is pressed again the zero is transmitted and displayed.


Ofcourse, I haven’t explored everything there is especially I wanted to use the I2C protocol to show a small animation movie on an OLED display. Sadly Proteus doesn’t have a simulation model for the OLED display and the display is just too costly to blindly experiment with. But other than that, working (playing) with this microcontroller is one of the best things I have done in my life.