1994 LA4440

LA4440 is a medium power audio amplifier IC. It supports stereo operations upto 12 watts. But it can also be configured in mono mode and it will give, up to 19 watts output on this mode. It had a decent audio quality. This was the time I was experimenting with various audio amplifier circuits. For example: bass & treble filters, equalisers, woofer and tweeter networks, etc... The LA4440 amplifier was fit enough to be used with most of these circuit combinations.

Back in the time we had a audio cassette deck SG-3800 from National Panasonic and it was quite powerful with big speakers. Along with it there were 2 microphones for karoke. I wanted to build a PA amplifier system with these microphones.

The LA4440 had a simple configuration and it needed minimal components for its operation.

LA4440 Internal Blocks

Stereo mode

Amplifier Channels in Stereo Mode

In this mode the 2 channels are used for stereo operation.

Mono bridge mode 1 (w/ feedback loop)

Amplifier Channels in Bridge Mode 1

Mono bridge mode 2

Amplifier Channels in Bridge Mode 2

Example stereo configuration

LA4440 in stereo mode

1993 NE555

On the year 1993, most of the time was spent going through different transistor circuits diagrams, inspecting broken electronic equipments etc ... This was a hobby. Had a vague idea on how transistor was biased. But didn't knew the exact reason for using various component values (like resistors and capacitors) on the circuits. The exact theory behind designing the component values got to me only much later. Also didn't know the relevance of different models of transistors were used. Didn't even knew there existed something like datasheets for these transistors.

I had couple of ITI text books on radios and amplifier circuits with me. Also, there was one book on old valve radio designs. Had a handbook of various types of transistor radio circuit schematics. A lot of time was spent on these books understanding audio amplifier circuits. It was a little bit confusing that most these books had circuits with PNP transistors, but most of circuit boards I had was of NPN transistors.

Lot of circuits were assembled and experimented. Design, assemble, experiment and dismantle, this was a constantly repeating sequence at that time. The LED dancing lights circuit with BC547 was an example. Important thing about circuit design is that, you should know deep enough of about the schematic that, you should be able to predict how your design will function even before it is powered on. Without this visualization it will be difficult to make successful designs. The same visualization is required is required to fix a broken equipment as well. You should be able to envision how the circuit will work on real world. This will also help you to locate the parts of the circuit which are not functioning as expected.

2 LED Dancing Lights

3 LED Dancing Lights

5 LED Dancing Lights

Also built few transistor audio amplifier circuits and tried tweaking them. The only tools that was available was soldering iron, screw driver and an earphone. For most of the basic things these were enough. Most of the tools were not that expensive compared to today. For example, the soldering iron costed me 25 rupees and resistors used to cost 20 paise per piece.

Most of the circuits were assembled on common PCB boards. Great deal of efforts were spent on manually routing the circuit on these boards. Many years later this helped when designing actual PCBs on CAD software.

Sometime this year, my friend Edwin shared with me some teaching notes on NE555. His mother was a teacher and at her school during the summer vacation there were some classes organized on electronics. The teaching notes also contained a huge cache of circuit schematics of NE555 on various operating modes. It even explained details on relevance of different IC pins and how they need to be biased for putting the IC in to different configurations. This was the first time something more in line like a datasheet was available to me and NE555 configurations were relatively simple compared to the transistors. More over this IC was quite cheaper to procure. The IC packaging was compact and simple enough to be used on small circuits.

The NE555 can be used in different operating modes. Functionally, few popular ones were as an oscillator and as a timer. We used this IC on LED flasher circuits and sound tone generator circuits.

2 LED NE555 Astable Multivibrator

NE555 Tone Generator / Piano

Later this year, again started focusing on radio and amplifier designs. Lot of time was spent on actual design concepts from valve vacuum tube circuits. This later helped on understanding how the upgraded transistor designs work for the similar functionality. Considering the books I was referring were quite old, it gave an insight of why exactly they chose particular design patterns on different sections of the circuit.

My Projects

These are few of the interesting past projects, their experiences and learnings.

1993 NE555

1994 LA4440

1995 L-Board Radio

1996 VSB Blocker

2003 PCI Controller

2006 H264

2008 Switch 2008

2009 Switch 2009

2012 Switch 2012

2020 Switch 2020

My Battles

I believe, life is a war and everyday is a battle. So, I just lived through the battles. The idea is to go forward through these battles. There is no point in stopping at any point, because then that means you are not going ahead anymore. All you can do is to just pause for a while and breath some fresh air and go ahead. For everything else you want to do along this journey to relax, you need resources, which I never had.

