← Back to Projects
HardwareShipped

PER Power Electronics Design Challenge

Designed and analyzed a sensor-monitoring circuit and evaluated buck-converter architectures for an automotive electrical environment.

Independent engineering work for Penn Electric Racing's recruitment process—not PER vehicle hardware. Brake and current thresholds feed comparator and logic stages that drive an indicator under a response-time requirement, while a buck stage is judged on efficiency, headroom, ripple, EMI, and packaging instead of 'outputs 5 V' alone.

Engineering highlights

  • Sensor-threshold monitor with concurrent logic and indicator timing
  • Buck selection framed around efficiency, ripple, EMI, and load headroom
  • Requirement check after an initial response-time misread
Date
Fall 2026
Focus
Power Electronics · Design Challenge
Build stage
Recruitment design challenge
Disciplines
Power Electronics · Circuit Design · Engineering Design Challenge
Power ElectronicsCircuit DesignComparatorsBuck ConvertersEMICircuitLabPERDesign Challenge
Build snapshot
PER Power Electronics Design Challenge media 1
Full write-up below. The hero is the short version. This is the build story: what I designed, what broke, and why I made the calls I did.

Motivation

Why I started this

What pulled me in, and what I wanted to get better at.

Why I built it

I wanted to prove I could turn a written electrical requirement into a circuit that monitors sensor thresholds, makes a logic decision, and drives an indicator under real timing and automotive supply constraints.

What interested me

The interesting part was not drawing a schematic. It was deciding how threshold detection, logic, timing, and a 5 V rail from a noisy ~12 V vehicle supply should fit together without inventing convenience that the environment will punish.

What I wanted to learn

I wanted a harder look at buck-converter selection: efficiency, headroom, ripple, EMI, and board area as a system, not as a single 'outputs 5 V' checkbox.

System Overview

How the system fits together

Independent engineering work for Penn Electric Racing's recruitment process. The circuit watches brake and current sensor conditions, decides when those conditions are satisfied together, and activates an indicator within a required response window. Power comes from an automotive-style 12 V domain that must be regulated for the sensing and logic stages.

01

Power regulation

Steps the vehicle supply into a clean enough low-voltage rail for references, comparators, and logic.

02

Sensor inputs

Bring brake and current sensing into the threshold stage with usable reference levels.

03

Threshold detection

Comparators answer whether each sensor has crossed its required level.

04

Logic + timing

Combine conditions and shape the response so the indicator meets the timing requirement.

05

Indicator

Make the decision visible without loading the decision node incorrectly.

Data flow

12 V supply → regulation → sensor/reference network → comparators → logic → timing → indicator.

Control flow

Analog thresholds become digital decisions; the timing network enforces response behavior before the LED stage.

Design Challenge Deep Dive

Independent engineering work completed as part of Penn Electric Racing's recruitment process. Not hardware designed for or used on the PER car.

Signal / power path

0112 V Supply
02Power Regulation
03Sensor Inputs
04Threshold Detection
05Logic
06Timing / Response
07Indicator

Why each block exists

Each stage answers one question. If a block cannot justify itself, it should not be on the board.

Comparator 1

Has the brake signal crossed its required threshold?

Turns an analog brake condition into a clear decision edge for the logic stage.

Comparator 2

Has the current signal crossed its required threshold?

Same idea for current sensing so both conditions share a comparable decision language.

Logic

Are the required conditions simultaneously true?

Prevents an indicator trip on a single sensor event when concurrency is required.

Timing

Does the circuit satisfy the required response behavior?

Shapes how quickly the decision becomes a visible indicator event.

Power regulation

Is the low-voltage rail honest under automotive supply and load?

Keeps references and logic alive without dumping switching pain into the sensing path.

Indicator

Can a human see the decision without loading the circuit badly?

Closes the loop from requirement to observable behavior.

Schematic

Schematic placeholder
Placeholder for CircuitLab schematic

