Engineering between firmware, electronics, and motion.
I’m an Electrical Engineering student at Texas Tech University focused on embedded systems, hands-on hardware, and electromechanical control. My work spans microcontrollers, sensors, motors, PCB-level debugging, real-time firmware, and digital logic. I like engineering at the boundary between hardware and software: instrument the system, find what fails, change the design, and validate the result.
Hands-on Experience
Built, tested, and debugged real embedded hardware.
Industry and research experience focused on board bring-up, firmware–hardware integration, sensors, actuators, and structured root-cause debugging.
IndustryMay 2025 – Aug 2025
Research & Innovation Intern — Embedded Systems
Walton Hi-Tech Industries PLC
Tested and brought up embedded control boards for consumer appliances, including sensor feedback, relay and motor operation, UART/SPI communication, and firmware response.
Diagnosed 20+ board-level hardware and firmware issues using embedded C/C++, serial debugging, an oscilloscope, and a multimeter.
Documented test results, failure symptoms, and root causes so engineers could reproduce problems and improve control-board reliability.
ResearchAug 2025 – Mar 2026
Undergraduate Research Scholar — Embedded Systems
Texas Tech University
Developed C/C++ firmware for autonomous robotic systems using real-time inputs from multiple sensor types.
Designed and iterated low-power robotic prototypes integrating sensors, actuators, and embedded circuits.
Calibrated sensor inputs, debugged firmware, and tested actuator responses to improve real-time control reliability.
Skills
Tools and fundamentals I use to build and debug systems.
Embedded / Real-Time
C/C++embedded CSTM32 / ARM Cortex-MFreeRTOSbare-metal programmingArduinoSPIUARTI²Cinterruptssensor integrationmotor / actuator control
Make the system observable, then make it reliable.
01
Build the full loop
I like projects where firmware has to interact with real sensors, power electronics, motors, displays, or communication hardware—not just compile in isolation.
02
Instrument before guessing
I use UART logs, oscilloscopes, logic analyzers, multimeters, and structured test steps to make failures visible and narrow down root causes.
03
Iterate from evidence
Calibration, timing changes, state-machine revisions, and hardware checks are driven by observed behavior, then re-tested until the system is more reliable.
Contact
Let’s build something that has to work in the real world.
