DEV Community: Harsh Raj

First year ECE — what I actually learned vs what I expected

Harsh Raj — Sat, 02 May 2026 17:13:23 +0000

When I joined ECE I had a rough idea of what to expect. Circuits, signals, maybe some programming. I thought the first year would be mostly theory — formulas, diagrams, exams — and the real learning would come later.
Some of that was right. Some of it was completely wrong.
What I expected
I expected most of the year to be sitting in class, copying notes, studying for tests. I thought hands-on work would come in later years once I had enough theory behind me. I also thought I would mostly be working alone.
What actually happened
The theory was there, yes. Physics, maths, basic electronics. A lot of it felt abstract at first — I could follow the formulas without really understanding what they meant in real life.
But then the projects started.
We had to build things. Not simulate them, not draw them on paper — actually build them on a breadboard, connect real wires to real components, and make them work. And when something did not work, we had to figure out why.
That is where the real learning happened.
The projects changed everything
Before the Larson Scanner I did not understand what a timer IC actually does. I had read about it. I could answer exam questions about it. But I did not really get it.
Then I wired up the NE555, calculated the resistor values, connected everything, and watched the LEDs bounce. Suddenly the formula was not just a formula — it was the thing controlling the speed of those LEDs.
The same thing happened with the leak detector. I understood what a rolling average was in theory. But building one into a real system, seeing it stop the false alarms, watching it actually work — that made it stick in a way that no lecture could.
What surprised me most
Working with classmates was more useful than I expected. I assumed group projects meant one person does the work and others watch. That was not our experience. When you are both stuck on the same problem, you think differently together than you do alone. We caught each other's mistakes. We came up with ideas the other person had not thought of.
I also did not expect documentation to matter this much. Writing the project report forced me to understand what I had built well enough to explain it clearly. There were a few moments where I started writing and realized I did not actually understand something as well as I thought. So I went back and figured it out properly.
What I would tell myself before starting
The theory matters, but do not wait for it to be complete before you start building. You learn the theory better by using it than by studying it in isolation.
Also — take your projects seriously even when they are small. A well-documented, working mini project is worth more on your profile than ten half-finished ones.
Where I am now
First year done. Four projects submitted. A portfolio live on the internet.
I know I am still at the beginning. There is a lot I do not know yet. But I know more than I did a year ago, and I know it in a way that actually sticks.
That feels like the right kind of progress.

Written at the end of my first year studying B.Tech ECE at DIT University, Dehradun.

What the leak detector taught me about real-world noise

Harsh Raj — Sat, 02 May 2026 17:10:13 +0000

Before I built the leak detector, I thought sensors just worked. You connect them, they give you data, you use that data. Simple.
That is not how it goes.
The problem
The SW-420 vibration sensor is a small, cheap component. When something vibrates near it, the output goes HIGH. When it stops, it goes LOW. On paper this is exactly what you need to detect a leaking pipe — the leak creates a constant vibration, the sensor picks it up, you trigger an alarm.
In reality, everything vibrates. A truck driving past the road outside. Someone walking nearby. Wind hitting the surface. Even just tapping the table the circuit is sitting on.
During early testing, the alarm was going off constantly. Not because of leaks. Because of everything else.
First attempt at fixing it — thresholds
My first idea was to add a threshold. Only trigger if the vibration is strong enough. Set a minimum magnitude using the ADXL345 accelerometer and ignore anything below it.
This helped a little. But trucks and heavy footsteps still crossed the threshold. The alarm still fired randomly.
The actual fix — time
The key insight was simple once I thought about it: a real leak is continuous. A truck passes in under a second. A footstep lasts 0.3 seconds. But a pipe leak hisses 24 hours a day without stopping.
So instead of asking "is the vibration strong enough right now?" I changed the question to "has the vibration been strong enough for the last 2 seconds?"
I added a timer. The system only confirms a leak after the signal stays above the threshold for 2 full continuous seconds. If the vibration drops even once during those 2 seconds, the timer resets.
False alarms dropped to zero.
The rolling average
There was still one small problem. The raw accelerometer reading fluctuates even during real vibration. It would dip briefly below the threshold for one reading, then come back up. This was causing the timer to reset unnecessarily.
The fix was a 1-second rolling average. Instead of looking at the current reading, the system looks at the average of the last 10 readings (one per 100ms). A single dip only affects the average by 10% — not enough to reset the timer.
After adding this, the countdown ran smoothly through continuous vibration with no resets.
What I learned
Real-world data is messy. The clean signal you imagine in your head when you design a system rarely exists in practice. You have to expect noise, plan for it, and build filtering into the system from the start.
The 2-second timer and the rolling average are both simple ideas. But they are the difference between a circuit that triggers randomly and one that works reliably.
Simple solutions, when applied to the right problem, work better than complex ones.

This was part of my Vibration Leak Detector mini project, completed in my first year at DIT University under Dr. Nafees Ahmed.

Why the NE555 timer is the most satisfying chip I've ever used

Harsh Raj — Sat, 02 May 2026 17:02:47 +0000

When my professor first mentioned the NE555 timer in class, I thought it was going to be one of those topics you study just to pass the exam and forget about. I was wrong.
The NE555 is a small chip that has been around since 1972. It costs about Rs. 10. And somehow, it can do more than I expected from something that cheap and that old.
What it actually does
In simple terms — it makes a clock. A steady pulse that goes HIGH and LOW at a set speed. That's it.
You set two resistors and one capacitor, plug in the formula, and you get a frequency. For my Larson Scanner project I needed about 1.5 Hz — meaning the signal switches 1.5 times per second. I calculated the resistor values, connected them, powered the circuit, and measured 1.48 Hz on the output. That's within 2% of what the math said it should be.
That moment felt good. The math worked. The real world agreed.
Why it's satisfying
Most things in electronics have some gap between theory and reality. Sensors give noisy data. Connections have resistance you didn't account for. Something always behaves slightly differently than the datasheet says.
The NE555 just works. You calculate, you build, you measure, and the numbers match. For someone who is still learning, that kind of clean result matters a lot.
What I built with it
I used the NE555 for my Larson Scanner — the bouncing LED display from Knight Rider. The entire circuit has no microcontroller, no code, nothing programmable. Just the NE555 for the clock, a CD4017 decade counter to step through the LEDs, and six diodes to make the bounce effect work.
The full circuit costs under Rs. 200 and runs on a 9V battery. I tested it for 30 minutes straight. No stuck LEDs, no false triggers, no issues.
What it taught me
Before this project I thought you needed a microcontroller for everything. Write code, upload it, run it. That's the only way.
The NE555 showed me that is not true. Sometimes hardware logic alone can do the job — and do it more reliably, with fewer parts, and at a lower cost than any microcontroller solution would.
That is a mindset shift I will carry forward.

This was part of my Larson Scanner mini project, completed in my first year at DIT University under Dr. Saurabh Mishra.