TODO: replace with CircuitLab schematic export (schematic.png) in this folder.

Datasheet comparison

LM5164 vs LMR33630

Exact numbers left as placeholders until datasheet values are filled in.

Efficiency

Less energy wasted as heat in a packed enclosure.

LM5164

TODO

LMR33630

TODO

Output-current capability / headroom

Provides margin when MCU, sensors, or CAN circuitry create transient loads.

LM5164

TODO

LMR33630

TODO

Transient response

Determines how well the 5 V rail stays regulated when load current suddenly changes.

LM5164

TODO

LMR33630

TODO

Output-voltage ripple

Excessive supply noise can affect sensitive analog measurements.

LM5164

TODO

LMR33630

TODO

EMI behavior

Fast switching edges can inject noise into nearby sensor and communication circuitry.

LM5164

TODO

LMR33630

TODO

PCB footprint

Matters in tightly packaged automotive electronics.

LM5164

TODO

LMR33630

TODO

Thermal behavior

Heat that has nowhere to go becomes a reliability and layout problem.

LM5164

TODO

LMR33630

TODO

Understanding EMI

~ ~ ~

Radiated EMI

Buck converter
↓
Nearby analog / CAN
↓
5 V rail → sensor / MCU

Conducted noise on the supply path

Conducted noise

Switching disturbances travel through PCB traces, supply rails, or ground and show up as rail bounce or reference noise.

Radiated noise

Fast-changing currents and voltages create electromagnetic fields that can couple into nearby circuitry without a shared conductor.

On a sensor / data-acquisition board near electrically noisy drivetrain hardware, both paths matter. A quiet schematic can still become a noisy measurement if the buck stage is treated as isolated from the analog neighborhood.

Verification

Verification is where the design meets the written requirement. Waveform first; numbers only when measured.

CircuitLab transient
CircuitLab transient analysis for response timing

Primary simulation evidence from the challenge submission.

Indicator responds within the allowed response window

Mechanism: Comparator + logic + timing network

Method: CircuitLab transient analysis

TODO · result

Both sensor conditions required before indication

Mechanism: Concurrent logic on comparator outputs

Method: Functional simulation / schematic review

TODO · result

5 V rail suitable for sensing/logic under automotive input

Mechanism: Buck regulation stage

Method: Datasheet comparison + (TODO) rail simulation

TODO · result

What changed after checking the requirement

Engineering was iterative. The circuit could function and still be wrong relative to the written response-time requirement.

  1. 1

    Initial interpretation

    Treated 0.5 s more like a minimum delay aesthetic than a maximum allowable response.

  2. 2

    Simulation

    Captured transient behavior for the indicator path.

  3. 3

    Compare against the written requirement

    Re-read the response-time wording as a bound the design must stay inside.

  4. 4

    Identify the mismatch

    A 'working' delay story can still fail a maximum-response requirement.

  5. 5

    Revise understanding / design

    Updated the timing interpretation so verification targets the real constraint.

Engineering Breakdown

Broken down by discipline

Each block covers the goal, the design, what broke, what changed, and what shipped.

01Sensing & Decision Logic

Sensing & Decision Logic

Goal

Detect when brake and current conditions are simultaneously satisfied and drive an indicator.

Design

Comparator stages for each threshold, logic that requires the concurrent condition, and a timing network that sets response behavior.

Challenges

  • Reference and hysteresis choices change how noisy sensor edges look at the comparator.
  • Response timing is a requirement, not a cosmetic RC preference.

Iterations

  • First-pass threshold network.
  • Logic combination of both conditions.
  • Timing revised after checking the written response requirement.

Final implementation

Comparator + logic + timing path aimed at concurrent detection and bounded indicator response.

02Power Regulation

Power Regulation

Goal

Generate a usable 5 V rail from an automotive ~12–17 V domain without treating the converter as a black box.

Design

