Engineering Insights

Detailed write-ups on my portfolio projects, from Embedded Systems to AI and OS Architecture.

Detecting Faults on Three-Phase Transmission Lines: From First-Principles Logistic Regression to Support Vector Machines

Three-Phase Transmission Line Fault Detection Dashboard

A practical deep-dive into transmission line fault classification using custom NumPy implementations and Support Vector Machines (Linear vs. RBF Kernels).

1. Introduction & The Engineering Challenge

In high-voltage electrical power grids, three-phase transmission lines are the critical arteries carrying bulk electrical power across vast distances. However, these lines operate exposed to severe environmental stressors and are vulnerable to various fault conditions:

  • Line-to-Ground (L-G) Faults: Typically caused by lightning strikes, tree encroachment, or insulation flashover.
  • Line-to-Line (L-L) Faults: Physical contact between phase conductors due to high winds, conductor galloping, or tower sway.
  • Double Line-to-Ground (L-L-G) Faults: Multi-phase contact involving ground path.
  • Three-Phase Symmetrical (L-L-L / L-L-L-G) Faults: Severe short-circuits across all phases simultaneously.

When a short-circuit occurs, instantaneous currents surge to destructive levels, while voltages sag sharply due to the collapse of line impedance. A numerical protective relay must detect this abnormal condition within milliseconds (typically 1–2 cycles of 50/60 Hz power frequency, or 20–40 ms) and send a trip signal to the circuit breaker before transformer cores saturate or conductors melt.

In this project, we address a foundational engineering and machine learning question:

"Can a linear decision boundary detect a fault from instantaneous 3-phase current and voltage measurements? If not, what is the simplest and most effective fix: expanding the feature space (e.g., quadratic features) or using non-linear kernels (e.g., RBF Support Vector Machines)?"

