Electrical engineering.
Analytical thinking.

My contribution

Synthesised and scaled loop coefficients, modelled the modulator and assessed SQNR, harmonic distortion, stability, integrator gain and mismatch.

Results & limitations

The ideal-case simulation reported 115.4 dB SQNR against a 105 dB target. Non-ideal cases degraded performance. This is a simulation result, not a measurement from a fabricated ADC. The report contains inconsistent dither labels, so no dither setting is assigned to that figure here.

Architecture and evaluation

Used a third-order cascade-of-resonators feed-forward architecture with a 3-bit quantiser and OSR of 128. Compared design options and synthesised coefficients with the Delta-Sigma Toolbox before scaling the loop and evaluating the Simulink model.

Test programme

Examined spectra and signal quality across input conditions, then varied finite integrator gain, loop-coefficient mismatch, DAC mismatch and dither. These experiments distinguish an ideal noise-shaping baseline from sensitivity to implementation non-idealities.

What the figures demonstrate

The block diagram explains the chosen architecture. The output spectrum shows the ideal-case noise-shaping behaviour. A strong ideal result does not establish that every non-ideal case meets the target, or that a physical converter would reproduce it.

Link to this project ↗

Approach

Estimated transfer-function parameters from step-response measurements, investigated frequency response and stability, and applied Ziegler–Nichols tuning followed by practical adjustment.

Reported outcome

The lab report describes reducing overshoot below 20% while retaining zero steady-state error. The exercise demonstrated the trade-off between response speed, overshoot and stability in the tested setup.

System identification

Used measured step responses to estimate steady-state gain and time constants, then compared an empirical motor model with a model derived from the motor’s physical relationships.

Control design

Explored open-loop and closed-loop behaviour, frequency response and stability. Used Ziegler–Nichols methods as an initial tuning point, then adjusted proportional, integral and derivative parameters to manage overshoot and response speed.

What changed in testing

The report records reducing proportional gain and increasing derivative time during final adjustment. The response plot below shows the tested setup approaching its setpoint with reduced oscillation; the reported sub-20% overshoot result is specific to that laboratory exercise.

Link to this project ↗

The signal chain

Designed the amplifier in LTspice, built it on breadboard, substituted available components and added decoupling, power indication and a measurement path. The microphone signal was digitised by the STM32, transferred as sample values and converted to a waveform and WAV file in MATLAB.

Supporting microcontroller work

My accompanying STM32 labbook also documents LED duty-cycle experiments, UART communication with a terminal, and conversion of 12-bit ADC samples back into voltage values. These exercises connect firmware configuration with observable outputs and support the later audio-recording work.

Testing the analogue front end

Checked DC bias and used a signal generator to investigate gain and cut-off behaviour. Practical component substitutions produced differences from the intended filter response, which the report compared with simulation.

Result and limitations

The recording was quiet and its observed duration differed from the expected sample count and rate. The report discusses possible microphone/input-level causes, but does not establish a single confirmed root cause. This is a useful example of connecting analogue measurements with digital-sampling checks.

Link to this project ↗

From truth tables to sequential behaviour

My digital-systems daybook documents a half-adder using NAND and XOR logic, followed by D-latch, flip-flop and shift-register experiments. Truth tables connect the gate-level circuit with its expected outputs.

A four-stage shift register

Connected four CD4013 flip-flop stages in simulation to a common clock. The recorded outputs show the active bit progressing through 0001 → 0010 → 0100 → 1000 across successive clock periods.

Interpreting timing measurements

Used clock and data transitions to investigate propagation delay, setup time and hold time. The report compares observations with datasheet values and identifies a discrepancy in the hold-time estimate, considering stimulus settings and manual observation as possible causes.

These figures document discrete-logic circuit simulations. The FPGA and Verilog work is described separately.

Link to this project ↗

Practical work

Implemented and tested FPGA-based logic, including an LED-control application, and investigated hardware behaviour while applying digital-system concepts.

Design approach

Applied digital-logic concepts through simulation and implementation in Verilog, including finite-state machines and timing. Hardware testing helped connect expected logic behaviour with what the FPGA actually did.

Link to this project ↗

The task

Move a cube between initial and target poses with a dual-arm robot while accounting for an obstacle. The WANG_ULLAH submission brings together grasp geometry, motion planning, trajectory generation and torque control using the course’s simulation framework.

My contribution

My teammate and I worked together across the project, jointly developing and debugging the geometry, planning and control stages.

Grasp configurations

The inverse-geometry routine stacks the two hand-pose errors and Jacobians, uses a pseudoinverse update with a posture-bias term, and projects configurations to joint limits. Collision checks are used while searching for configurations that align both hands with the cube’s hooks.

Planning a route

The RRT-style planner samples cube poses, solves for corresponding grasp configurations and grows a tree through local interpolations. Candidate connections include collision and obstacle-distance checks. A shortcut stage attempts to remove intermediate nodes through checked connections.

From path to motion

The control code densifies the joint path and constructs a Bézier trajectory with position, velocity and acceleration references. Inverse-dynamics tracking is combined with Cartesian spring forces at the grasp points, mapped into joint torques through the hand Jacobians.

Scope of the evidence

This is team coursework built on a supplied robotics framework. The recording illustrates the implementation in simulation; it does not establish physical-robot performance or continuous collision clearance after trajectory smoothing.

Link to this project ↗

Year 4: pandemic analysis

Built on supervisor-provided data and base R scripts. Standardised categorical variables, checked missingness, improved visualisations and extended models with sociodemographic predictors.