Compared candidate buck architectures (LM5164 vs LMR33630 class parts) against efficiency, current headroom, transient behavior, ripple, EMI, footprint, and thermal story.

Challenges

  • A part that 'makes 5 V' can still fail the rest of the board through noise or weak transient response.
  • EMI couples into sensor and communication circuitry that lives next to the power stage.

Iterations

  • List of metrics that matter for this PCB.
  • Side-by-side datasheet reading (values still being filled in on the page).
  • EMI framing for conducted vs radiated noise.

Final implementation

Documented selection criteria and comparison scaffold for the buck stage.

Key Design Decisions

Calls I actually made

What else was on the table, what I picked, and why it still made sense once the hardware was real.

01

Treat the buck as a system, not a voltage label

The problem

Generating 5 V from ~12–17 V looks simple until load steps, ripple, EMI, and packaging show up.

Alternatives considered

  • Pick the first 5 V regulator that fits the pinout
  • Compare candidates against efficiency, headroom, transient, ripple, EMI, footprint, thermal

Tradeoffs

A tiny or cheap part can still heat the board, ring the rail, or couple noise into analog paths.

Why I chose this

Score candidates on system metrics first. Exact datasheet numbers remain TODO placeholders until filled from the sheets.

02

Response time is a max, not a delay aesthetic

The problem

An RC timing network can satisfy 'the circuit waits' while still violating a maximum allowable response.

Alternatives considered

  • Treat 0.5 s as a minimum delay
  • Treat 0.5 s as a maximum allowable response and size timing accordingly

Tradeoffs

Misreading the written requirement produces a working waveform that fails the spec.

Why I chose this

Re-check simulation against the requirement text, then revise the timing interpretation.

Evolution

How it got here

Bench bring-up, CAD fits, soldering, and the demos in between. Not just the final photo.

  1. Draft

    Threshold path on the page

    Built the sensing → compare → logic → indicate story before locking the power stage.

    No media for this milestone yet.

  2. Simulate

    Transient check

    Ran CircuitLab transient analysis to see indicator timing against the intended behavior.

    No media for this milestone yet.

  3. Correct

    Requirement mismatch

    Caught that the response-time wording was a maximum, not a minimum delay, and revised understanding/design.

    No media for this milestone yet.

Results & Validation

What held up

What worked in the end, what I can show for it, and where it's still limited.

Transient simulation captured

Transient waveform

CircuitLab transient analysis is on the page as primary verification evidence for response behavior.

Measured response time

TODO · measured response

Exact measured value still needs to be filled from the simulation readout.

Requirement check

TODO · pass/fail

Pass/fail against the written response requirement is left as an explicit TODO so the page never invents a result.

Photos and clips

The runs and stills that match the results above.

Transient analysis
CircuitLab transient analysis waveform for the PER sensor-monitor circuit

CircuitLab transient analysis from the submission package. Read timing from the plot; do not invent numbers here.

Limitations

  • Datasheet comparison cells are placeholders until exact LM5164 / LMR33630 numbers are entered.
  • CircuitLab schematic export still needs to replace the schematic placeholder asset.
  • Pass/fail interpretation of response time is intentionally unmarked until you confirm the readout.

Reflection

Looking back

What surprised me, what I'd redo, and questions I'm still chewing on.

What surprised me

  • Power regulation stopped being 'does it output 5 V?' and became a system question about heat, ripple, EMI, and load steps.
  • A circuit can look correct in simulation while still failing a written timing requirement if the requirement is misread.

What I would redesign

  • Fill datasheet metric cells with the real comparison numbers.
  • Swap the schematic placeholder for the CircuitLab export.
  • Record measured response time and pass/fail next to the waveform.

Future improvements

  • Bring the same datasheet-driven buck review into other automotive / drivetrain boards.
  • Practice writing verification tables before schematic polish.

Questions that emerged

  • How much EMI margin is enough for sensor and CAN neighbors on a denser PCB?
  • Which transient cases should be mandatory before locking a buck choice?