Is there anything pleasurable about this ? There may not be anything pleasent about this at all, it is just hard life. We cannot expect every part of your life will be pleasent. Let's don't be a snowflake about this. You will have more scars from these battles than happy memories. But if you want to go ahead try to take these scars as the battle trophies.

You cannot win every battle. You cannot win on every battle ground. I believe you don't have it as long as you don't have it. There is no point in speculations, you can only truly know whether you won the battle after the battle is over.

As an engineer I handle different kinds of problems. We as engineers, it is our duty and our job to solve problems. There are different types of problems. Some of them are stationary and you can revisit them anytime you want. But some of them are not like that and you may have to keep a note of them to be handled later for various reasons. I usually keep a bucket list of them. Let's handle these unfinished businesses later. Probably at some point you have to hunt them down for good.

There are smart people who like to avoid scenarios where you encounter problems. I also prefer to do the same if it was ever an option. Unfortunately, I never had the resources nor the the convenience for this. But you have to understand that this is not a permanent solution and you cannot evade the problems forever. At some point in time you will be forced to handle them, to make it worse let's say at an unexpected situation. As an old-school engineer I mostly handle the problems and not evade them. Because there is no point in leaving them in open and expecting surprises. For your own good you should be able to handle them with bare hands. You may not have all the possible gimmicks in the world to handle them.

When there are problems you have to solve them. There are some people who runs away from problems. This is never a long time solution for any thing and it never gets you anywhere. Then there are those who switch lanes when they encounter problems. This is not a good idea either. There is a famous quote: I had problems and thought "I will use Java!". Now I have problem factory. I was personally a guy who solved loads and loads of problems. When I left Gurgaon in 2012, my L2 manager (who later went on to become the CTO of the company) complemented: "Nells was a mass murderer of bugs". He was one of the very few good people who really supported that project. I was personally responsible for fixing more than 190 bugs on that project in a mere 9 month window.

I believe in finding the root-cause of problems. On control plane (datcom) the root cause can be very deep and hard to locate. I was that guy who hunted down the hard to locate problems and closed them down for once and for all. There were lot of people who were not happy about the root causes of many these problems. Usually you have to incorporate the solutions for problems back in to the system design at some point. Or the way around is, they say, you should fix the problems in design level. Also, ideally, you have to close the problems only once. But there are some times where the problems get reopened repeatedly. Probably someone is not doing their design properly. Design issues can manifest to lot of problems.

The biggest help you can do to your team is to do your own tasks properly. Always make sure that you are complete your tasks as perfectly as you can, with the best quality. Don't assume your team mates to dedicate their time to review your work. It is a good to have. But make sure you don't rely on others review. Make sure not to leave any loose ends. Never leave any loop holes. Understand that others have to complete their own tasks as well. Dedicating their time to look in to your work is only going to bring down their work quality as well. Ofcourse helping your team mates is important, but make sure you can work with least help from others. Make sure to have all the necessary things (tools, knowledge, etc) needed to complete the work before hand. If others constantly have to babysit you, then clearly you need some improvements. Be the improvement be on your knowledge, practice etc. Also, please do these improvements on your own time and dedicate time for this. Don't think that these things will improve solely from your hands own from the work.

For an engineer knowledge is a very important asset. Your knowledge is your responsibility. You need have what you don't have. Dedicate time to accumulate it. Make sure to collect your knowledge from proper sources. It is good to refer Wikipedia to your doubts. But depending solely on Wikipedia is a big mistake. You can never work on something with only Wikipedia level of knowledge. For engineers mostly the proper source of this information are specifications. There are places like IETF, IEEE, ISO, ITU-T or OIF where you can freely get these specifications. Also, try to understand the specifications are written and maintained to have common understanding between all engineers. So, if someone is going through these specifications and arrive on a different conclusion from others, then clearly there is some problem here. Try to find out if the problem was on your side or on their side. There is nothing like, anyone can go through them and have their own interpretations. The specifications are there to have common interpretations. Clearly, there can be different ways of implementation of the same specifications. But different implementations must have same functionalities covered and they should interoperate.

It is important to realise that there are always more/new things to learn. Also, somewhere out there, there are people better than you. Being a better engineer is an ongoing process. We should have the self awareness of how much exactly we know of and how much exactly we may not know of as well. Because not knowing what exactly you cannot do can land you in troublesome situations. This is why self awareness of own knowledge is very important.