Building on breadboards since I was 13 taught me to enjoy getting close to the hardware. This notebook connects my lab work, coursework, and systems experience—and gives me a place to show the reasoning behind the next build.
The waveform can tell you where to look. The operating point helps explain why.
In the output stage of my discrete op-amp lab, I observed crossover distortion near the waveform’s zero crossing and adjusted the transistor bias to reduce it. Later stages added current mirrors, voltage gain, and the differential input. Building the circuit in parts helped connect each stage’s operating conditions to the behavior of the complete amplifier.
01Push-pull outputPhysical laboratory work
02Bias & current mirrorsPhysical laboratory work
03Voltage gainPhysical laboratory work
04Differential inputPhysical laboratory work
The project includes my written lab account, six lab photographs, and the photographed schematic. Original measurement data is not uploaded, so the photos support the build record without establishing numerical performance.
Move either control to see amplitude and phase change. This example supports the front-end PCB I plan to build; it is not a simulation or measurement from my op-amp lab.
RC / FREQUENCY RESPONSEIDEAL MODEL · NOT A MEASUREMENT
— Input (1 V peak)— Ideal output
Cutoff frequency1591.5 Hz
Output / input0.847 V/V
Attenuation-1.45 dB
Phase-32.1°
Fixed C = 10 nF. This ideal, unloaded RC model shows attenuation and phase lag. It does not include tolerances, amplifier limitations, source impedance, or an ADC load.
A little time at the workbench
Connect. Observe. Refine.
Explore a simple circuit, then step through one of my PCB designs.
Calculated current9.1 mACircuit closed
Breadboard learning model
One resistor makes a difference.
Switch the supply or change the series resistor. A larger resistance lowers the current through the LED.
Idealized DC example: I = (5 V − 2 V) / R. The LED has an assumed 2 V forward drop. Animation shows the current path; it is not a measurement or a wiring guide for my op-amp.
A timing assumption belongs in the specification, not in the debugging guesswork.
My digital-logic and computer-architecture coursework is the starting point for a planned UART project. Before writing the receiver, I want to make its timing assumptions explicit: clock frequency, bit period, sample positions, and accumulated timing error.
UART / BYTE EXPLORERILLUSTRATIVE 8N1 FRAME
Baud rate
115,200 baud selected
Byte 85 · Hex 0x55 · Data on the wire: 1 0 1 0 1 0 1 0 (LSB first)
Bit period8.68 µs
10-bit frame86.81 µs
50 MHz / 16× divider27
Integer-divider error+0.47%
8 data bits, no parity, one stop bit. The divider example rounds to a constant integer; it is a calculation, not a test of the planned receiver.
The low start bit, least-significant-bit-first data, and high stop bit follow the standard asynchronous format described in Microchip’s frame-format documentation. These are calculated examples; the receiver is not implemented yet.
The reader, application, and inventory record each tell part of the story.
At USPA, my work includes validating receiving, item creation, RFID encoding, and inventory workflows. One issue brought the importance of those connections into focus: after a device-side update in our RFID setup, tag capture in the USPA app became slow or stopped entirely. We needed to get the workflow moving again.
OBSERVED
Slow or missing tag capture
Tag capture in the USPA app became slow or stopped entirely.
CHANGE CONTEXT
Device and app compatibility
A device-side update introduced a compatibility issue with the USPA app.
TEAM RESPONSE
An update to the USPA app
We released an app update to restore compatibility with the reader device and get tag capture flowing again.
This is a summary of an actual work issue. Device model, update version, app-update internals, and before/after timing measurements are not documented here.
A troubleshooting framework
Find the last step you can confirm.
The checkpoints below explain how I approach this kind of workflow. They are an illustrative process, rather than a reconstructed incident log.
A question to investigate
What was received?
Record the carton or item input and the expected next step. Use a known test item to separate a repeatable failure from an ambiguous observation.
Illustrative workflow based on my confirmed responsibilities. It does not expose a production incident, customer record, or USPA’s proprietary architecture.
A useful test tells the next person how to reach the same result.
During my Vector MGT internship, I developed Python scripts for recurring data workflows, debugged backend services, and tested REST API endpoints using scripts and log analysis. That experience connects to a habit I want to carry into hardware: save enough context for a test to be repeated.
01
Input
What exact signal, request, or item begins the test?
02
Configuration
Which hardware revision, firmware, software version, and settings are in use?
03
Expectation
What should happen, and what is the pass/fail condition?
04
Observation
What actually happened? Preserve the relevant output.
05
Repeat
After the change, rerun the test and check adjacent behavior.
Reflection on confirmed internship responsibilities. This page does not include employer code, logs, or a specific confidential bug case.