Year 5: longer-term trajectories

Extended the work to 14 main-survey waves with spline-based longitudinal analysis and complementary survey-weighted logistic regressions. The two dissertation stages used different survey datasets.

What I learned

Consistent variable definitions, careful model interpretation and clear attribution matter as much as producing a plot. This overview focuses on methods and contribution; respondent-level survey data is not distributed here.

From inconsistent data to analysable variables

Worked on consistent coding across waves, categorical-variable definitions, missingness summaries and comparison plots. This preparation was necessary before extending the statistical models or interpreting group differences.

Two complementary modelling views

Used spline-based longitudinal analysis to explore changing continuous scores, alongside wave-level survey-weighted logistic regressions for binary caseness. These analyses answer related questions but have different weighting and interpretation requirements.

Checking the model against observations

Compared predicted and observed aggregate trajectories as a diagnostic. Close agreement in a plot is not proof of causation or sufficient validation on its own. Complete-case selection and differences in survey-weight handling remain important limitations.

Link to this project ↗

My contribution

I extended the team’s baseline with a FixMatch training pipeline, weak/strong data augmentation and active-sampling strategies. I added label-allocation options, configured experiment sweeps, produced comparison plots and documented how teammates could run the experiments.

Working within a team

A teammate established the initial working SSDA baseline. I built on that foundation; the model, final submission and reported experiment results form part of our group study.

Scope & limitations

Experiments used a single random seed and limited training duration. Observed rankings are study-specific, rather than evidence that one strategy is universally best.

Research question

When only a small fraction of real target images can be labelled, does performance depend more on the training method, the examples selected, the allocation of labels across classes, or the total budget?

Training pipeline

Used a ResNet-50 backbone with a bottleneck head. Weakly augmented unlabelled images generated confidence-filtered pseudo-labels, while a strongly augmented view supplied the consistency-training loss. An exponential moving average of model weights was used for evaluation.

Experimental comparisons

Compared random, uncertainty, diversity and hybrid selection; proportional, equal and difficulty-based allocation; and budgets from 0.5% to 5%. The selection figure holds the nominal budget at 1%.

Interpreting the result responsibly

The source-pretrained model provided the selection signal before target adaptation. Rankings could depend on this choice. Experiments used one seed and limited epochs. The baseline and FixMatch training recipes also differ in optimiser and duration, so their comparison does not isolate the loss function alone.

Selection and label allocation

I extended the sampler to control two separate decisions: which images to label, and how many labels to allocate to each class. The implementation supports random, uncertainty, diversity and hybrid selection with proportional, equal or difficulty-based allocation.

Making experiments repeatable

I connected strategy, budget and allocation settings to environment-controlled SLURM jobs, organised sweep results and improved plot labels. Cluster-run fixes included checking that scratch-data copies existed before training, so a failed copy would stop clearly instead of failing later.

Reading the experiment figures

The three sweeps ask different questions. Selection compares which examples to label; budget varies the total labelled fraction; allocation distributes a fixed budget across classes. Each figure includes training curves and the best observed accuracy from that particular run.

Link to this project ↗

The engineering problem

Turn a day’s coursework delivery orders into validated delivery records and planned drone movements. Restaurant menus, orders, no-fly regions and the central area were supplied through REST endpoints.

How I structured the application

Separated data retrieval, shared application data, order validation, geometry, route search and output writing. The main application loaded the endpoint data and passed it to the delivery-processing stage.

Order validation

Implemented checks for payment-field formats and expiry, pizza count, menu membership, a single supplying restaurant, opening day and total price including the delivery charge. Validation codes describe why an order cannot proceed; these are coursework rules rather than a production payment-processing system.

Geometry and route search

The geometry helper provides coordinate-distance, next-position and polygon-membership operations. The planner expands 16 headings in 22.5° increments, keeps a priority queue of candidate cells and uses parent links to reconstruct a route.

The search score is weighted as f = g + 3h, where g represents accumulated movement cost and h estimates distance to the goal. This prioritises progress toward the goal; it does not establish a globally shortest route. Candidate positions are checked against no-fly polygons.

Outputs that can be inspected

The delivery stage writes a delivery-summary JSON file, movement-by-movement flight-path records, and a GeoJSON LineString combining the saved route coordinates. The figure uses the 4,791 coordinate entries in a saved coursework output, rather than an invented demonstration path.

What the figure establishes

The saved output demonstrates route generation and export. It is not a physical-flight recording or independent verification of shortest-path optimality, full obstacle clearance or every order-validation edge case. No new live service call or drone flight was performed to create this portfolio figure.

Link to this project ↗

Building on a compiler framework

Across three coursework repositories, I worked on parser implementation, type checking, dead-code warnings and optimisation passes. The projects used supplied compiler infrastructure, with my changes recorded in the repository history.

Semantic analysis

The implementation builds typing environments, checks assignment compatibility and traverses the program structure. A separate visitor tracks variable use to report dead-code conditions, connecting syntax with the meaning and use of program values.

Local optimisation

Pattern-rewrite passes fold integer constant expressions, apply selected algebraic simplifications and remove unused literal or binary-expression results. The dead-code pass retains division operations, illustrating why removing an unused result also requires attention to observable behaviour.

What this demonstrates

Experience reading a larger codebase, traversing syntax trees and expressing transformations over an intermediate representation. The diagram summarises the coursework stages; it is not a performance benchmark or a claim of complete language coverage.

Link to this project ↗