To rigorously understand the underlying mathematical mechanics, we implement Logistic Regression completely from scratch using NumPy (avoiding high-level abstractions like Scikit-Learn's estimators, scalers, or train-test split utilities) and benchmark it directly against Linear and Radial Basis Function (RBF) Support Vector Machines (SVMs).

2. Dataset and Preprocessing Pipeline

We utilized the Electrical Fault Detection and Classification benchmark dataset from Kaggle, simulated in MATLAB/Simulink. Each observation represents an instantaneous measurement sample containing 6 physical quantities:

  • Ia, Ib, Ic: Instantaneous currents of phases A, B, and C (Amperes).
  • Va, Vb, Vc: Instantaneous voltages of phases A, B, and C (per-unit system).
  • y ∈ {0, 1}: Binary ground-truth target where 1 denotes a fault condition and 0 denotes normal healthy operation.

Data Cleaning and Leak-Free Standardisation:

  • Uninformative Column Removal: The raw CSV dataset contained two empty trailing columns (Unnamed: 7 and Unnamed: 8), which were dropped.
  • Deterministic Partitioning: The cleaned dataset (12,001 rows) was split into 60% Training (7,200 rows), 20% Validation (2,400 rows), and 20% Test (2,401 rows) using a fixed random seed (np.random.default_rng(42)). The fault class proportion remained balanced across all splits (~45.1% – 46.1% faults).
  • Strict Standardisation: To prevent data leakage, the mean μ and standard deviation σ were computed solely from the training partition and then applied to transform the validation and test partitions: z = (x - μtrain) / σtrain

Feature Sets Defined:

  • Set R (Raw Features, d=6): [Ia, Ib, Ic, Va, Vb, Vc]
  • Set Q (Quadratic Features, d=12): [Ia, Ib, Ic, Va, Vb, Vc, Ia2, Ib2, Ic2, Va2, Vb2, Vc2]

Crucial engineering detail: For Set Q, the squared features were computed from the raw physical values before computing the 12-dimensional training mean and standard deviation for standardisation.

Property / Metric Value
Raw rows / raw columns12,001 rows / 9 columns
Columns removedUnnamed: 7, Unnamed: 8
Missing values after cleaning0
Fault rows / Healthy rows5,496 fault (45.8%) / 6,505 healthy (54.2%)
Train / Validation / Test rows7,200 / 2,400 / 2,401
Fault fraction in Train / Val / Test0.4607 / 0.4512 / 0.4565

3. Exploratory Data Analysis: Why Linear Classifiers Fail

Before training any machine learning model, exploratory data analysis reveals the fundamental physical geometry of power transmission signals.

Line Currents vs Sample Row
Figure 1: Instantaneous phase currents (Ia, Ib, Ic) across the first 2,000 samples with shaded fault intervals.

In normal healthy conditions, currents follow clean sinusoidal oscillations with bounded amplitudes. Once a fault strikes, the currents surge instantaneously by several orders of magnitude, accompanied by severe phase asymmetry and voltage collapse.

Scatter Plot of Ia vs Ib
Figure 2: Phase-plane scatter plot of Phase A current (Ia) vs Phase B current (Ib) showing annular fault distribution.

The Phase-Plane Geometry (Ia vs Ib):

  • Normal operating points form a compact cluster centered at the origin (0, 0).
  • Fault points form a broad annular ring (torus) completely encircling the normal operating cluster.

Why does a linear hyperplane fail? Because alternating currents oscillate symmetrically across zero every half cycle, instantaneous fault currents swing between positive peaks and negative troughs. Fault states surround the origin in all directions. A flat linear hyperplane cutting through the 6D feature space cannot isolate the interior healthy core from the exterior surrounding fault ring without triggering immense misclassifications.

Histogram of Phase A Current
Figure 3: Histogram distribution of Phase A current (Ia) comparing healthy vs fault operating states.

4. Model Implementation & Training

4.1 Logistic Regression from Scratch (NumPy)

The logistic regression model parameters θ ∈ ℝd+1 were trained using custom vectorized NumPy routines:

  • Sigmoid Hypothesis: hθ(x) = 1 / (1 + exp(-θT x))
  • Negative Log-Likelihood Cost with Numerical Clipping: Probabilities were clipped to [10-12, 1 - 10-12] to prevent ±∞ overflow during log evaluations.
  • Vectorized Gradient Descent: Parameters updated iteratively via θ := θ + (α/m) XT (y - hθ(X)).
Learning Rate Tuning for Set R
Figure 4: Cost J(θ) vs iterations for Set R across learning rates α ∈ {0.01, 0.1, 1.0, 10.0}.
Learning Rate Tuning for Set Q
Figure 5: Cost J(θ) vs iterations for Set Q across learning rates α ∈ {0.01, 0.1, 1.0, 10.0}.

For both feature sets, cost curves strictly monotonically decreased with α = 1.0 (Set R) and α = 10.0 (Set Q), converging cleanly from the theoretical initial cost J(0) = ln(2) ≈ 0.693147.

Feature Set Chosen Learning Rate (α) Final Cost J(θ) Validation Accuracy
Set R (Raw, d=6)α = 1.00.67716173.08%
Set Q (Quadratic, d=12)α = 10.00.05343497.83%

4.2 Support Vector Machines (Linear vs. RBF Kernels)

We trained Support Vector Classifiers on Set R across regularisation parameter C ∈ {0.1, 1.0, 10.0, 100.0} and kernel coefficients γ ∈ {0.1, 1.0}:

SVM Accuracy vs Regularisation Parameter C
Figure 6: SVM validation accuracy and support vector counts across regularisation parameter C.
Kernel C γ Validation Accuracy Support Vectors
Linear0.1-72.58%5,849 / 7,200
Linear1.0-72.58%5,843 / 7,200
Linear10.0-72.58%5,835 / 7,200
Linear100.0-72.62%5,835 / 7,200
RBF0.10.195.00%1,347 / 7,200
RBF0.11.098.04%848 / 7,200
RBF1.00.197.50%723 / 7,200
RBF1.01.099.17%482 / 7,200
RBF10.00.199.21%381 / 7,200
RBF10.01.099.62%342 / 7,200
RBF100.00.199.54%174 / 7,200
RBF100.01.099.67%266 / 7,200

5. Unbiased Test Set Performance Evaluation

Evaluating the four selected final candidate models exactly once on the held-out test partition (2,401 rows):

Model Architecture Test Accuracy True Negatives (TN) False Alarms (FP) Missed Faults (FN) True Positives (TP)
Logistic Regression (Set R)72.64%1,3050657439
Linear SVM (C=100)73.64%1,3050633463
Logistic Regression (Set Q)97.88%1,2996451,051
RBF SVM (C=100, γ=1.0)99.58%1,301461,090

6. Deep Analytical Insights

6.1 Physical Meaning of the Learned Quadratic Weights (θ)

Inspecting the learned parameter vector θ for Set Q reveals how machine learning captures real-world electrical circuit physics:

Weight Index Feature Learned Value Physical Interpretation
θ0Bias / Intercept+24.9209Baseline log-odds offset
θ1Ia+2.3273Linear phase current correlation
θ2Ib-5.3581Phase balance offset
θ3Ic-1.7365Phase balance offset
θ4Va-0.5336Voltage coupling
θ5Vb+0.4167Voltage coupling
θ6Vc+0.0986Voltage coupling
θ7Ia2+18.8912High Energy / Overcurrent Surge (+)
θ8Ib2+4.7543High Energy / Overcurrent Surge (+)
θ9Ic2+13.9569High Energy / Overcurrent Surge (+)
θ10Va2-6.0276Healthy Voltage Indicator (−)
θ11Vb2-6.4643Healthy Voltage Indicator (−)
θ12Vc2-6.1407Healthy Voltage Indicator (−)

Notice that the weights on the squared currents (Ia2, Ib2, Ic2) are massively positive (±18.89, ±13.96), pushing the sigmoid probability towards 1 (Fault). Conversely, the weights on the squared voltages (Va2, Vb2, Vc2) are consistently negative (-6.03 to -6.46), pushing the probability towards 0 (Healthy).

When a line faults, currents soar (short-circuit) and voltages collapse (impedance drops). The quadratic terms measure the instantaneous electrical energy magnitude E ∝ I2, transforming the doughnut-shaped annular ring into a cleanly separable elliptic paraboloid!

6.2 Support Vector Dynamics: Linear vs RBF

The Linear SVM required 5,835 support vectors out of 7,200 training rows (81.0%)! This enormous support vector count confirms that points are constantly violating the margins and that linear separation is fundamentally impossible.

In contrast, the RBF SVM with C=100 and γ=1.0 achieved 99.6% accuracy with only 266 support vectors (3.7%). The kernel function implicitly projects the data into an infinite-dimensional Hilbert space where an optimal maximum-margin hyperplane separates the fault manifolds effortlessly.

6.3 Relay Engineering: Missed Faults vs False Alarms

In protective relaying, a missed fault (False Negative) is an operational disaster. If a fault is missed, fault current continues to arc through the transmission tower, destroying transformers, endangering human life, and destabilizing the grid. A false alarm (False Positive) is merely an inconvenience that causes an unnecessary breaker trip.

While linear models miss over 630 faults on the test set, the RBF SVM reduces missed faults to just 6 (and Set Q Logistic Regression reduces it to 45).

7. Full-Stack Interactive Web Dashboard

To make this system accessible to power systems operators and electrical engineers, we built an interactive dashboard with glassmorphism dark UI styling. It allows users to:

  • Enter custom instantaneous 3-phase currents (Ia, Ib, Ic) and voltages (Va, Vb, Vc).
  • Select predefined realistic fault presets (Healthy Baseline, Phase A-G Fault, Severe Three-Phase Symmetrical Short Circuit).
  • Get instantaneous real-time inference with probability gauges comparing Quadratic Logistic Regression vs. RBF Support Vector Machine side-by-side.

8. Summary & Key Takeaways

  • Geometry Dictates Model Choice: AC oscillatory signals create circular/annular geometric distributions in phase-space that linear models cannot separate (capped at ~73%).
  • Physics-Informed Feature Engineering: Introducing quadratic features (I2, V2) lifted simple logistic regression accuracy from 73.0% to 97.9% without adding complex model latency.
  • Non-Linear Kernels: RBF SVM achieved the highest test performance (99.58% accuracy with only 6 missed faults).
  • Zero-Dependency Fundamentals: Writing logistic regression from scratch in pure NumPy provides profound insight into standardisation, numerical stability, and optimization dynamics.

Explore the Complete Source Code

Full Python source code, NumPy implementations, EDA notebooks, Streamlit app, and pretrained models are available on GitHub.

View GitHub Repository

Predicting Solar Power Plant Output from Weather Data: A Linear Regression Study from Scratch

Solar Power Prediction Dashboard

Evaluating On-Site Weather Sensors vs. Public Satellite Reanalysis Data for Grid-Scale Solar Generation Forecasting

1. The Question & Problem Motivation

Solar photovoltaic (PV) power generation is inherently variable, dependent on diurnal solar geometry, atmospheric cloud attenuation, and panel temperature dynamics. For electrical grid operators, predicting solar plant AC power generation hours in advance is essential for load balancing, spinning reserve allocation, and grid frequency stability.

In this study, we investigate three core machine learning questions:

  • Predictive Accuracy: Can linear regression fit strictly from scratch accurately predict plant-level hourly AC power generation (PAC) using atmospheric weather variables?
  • On-Site vs. Remote Public Data: How much prediction accuracy is lost when replacing expensive on-site weather sensors with free, publicly accessible satellite reanalysis weather data (Open-Meteo API)?
  • Optimization Solvers: How do closed-form analytical solvers (Normal Equation) compare to iterative optimization algorithms (Batch Gradient Descent and Stochastic Gradient Descent)?

2. Data Engineering & Preparation

We analyze 34 days of continuous generation and weather data (May 15, 2020 – June 17, 2020) from Plant 1, located near Gandikota, Andhra Pradesh, India (Lat 14.82°N, Lon 78.28°E).

Preprocessing Pipeline:

  • Timestamp Standardization: Raw generation files used non-standard date strings (DD-MM-YYYY HH:MM), whereas weather sensors logged standard ISO timestamps. All timestamps were standardized into native UTC/IST datetimes.
  • Plant-Level Power Aggregation: The plant contains 22 separate central inverters. We aggregated total plant generation by summing AC_POWER and DC_POWER across all inverters at each 15-minute timestamp.
  • Hourly Resampling: The 15-minute merged generation and weather readings were resampled to hourly arithmetic means, producing a clean dataset of 796 hourly rows.
Metric / Parameter Value
Raw generation rows (Plant 1)68,778
Raw sensor rows (Plant 1)3,182
Timestamps present in only one file26
Hourly rows after resampling796
Hourly rows with missing values0
Open-Meteo weather rows downloaded816
Correlation (Sensor vs Open-Meteo)0.9333
Peak Hour Comparison12:00 PM (Identical)

3. Exploratory Data Analysis (EDA)

Before modeling, we explored the physical relationships across solar generation and meteorological variables.

AC Power vs Irradiation
Figure 1: AC Power vs. Irradiation scatter plot.
Module Temperature vs Ambient Temperature
Figure 2: PV Module Temperature vs. Ambient Air Temperature (colored by irradiation).
AC Power vs DC Power
Figure 3: AC Power vs. DC Power linear conversion ratio (Inverter efficiency ≈ 0.098).
Average AC Power by Hour of Day
Figure 4: Mean AC Power by hour of day (diurnal bell curve peaking at solar noon).

Key EDA Insights:

  • Linear Photovoltaic Response: AC power shows a strong linear correlation with solar irradiance (r > 0.95).
  • Thermal Panel Elevation: PV module temperature regularly exceeds ambient air temperature by 15–25°C under direct solar irradiance due to radiative heating.
  • Inverter Conversion Ratio: AC power vs DC power exhibits a near-perfect linear ratio of 0.098 (accounting for central inverter scaling and conversion efficiency).
  • Diurnal Bell Curve: Hourly mean AC power follows a symmetrical bell curve peaking between 11:00 AM and 1:00 PM, dropping to zero at night.

4. Location Verification: On-Site Sensor vs. Open-Meteo API

To verify the geographical coordinates of Plant 1 (Lat 14.82°N, Lon 78.28°E), we downloaded historical ERA5 reanalysis weather data from the Open-Meteo Historical Weather API and compared on-site sensor irradiance against satellite-derived shortwave radiation.

Location Verification Plot
Figure 5: 3-day location verification comparison (Sensor Irradiation vs. Open-Meteo Shortwave Radiation).

Verification Findings:

  • The correlation between on-site sensor irradiation and Open-Meteo shortwave radiation reached 0.9333, confirming exact spatial alignment.
  • Both signals reach peak intensity at 12:00 PM IST, confirming no time-zone offset or solar longitude discrepancy.

5. Linear Regression Implementation & Solver Results

All algorithms were implemented from scratch using NumPy matrix operations:

  • Normal Equation: θ = (XTX)-1 XTy
  • Batch Gradient Descent: θ ← θ − α (1/m) XT(Xθ − y)
  • Stochastic Gradient Descent: θ ← θ − α (x(i))T(x(i)θ − y(i))

Feature Sets:

  • Set A (On-Site Sensors): irradiation, module_temp, ambient_temp, sin/cos hour encoding (d=5)
  • Set B (Public Weather): sw_radiation, temp_2m, cloud_cover, sin/cos hour encoding (d=5)

Feature Scaling used Z-score standardization with training set mean and standard deviation only. Train/Test Split: Chronological split — Train = May 15 to June 10 (628 hours), Test = June 11 to June 17 (168 hours).

Batch GD Learning Rates
Figure 6: Batch GD Cost J(θ) vs. Iteration for α ∈ {10⁻⁵, 10⁻⁴, 10⁻³}.
SGD Learning Rates
Figure 7: SGD Cost J(θ) vs. Epoch for α ∈ {10⁻⁴, 10⁻³, 10⁻²}.

Test-Set RMSE Performance (kW):

Feature Set Solver Method Train RMSE Test RMSE (All) Test RMSE (Day)
Set A (Sensors)Normal Equation537.62539.46704.46
Set A (Sensors)Batch GD (α=0.001)741.84880.251,144.76
Set A (Sensors)SGD (α=0.01)539.93549.47714.47
Set B (Public)Normal Equation2,699.922,620.943,409.50
Set B (Public)Batch GD (α=0.1)2,699.922,620.943,409.50
Set B (Public)SGD (α=0.01)2,744.922,699.923,453.25

Learned Weight Vector (θ) for Set A:

Feature Normal Eq Batch GD SGD Interpretation
Intercept (x₀=1)+6,890.57+6,890.57+6,876.12Mean baseline plant power
irradiation+8,345.04+8,345.04+8,312.45Primary Driver (+)
module_temp-108.12-108.12-104.30Thermal Efficiency Drop (−)
ambient_temp-17.16-17.16-15.80Minor ambient coupling
sin_hour-47.38-47.38-42.10AM/PM asymmetry correction
cos_hour-416.56-416.56-410.20Diurnal cycle suppression

6. On-Site Sensors vs. Public Weather Data

  • Set A Daytime RMSE: 704.46 kW (2.35% of 30 MW plant capacity)
  • Set B Daytime RMSE: 3,409.50 kW (11.36% of 30 MW plant capacity)
  • Relative Difference: Public weather data incurs +384% higher RMSE
Actual vs Predicted Test Week
Figure 8: Actual vs. Predicted AC Power across the 7-day test week (June 11–17, 2020).
Open-Meteo relies on satellite reanalysis grids (~10 km resolution). Sudden local cloud shadows passing over the plant are missed by satellite grids. Additionally, on-site sensors measure direct panel glass temperature (module_temp), which rises to 65°C under sunlight. Set B only has 2m air temperature, completely missing semiconductor thermal efficiency degradation.

7. Model Diagnostics & Residual Analysis

Residuals vs Hour of Day
Figure 9: Residuals (y − ŷ) vs. Hour of Day for Set A Normal Equation.
  • Nighttime (19:00 – 05:00): Residuals are identically zero due to post-processing ReLU clipping (max(ŷ, 0)).
  • Midday Peak Error (11:00 – 14:00): Residuals show maximum variance (±2,000 kW). This is caused by inverter saturation/clipping at maximum solar irradiance and rapid thermal transient lags during midday cloud passages.

8. Conclusion & Key Takeaways

  • Photovoltaic Physics Matter: Solar irradiance is the dominant driver of generation (θ₁ = +8345), while module temperature exhibits a clear negative efficiency penalty (θ₂ = −108).
  • On-Site Sensors are Mandatory for Precision: Relying solely on free public weather APIs increases prediction error by nearly 4× (704 kW vs 3,409 kW daytime RMSE).
  • Closed-Form Normal Equation is Superior for Small m: For m ≈ 800 rows, the analytical Normal Equation achieves exact global minimum weights instantaneously without hyperparameter tuning.

Explore the Complete Source Code

Full Python source code, NumPy implementations, EDA notebooks, Streamlit app, and pretrained models are available on GitHub.

View GitHub Repository

Building an Autonomous Line-Following Robot

Robotics is the ultimate intersection of hardware and software. One of my fundamental projects during my B.S. in Electrical Engineering at FAST NUCES was designing and building a completely autonomous line-following robot from scratch. The objective was simple but the implementation required precise tuning: navigate a complex track using IR sensors without any human intervention.

Hardware Architecture

At the brain of the operation was the Arduino Uno. I selected it for its rapid prototyping capabilities and robust community support. To detect the line, I implemented an array of IR (Infrared) sensors. These sensors constantly measure the reflectivity of the surface beneath them—differentiating between the dark track line and the lighter floor.

The motor control was handled via an L298N motor driver, enabling bidirectional control of two DC motors. Power management was critical; I had to ensure the motors drew enough current without browning out the microcontroller.

Software and PID Tuning

Writing the control logic was the most challenging and rewarding part. A simple "if left sensor sees black, turn left" algorithm results in incredibly jerky and inefficient movement. To solve this, I implemented a custom algorithm inspired by PID (Proportional, Integral, Derivative) control logic.

"The key to smooth robotics isn't just knowing where you are, but predicting where the momentum will take you in the next few milliseconds."

By reading the analog values of the IR array, the robot could calculate an "error" value based on how far off-center the line was, and adjust the motor PWM (Pulse Width Modulation) speeds proportionally. This resulted in buttery-smooth cornering.

Conclusion

This project solidified my understanding of closed-loop control systems and real-time microcontroller programming. It served as a fantastic stepping stone into more complex embedded architectures.

Designing a Role-Based Smart Home Automation System with ATmega32

While Arduinos are great for prototyping, industrial and commercial applications demand bare-metal microcontroller programming. To challenge myself with low-level register manipulation in C, I designed a Smart Home Automation System utilizing the ATmega32 microcontroller.

System Overview

The project wasn't just about turning lights on and off; it was about security and hierarchy. I implemented a robust role-based access system. The system differentiates between "Admin" users and "Guest" users.

  • Admin Access: Can configure the system, add/remove guests, and control all appliances.
  • Guest Access: Can only toggle basic lighting and fan states, restricted from security controls.

Implementation Details

I interfaced a 4x4 matrix keypad for passcode entry and an alphanumeric LCD (16x2) for the user interface. Programming these peripherals required writing custom driver libraries in C, managing the GPIO (General Purpose Input/Output) registers directly rather than relying on abstracted libraries.

Authentication data (passwords and roles) was stored and retrieved from the ATmega32's internal EEPROM, ensuring that the system retained its configuration even after a power loss.

The Hardware Challenge

To safely control high-voltage AC appliances (simulated via 220V bulbs in the prototype), I designed an isolation circuit using optocouplers and mechanical relays. This ensured that any power surge on the AC side would not fry the delicate 5V DC logic of the ATmega32. This project deeply enhanced my understanding of memory management, bare-metal C programming, and power electronics isolation.

Simulating an OS: Process & Resource Management in User-Space

As an Electrical Engineer, my focus is primarily on hardware, but understanding how software interfaces with the CPU is crucial. To bridge this gap, I developed an OS Process and Resource Manager—a User-Space Operating System Simulator written entirely in C++.

Core Mechanisms Modeled

Operating systems are massive, complex beasts. For this simulator, I focused strictly on the core kernel responsibilities:

  • Process States: Implemented a state machine for processes transitioning between New, Ready, Running, Waiting, and Terminated.
  • Context Switching: Simulated saving and loading the CPU registers (Process Control Block - PCB) when swapping out processes.
  • Resource Allocation: Implemented Banker's Algorithm to handle simulated memory and peripheral requests, ensuring the system never enters a deadlock state.

Data Structures & Algorithms

Efficiency was key. I utilized custom queue structures to manage the Ready Queue and Waiting Queues. The scheduling algorithm utilized was a simulated Round-Robin with dynamic time-quantums, adjusting based on whether the process was I/O bound or CPU bound.

By building this simulator, the abstract concepts of CPU scheduling, mutexes, semaphores, and memory paging became concrete logic in my mind. It heavily influences how I write firmware today, ensuring my microcontroller code is non-blocking and resource-efficient.

Lessons Learned: My AI Internship at CyberGen

During the summer of 2025 (July - August), I had the privilege of joining CyberGen as an AI Intern. It was an eye-opening experience that took my theoretical knowledge of Python and Machine Learning and subjected it to the rigors of real-world corporate demands.

What I Worked On

My primary responsibility was assisting the senior engineering team with AI-based tasks and workflow automation. Much of the data processing tasks that took hours were ripe for automation. I developed Python scripts utilizing Pandas and NumPy to clean and preprocess massive datasets before they were fed into the training pipelines.

Furthermore, I gained hands-on experience evaluating the outputs of Large Language Models (LLMs) to ensure response accuracy and safety compliance for internal tooling.

The Biggest Takeaway

The most valuable lesson wasn't a specific coding framework, but rather the importance of data quality. An AI model is only as intelligent as the data it trains on. Garbage in, garbage out. My time at CyberGen taught me to rigorously validate datasets and treat data engineering with the same respect as algorithm design.

Practical Analog Automation: Proteus Circuit Simulations

Before soldering a single component, a robust circuit design must be simulated and stressed. I frequently use Proteus to validate my analog designs. Two of my favorite foundational analog projects are the Automatic Street Light System and the Temperature Controlled Fan.

The Automatic Street Light

This project entirely avoids microcontrollers. It relies purely on the physics of an LDR (Light Dependent Resistor) and the switching properties of BJT transistors. By setting up the LDR in a voltage divider configuration with a variable potentiometer, I created a tunable threshold. As ambient light drops, the LDR resistance spikes, altering the voltage at the transistor's base. Once the base-emitter voltage exceeds ~0.7V, the transistor saturates, triggering a relay that powers the street lamp. It's an elegant, highly reliable, and cheap analog solution.

The Temperature Controlled Fan

Similar in philosophy, this circuit utilizes an NTC Thermistor or an LM35 sensor. Using an Operational Amplifier (Op-Amp) configured as a comparator, the circuit compares the voltage from the temperature sensor against a reference voltage (set by a potentiometer).

When the temperature crosses the threshold, the Op-Amp outputs high, driving a MOSFET which in turn spins up a DC cooling fan.

These projects reinforce a core engineering philosophy: don't use a $5 microcontroller when a $0.10 Op-Amp and a sensor can do the job with zero latency and infinite reliability.