Hardware Academy

Real-world scenarios

Every lesson ends with a problem that happened to someone. Read the symptoms, take the hints one at a time, then reveal the root cause and compare it with your diagnosis.

38 scenarios

Real-world scenario

Sensor board reads garbage above 125 °C

An engine-bay pressure sensor module passed every bench test and went into AEC-Q100 Grade 1 qualification (−40 to +125 °C ambient). The bridge amplifier drives a 1 MΩ series resistor and a 10 nF capacitor, a 16 Hz anti-alias filter, and a BAV99 dual switching diode clamps the filtered node to the 3.3 V and ground rails to protect the ADC input. At 25 °C the reading is accurate to 0.1%. In the thermal chamber it starts drifting above 85 °C and is useless at 125 °C.

Symptoms

  • Within 0.1% at 25 °C, about 2% high at 85 °C, and nearly 1 V (30% of full scale) off at 125 °C
  • The error is smooth and repeatable, and it disappears completely when the chamber cools; nothing is damaged
  • Swapping the pressure sensor for a precision resistor bridge does not change the drift
  • A second board built with a 10 kΩ filter resistor for a different customer drifts far less

From From atoms to energy bands · Semiconductors

Real-world scenario

Two 'identical' wafers, three times the resistance

A mixed-signal chip uses an implanted n-type resistor layer: phosphorus at 5 × 10¹³ cm⁻² and 150 keV, followed by a 1050 °C spike anneal, with a target sheet resistance of 500 Ω/□ ± 5%. A 25-wafer lot comes back from the line with 23 wafers on target and two that are wildly off. Production wants to know whether to scrap the two wafers and whether the implanter is drifting.

Symptoms

  • Four-point probe: 23 wafers read 492-508 Ω/□, while wafers 14 and 15 read about 1.5 kΩ/□, three times the target
  • The implanter log shows identical dose, energy and beam current for all 25 wafers
  • SIMS on wafer 14 shows the same phosphorus depth profile, atom for atom, as a good wafer
  • Resistors on wafers 14 and 15 are 3× too high and have a different temperature coefficient from the rest

From Doping, electrons and holes · Semiconductors

Real-world scenario

Reverse-polarity diode runs hot at 1 A

A 12 V robot controller takes power from a lead-acid battery through a 1N4007 in series with the positive lead, so a reversed battery cannot destroy the board. The board draws about 1 A on average. During a 40 °C enclosure soak for a customer, the thermal camera picks out one part far hotter than everything else, and after 500 hours the laminate under it has started to brown.

Symptoms

  • The 1N4007 body reads 110 °C on the thermal camera in a 40 °C enclosure; every other part is below 60 °C
  • A meter across the diode reads 0.95 V at 1.0 A
  • Whole-board efficiency is about 8% below what the buck regulator's datasheet predicts
  • The diode was chosen because its 1000 V rating looked 'safe'

From The p-n junction and diodes · Semiconductors

Real-world scenario

The MOSFET is 'on' but too hot to touch

A greenhouse controller uses an ESP32 to switch a 12 V, 2 A irrigation pump. The designer picked an IRF540N from the parts drawer (100 V, 33 A, 44 mΩ) and drove its gate straight from a 3.3 V GPIO. On paper the loss is 2² × 0.044 = 0.18 W, so no heatsink was fitted. Within two minutes of the pump starting, the TO-220 tab is too hot to touch.

Symptoms

  • The tab reaches about 110 °C in a 25 °C room; the datasheet math predicted a barely warm part
  • Vds measures 0.7 V with the gate high, instead of the expected 0.09 V
  • The pump runs noticeably slower than when wired straight to 12 V
  • The same board driven from a 5 V Arduino runs much cooler, and two boards built from the same reel behave differently

From Transistors: BJT and MOSFET · Semiconductors

Real-world scenario

The chip overheats after a 10% voltage bump

An edge-AI camera runs its neural accelerator at 1.0 GHz from a 0.80 V core rail. A handful of units showed rare bit errors at 85 °C, so a firmware update raised the core rail by 10%, to 0.88 V, across the whole fleet. The thermal design assumed 10 W of chip power (8 W dynamic, 2 W leakage) with 5 °C/W from junction to the 50 °C air inside a sealed enclosure: a 100 °C junction against a 105 °C throttle point.

Symptoms

  • Within ten minutes of start-up, units in sealed enclosures hit the 105 °C throttle point and the accelerator clock drops from 1.0 GHz to 700 MHz
  • The dashboard frame rate falls from 30 to about 21 fps
  • Core-rail current is up about 14% even though the workload and clock frequency are unchanged
  • Units on an open bench at 25 °C never throttle

From CMOS logic: from gates to chips · Semiconductors

Real-world scenario

Yield drops after a CMP pad change

A 300 mm fab runs a 28 nm process at a steady 92% sort yield on a 1 cm² automotive microcontroller. On Monday the copper CMP tool that polishes metal 2 gets its scheduled pad replacement. By Thursday, sort yield on lots that went through that tool has fallen to 81%, and the yield engineer on call is asked to find out why before more wafers are scrapped.

Symptoms

  • Sort yield on affected lots falls from 92% to 81%, while lots polished on the sister CMP tool stay at 92%.
  • Wafer maps show failing dies in long arcs and lines that cross die boundaries instead of random single dies.
  • Electrical failures are metal-2 shorts and opens, and inline brightfield inspection after M2 CMP shows defect counts up 4×, classified as scratches.

From How chips are made: wafer fabrication · Semiconductors

Real-world scenario

QFN pins open after reflow at a new contract manufacturer

A motor-controller board uses a 5 × 5 mm, 32-pin QFN gate driver with a 3.5 × 3.5 mm exposed thermal pad and nine thermal vias. The design moves to a new contract manufacturer with a freshly cut stencil. On the first 2,000 boards, 4% fail end-of-line test with driver faults, and two field units come back after a week of thermal cycling.

Symptoms

  • Failing boards show one or two QFN perimeter pins open; pressing on the package makes the fault disappear.
  • X-ray shows 35-50% voiding in the thermal-pad joint and the package sitting visibly tilted, with some edge joints barely wetted.
  • Boards that pass run the driver about 20 °C hotter than boards from the previous manufacturer.

From Packaging and test · Semiconductors

Real-world scenario

SiC inverter fails EMI after a drop-in device swap

A team moves a 400 V, 150 kW traction inverter from silicon IGBTs to SiC MOSFETs, keeping the existing power board, busbar and gate-driver design. The new inverter cuts losses roughly in half on the dynamometer, but the first CISPR 25 emissions pre-scan fails badly and the motor-position sensor misbehaves at high load.

Symptoms

  • Phase-node edges measure about 50 V/ns, versus about 5 V/ns with the IGBTs, with 150 V of overshoot ringing at about 60 MHz.
  • Conducted and radiated emissions exceed the CISPR 25 limit by 15-20 dB between 30 and 100 MHz, with peaks at the ringing frequency.
  • Resolver faults and CAN error frames appear only above about 200 A of phase current.

From Power semiconductors: Si, SiC and GaN · Semiconductors

Real-world scenario

Interview case: “Our part fails in the field at high temperature. What do you do?”

Final-round interview for an applications-engineer role at a power-semiconductor company. The hiring manager says: an automotive customer reports 120 ppm field failures of our 40 V gate-driver IC, all in vehicles in hot climates, and the returned parts pass test at room temperature. Walk me through what you would do.

Symptoms

  • Field returns cluster in Arizona and the Gulf states, and failures appear only when under-hood temperature exceeds about 105 °C.
  • Returned parts pass the full final test at 25 °C but show 3× the datasheet leakage on one pin when retested at 125 °C.
  • Every failing part comes from two date codes assembled at one OSAT site.

From The industry map and the jobs · Semiconductors

Real-world scenario

ADC reads 2.9 V where the multimeter says 3.3 V

A 12 V battery monitor on a robot board feeds a 12-bit ADC through a divider chosen to waste almost no current: R1 = 261 kΩ and R2 = 100 kΩ, both 1%. The node should sit at 3.32 V and the divider draws only 33 µA. On the bench a multimeter on the ADC pin reads 3.30 V, yet the firmware reports about 2.9 V, and the number shifts when another analog channel is added to the scan list.

Symptoms

  • Multimeter on the ADC pin reads 3.30 V; the firmware prints about 2.9 V, roughly 12% low.
  • The reading is correct when the same channel is sampled twice in a row, and wrong when it follows a channel at 0 V.
  • The error scales with the voltage: it is a constant fraction, not a fixed offset.

From Circuit fundamentals you actually use · PCB Design

Real-world scenario

The blink timer runs 30% faster on fresh cells

A battery-powered asset tag paces its transmissions with an RC relaxation oscillator: a Schmitt-trigger inverter, a resistor and a 100 nF capacitor, nominally a 10 ms timebase. The bill of materials said '100 nF, 6.3 V', and purchasing picked the cheapest match, a Y5V 0402. The designer could only reach 100 Hz on the bench by raising R from the calculated 100 kΩ up to about 220 kΩ, then froze the design. In the field the tags run roughly 30% faster with fresh cells and slow down as the batteries sag, and the spread between tags is wider than the resistor tolerance can explain.

Symptoms

  • Frequency differs by more than 30% between a fresh 4.2 V cell and a nearly flat 3.0 V cell, even though the Schmitt thresholds scale with the supply.
  • An LCR meter at 1 kHz with no DC bias reads the capacitor at 98 nF, in spec, yet in circuit it behaves like roughly 45 nF.
  • R had to be raised from the calculated 100 kΩ to about 220 kΩ to hit 100 Hz, which is the clue that C is not 100 nF in circuit: the period is proportional to R × C, so a capacitor of about 45 nF needs about 2.2 times the resistance.
  • Cooling a board in a freezer shifts the frequency again.

From Passives: resistors, capacitors, inductors · PCB Design

Real-world scenario

The robot reboots every two minutes and the regulator is too hot to touch

A robot controller runs from a 3S Li-ion pack that sits near 12 V. An AMS1117-3.3 in a SOT-223 turns that into 3.3 V for an ESP32 with Wi-Fi, a few sensors and status LEDs, which together average about 200 mA. The board boots and drives normally for roughly two minutes, then resets; half a minute later it boots again and the cycle repeats. The regulator burns a finger, yet the pack voltage looks perfectly healthy on the meter.

Symptoms

  • The board resets about two minutes after power-up, restarts roughly 30 seconds later, and repeats.
  • The 3V3 rail collapses to 0 V at the moment of failure while the 12 V input stays steady.
  • The SOT-223 is too hot to touch, and a thermal camera reads about 140 °C on its tab.
  • The failure arrives later in a cold room and sooner inside the closed enclosure.

From Active components: regulators, op-amps, MCUs · PCB Design

Real-world scenario

Telemetry says the pack is at 7.0 V while the meter says 7.9 V

Rev B of the motor-driver board carries the battery-monitor divider, 100 kΩ over 47 kΩ, straight into an ADC pin, and the firmware converts counts back to volts with the 147/47 ratio. On the bench a multimeter reads 7.90 V at the connector. The firmware reports 7.0 to 7.3 V, and the number jumps by 0.2 V between consecutive samples. Swapping the ESP32 module changes nothing. The 100 nF capacitor marked C9 on the drawing was left off the first build to save a part.

Symptoms

  • The reported pack voltage is 8 to 12% low, and the error grows when the firmware samples the two line sensors just before it.
  • Readings jump by about 0.2 V from sample to sample, far more than the resistors' 1% tolerance can explain.
  • Probing the divider's midpoint with a 10 MΩ multimeter shows the expected 2.53 V, steady.
  • Fitting a 100 nF capacitor from the ADC pin to ground makes the reading settle at 7.88 V.

From Components in action: one board, every law · PCB Design

Real-world scenario

The motor driver works on the bench and never moves in the field

A first batch of 20 motor-driver boards passes bench testing: both motors spin from the lab supply, the firmware ramps them smoothly and the robot drives around the lab floor. The 200 production boards that follow never move: the firmware boots, 3V3 and VM are fine, the PWM and direction pins toggle on the scope, and the motor outputs stay at high impedance. The design review was signed off, and the ERC report had 41 messages that the team dismissed as cosmetic warnings.

Symptoms

  • Every production board boots normally, but no motor ever turns and both OUT pairs read high impedance with the supply on.
  • The TB6612FNG's STBY pin measures 0 V on a production board and about 3.3 V on the bench prototypes.
  • A note taped to the prototypes reads 'STBY: temporary jumper to 3V3 for the demo'.
  • The ERC log contains 'Pin not connected (U3, STBY)' among the 41 dismissed messages.

From Schematic capture: drawing a circuit people can read · PCB Design

Real-world scenario

The board browns under the motor driver

A 2-layer, 1 oz motor-driver board runs fine in light testing. At the first stall test, with both motors drawing about 3 A, the robot smells of hot varnish within a minute and the laminate under the driver turns brown. The motors also lose torque: the battery connector reads 7.2 V while the driver's VM pins read 6.8 V. The layout shows that the feed to the driver is a 10 mil (0.25 mm) trace, 50 mm long, because the autorouter treated it like any other net.

Symptoms

  • A burnt-varnish smell and visibly brown laminate along the trace to the VM pins after a minute at 3 A.
  • About 0.4 V is lost between the battery connector and the driver at 3 A, and the motors stall at lower torque than the datasheet promises.
  • A thermal camera shows the trace at about 185 °C while the driver chip is only warm.
  • The board passes ERC and DRC with no messages.

From PCB layout and stack-up · PCB Design

Real-world scenario

Robot resets whenever the motors start

The first spin of the motor-driver board runs the ESP32 happily on the bench with the wheels off the ground. Put the robot on the floor and command both motors from standstill, and the ESP32 reboots about one start in three; the serial console prints Brownout detector was triggered. The pack is a partly discharged 2S Li-ion (7.0 V), connected through 20 cm of lead wire. Rev A of the board has only a 100 nF capacitor at the TB6612FNG VM pins and one thin ground trace shared by the driver, the regulator and the module.

Symptoms

  • Resets only when both motors start from standstill under load; spinning freely never resets
  • Serial log shows Brownout detector was triggered, followed by a normal boot
  • A scope on 3V3 at the module shows a dip of about 700 mV lasting 40 µs, starting exactly when the motor PWM turns on
  • Between the battery negative terminal and the module GND pin, a second probe shows spikes of about 0.9 V on the PWM edges

From Power integrity, signal integrity and EMI · PCB Design

Real-world scenario

Half the 0402s tombstone

A 40-board run comes back from a low-cost assembler with about half of the 60 0402 capacitors and LEDs on every board, 28 to 32 of them, standing on one end after reflow. The failures are not random: each tombstoned part has one pad tied to a large ground pour with a solid connection and the other pad on a 0.2 mm trace. Parts with matching copper on both pads are fine, and so are the 0603 and larger parts. The assembler's profile log shows a preheat ramp of 3.5 °C/s.

Symptoms

  • 28 to 32 of the 60 0402 parts on each board stand on one end; 0603 and larger parts are fine
  • Every failed part has one pad on the ground pour and the other on a thin 0.2 mm trace
  • The end that is lifted off the board is always the one on the ground pour
  • The reflow log shows a preheat ramp of 3.5 °C/s with almost no soak

From DFM and how boards get made · PCB Design

Real-world scenario

New board draws 800 mA at idle

The first assembled motor-driver board arrives. The expected idle current is 60 to 80 mA. The bench supply is set to 7.4 V with its limit left at 0.8 A from an earlier job; the display shows 0.80 A and the voltage has collapsed to about 1.9 V, constant-current mode. The 3V3 rail reads 0.6 V instead of 3.3 V, and there is a faint smell near the regulator.

Symptoms

  • The supply is pinned at its 0.8 A limit and the output voltage has collapsed to about 1.9 V
  • The 3V3 rail reads 0.6 V; with power off, 3V3 to GND measures about 0.5 Ω
  • The AMS1117 is warm but not hot, and a faint smell comes from beside it
  • Replacing the regulator with a known-good one changes nothing

From Board bring-up and debugging · PCB Design

Real-world scenario

DRC passes but the board does not fit the chassis

The motor-driver board passes KiCad DRC with zero errors and the fab's DFM check, and five boards arrive. In the 3D-printed chassis two of the four M3 holes miss their standoffs by 1.5 mm, the JST motor connectors hit the rear wall, and the 5.4 mm tall bulk capacitor collides with the battery tray lid. The chassis designer had emailed a DXF with the pocket outline and the standoff positions weeks earlier.

Symptoms

  • Zero DRC errors and zero DFM warnings on the order page
  • Two of the four M3 holes sit 1.5 mm away from the chassis standoffs
  • J2 and J3 touch the rear wall when the board is lowered in
  • The 100 µF capacitor, 5.4 mm tall, hits the battery tray lid

From Practical: design the robot's motor-driver board in KiCad · PCB Design

Real-world scenario

Line follower drives straight through its stop line at speed

A team's line-following robot stops cleanly on a 19 mm strip of black electrical tape at 0.2 m/s. For the competition they raise cruise speed to 0.6 m/s and add an HC-SR04 read with pulseIn() inside loop() so the robot also stops for obstacles. On the practice track it now sails past the stop line on about half the runs, and when it does stop it ends up 6-10 cm beyond the tape.

Symptoms

  • At 0.2 m/s the robot stops on the tape every time; at 0.6 m/s it misses the line on roughly half the runs.
  • When it does stop, it ends 60-100 mm past the tape instead of on it.
  • A loop-timing printout shows the period jumping between 10 ms and about 48 ms; the long cycles happen when nothing is in front of the ultrasonic sensor.
  • Commenting out the ultrasonic read makes the misses disappear, even at 0.6 m/s.

From Anatomy of a robot · Robotics

Real-world scenario

Robot drives into angled walls its ultrasonic sensor never reported

An obstacle-avoiding robot uses one forward-facing HC-SR04 and turns away whenever the reading drops below 25 cm. In square-on bench tests it never touches a wall. During a hallway demo it drives straight into walls it meets at a shallow angle, and into a fabric-covered partition. Early in the project the team made the firmware convert a pulseIn() timeout, which returns 0, into 400 cm, because zeros were causing spurious stops in open rooms.

Symptoms

  • Square-on walls are detected reliably from a few centimetres to beyond 2 m.
  • Walls met roughly 30-45° off square are never reported; the log shows 0 (converted to 400 cm) for the last second before every impact.
  • The fabric-covered partition gives readings that jump between a plausible 40-60 cm and 0.
  • A second HC-SR04 angled 30° outward and fired at the same moment as the first made the readings noisier, not better.

From Sensors · Robotics

Real-world scenario

ESP32 resets every time the robot reverses

A robot's ESP32 and TB6612FNG share a 2S Li-ion pack: the driver's motor supply comes straight from the pack and the ESP32 runs from a small 5 V buck converter. The obstacle-avoidance code flips both motors from full forward to full reverse in one step when it sees a wall. About one reversal in three, the robot freezes for half a second and the serial monitor prints a reboot banner.

Symptoms

  • The serial log shows 'Brownout detector was triggered' followed by the ESP32 boot banner, only right after a reversal command.
  • Gentle speed changes never cause a reset, and the problem gets worse as the battery runs down.
  • A scope on the 5 V rail shows a dip to about 3.3 V lasting roughly 2 ms at each reversal, plus ringing spikes on the motor supply.
  • Unplugging one motor makes the resets rare.

From Actuators and motor drivers · Robotics

Real-world scenario

The IMU stops answering until the robot is power-cycled

A robot reads an MPU-6050 IMU at address 0x68 over I2C at 400 kHz, through 30 cm of ribbon cable to the ESP32. When a second sensor was added, the breakout's pull-up resistors were removed, so the bus now relies on the ESP32's internal pull-ups. On the bench it runs for hours. On the robot, after a few minutes of driving or right after an ESP32 brownout reset, every IMU read fails and only unplugging the battery brings it back.

Symptoms

  • Wire.endTransmission() returns 2 (NACK on address) or reads time out, and the accelerometer and gyro values freeze.
  • A scope shows SDA held low continuously while SCL idles high.
  • Before the lockups, the scope shows slow, rounded rising edges on SDA and SCL that take about 4 µs to reach the high level.
  • Dropping the bus to 100 kHz makes failures rarer but does not stop the lockups after resets.

From Microcontrollers and firmware · Robotics

Real-world scenario

Heading hold weaves ±10° down the hallway

A robot holds its heading with a P controller on a gyro-integrated yaw angle: wheel speed difference = Kp × heading error. To fix a slow drift, the team doubled Kp. They had also set the MPU-6050's digital low-pass filter to its 5 Hz setting to quiet motor vibration, and the heading controller runs in the 20 Hz behavior loop rather than the 100 Hz control loop. Now the robot weaves left and right about ±10° as it drives straight.

Symptoms

  • The weave has a steady period of about 0.7 s and does not die out.
  • Halving Kp stops the weaving but brings back the slow drift.
  • The weave gets worse at higher drive speeds and after the low-pass filter was set to 5 Hz.
  • A log of heading error and commanded turn rate shows the command peaking well after the error peaks.

From Control systems and PID · Robotics

Real-world scenario

Odometry is off by 1 m after one lap

A lab's indoor delivery robot (65 mm wheels, 2048-count encoders, 280 mm wheel base from CAD) drives a 24 m rectangular loop (8 m × 4 m) through the corridor using pure odometry between two charging docks. Clockwise laps end with the robot about 1 m from the dock even though its pose estimate says it is exactly on the marker, so the docking routine times out. The team has already swapped both encoders and rewritten the odometry code twice.

Symptoms

  • Commanding equal encoder counts for 8 m ends about 14 cm to the left of a tape line on the floor
  • Each commanded 90° turn measures about 88° with a protractor on the floor
  • Clockwise laps miss the dock by about 1 m, counter-clockwise laps by less than 10 cm
  • New encoders and a code rewrite left the error unchanged and repeatable from lap to lap

From Kinematics and motion · Robotics

Real-world scenario

The robot circles forever in the corner of the test pen

A student team's exploration robot (three HC-SR04 rangers at −45°, 0° and +45°, reactive steering that blends goal-seeking with obstacle avoidance) must cross a 3 m × 3 m pen and reach a charging beacon behind a low L-shaped wall. In 4 of 10 runs it drives into the inside corner of the L and stays there, sweeping left and right, until the battery runs flat.

Symptoms

  • Telemetry shows the turn command flipping sign about every 1.2 s while the front range bounces between 18 cm and 35 cm
  • The pose trace draws the same small figure-eight in the corner over and over
  • Moving the beacon 30 cm to the side makes the problem vanish for that layout
  • Lowering the steering gains only makes the oscillation slower

From Perception and navigation · Robotics

Real-world scenario

Works on USB, resets on battery

A student finishes the course robot. On the bench, with the ESP32 powered from the laptop's USB port and the pack switched on for the motors, it avoids boxes for half an hour while streaming telemetry over Wi-Fi. For the first real run they move the 5 V jumper so the buck powers the ESP32, unplug USB and put the robot on the floor. It drives for a second or two, stops, and starts its boot sequence again, over and over.

Symptoms

  • After each reboot the firmware logs esp_reset_reason() = ESP_RST_BROWNOUT
  • On USB power the same firmware runs for 30 minutes without a single reset
  • A scope on the 5 V rail shows dips to about 3.9 V lasting 2 ms each time both motors start
  • Resets get more frequent as the pack discharges and almost stop when Wi-Fi telemetry is turned off

From Build your smart robot · Robotics

Real-world scenario

Perfect in simulation, crashes on the real floor

A team's wall-following controller passed 200 out of 200 runs in their simulator at 40 cm/s with a 15 cm front threshold. On the real robot, in the office hallway, it clips the wall at about one corner in three and has twice driven into the base of a whiteboard stand.

Symptoms

  • The real robot starts its corner turn 6 to 9 cm later than the simulated robot does
  • Logs show the front range updating only every 60 ms, with occasional 400 cm readings next to a wall angled at 45°
  • At 20 cm/s the real robot almost never touches a wall
  • The thin metal legs of the whiteboard stand are invisible to it until it is too late

From Simulate before you build · Robotics

Real-world scenario

The publisher works, the subscriber never hears it

A new team member writes a C++ node that subscribes to /camera/image_raw to count people in the hallway. The camera driver is clearly running: ros2 topic hz reports 30 Hz and RViz shows the live image. The new node builds, starts, logs that it has subscribed, and then its callback never fires, not once, for an entire afternoon of debugging.

Symptoms

  • ros2 topic list shows /camera/image_raw and ros2 topic hz reports 30 Hz
  • RViz and ros2 topic echo display the images normally
  • The new node's callback counter stays at zero, with no errors and no crashes
  • A single warning at startup says a new publisher on /camera/image_raw is offering incompatible QoS and that no messages will be received from it

From ROS 2 and the robotics stack · Robotics

Real-world scenario

Regen vanishes on a −15 °C morning

A parcel fleet in Minneapolis runs 40 single-motor vans with 75 kWh, 400 V packs. They sleep outdoors at −15 °C and are charged to 100% overnight. On cold mornings drivers say one-pedal driving does almost nothing for the first 20-30 minutes, and they have to brake hard at the first stop sign. Two drivers have filed brake-fault tickets. By the afternoon the same vans regenerate normally.

Symptoms

  • The power meter shows regen capped at about 5 kW instead of the usual 60-80 kW, with a 'regenerative braking limited' message.
  • Full regen returns gradually over 20-40 minutes of driving, or right away if the van was preconditioned while still plugged in.
  • A van that leaves the depot at 100% state of charge shows the same cap on a warm September day.
  • Motor and inverter diagnostics are clean, and drive torque on the same cold morning is only mildly reduced.

From EV powertrain architecture · EV Powertrain

Real-world scenario

Track day leaves a PM motor 8% weaker

A customer takes a rear-drive performance EV with an interior-PM motor to a track day: six back-to-back hot laps on a 32 °C afternoon. The drive unit never logged a fault. Back on the road the car feels flat. At the service visit, a timed run shows 0-100 km/h has slipped from 4.4 s to 4.8 s, and the inverter's torque estimate no longer matches the measured axle torque.

Symptoms

  • At the same q-axis current, measured torque is about 8% below the delivery value, and it does not recover after a night of cooling.
  • A coast-down test with the inverter off shows lower back-EMF: open-circuit line voltage at 6,000 rpm has dropped from 250 V to 230 V.
  • The stator winding thermistors peaked at 140 °C, well inside the 180 °C insulation rating, so no derate was ever triggered.
  • The loss is the same at every speed, not only near top speed.

From Three-phase motors · EV Powertrain

Real-world scenario

Inverter trips on overcurrent, but only at launch

A prototype rear-drive EV passes its highway testing, but on full-throttle launches from standstill the inverter trips with a phase-overcurrent fault about one launch in three, and the car coasts to a stop. The controller measures phases A and B with open-loop Hall-effect sensors and computes C as −(A + B). A third sensor on phase C feeds only a fast hardware comparator set to 650 A. The inverter's current limit is 620 A peak, and the 400 V pack can deliver at most 150 kW.

Symptoms

  • Trips happen only in the first second of a hard launch, below about 10 km/h, and never at highway speed, even at the full 150 kW.
  • Logged Id and Iq track their references cleanly right up to the trip.
  • At crawl speed the car shudders once per electrical revolution.
  • With the motor at standstill and zero torque commanded, the A and B readings sit at zero while the phase-C sensor reads about 40 A, so the three readings no longer sum to zero.

From Inverters, PWM and field-oriented control · EV Powertrain

Real-world scenario

Module 7 balances every night

A last-mile delivery fleet runs 40 identical electric vans. Each 96s pack is built from 16 modules, and each module has its own monitor board that balances its six series groups toward the lowest one. The fleet dashboard flags van 23: module 7's balancing resistors run six to eight hours every night, while every other module in the fleet balances for a few minutes a week. The van's usable range has dropped about 6 % in three months.

Symptoms

  • Module 7's board logs hours of bleeding on groups 1-3 and 5-6 every night; group 4 is never bled.
  • With balancing disabled for a 48-hour park, group 4 falls about 4 mV below its neighbours; every other group in the pack stays within 1 mV.
  • Discharge ends when module 7 reaches the low-voltage limit, while the other modules still hold about 5 % charge.
  • Module 7's board runs about 6 °C warmer than the others overnight. Cell temperatures and charging currents look normal.

From Batteries and the BMS · EV Powertrain

Real-world scenario

Design review: the front motor that cost 4 % of highway range

An EV startup is reviewing its dual-motor crossover before design freeze. To share parts, the team fitted the same 150 kW interior permanent magnet motor to both axles. The rear motor drives the car while cruising; the front motor is commanded to zero torque and only joins in for hard acceleration, low grip or towing. Prototype range at a steady 70 mph comes in 4 % below target, and the drive-unit team has to explain why.

Symptoms

  • Coast-down tests show about 600 W more drag at 70 mph than the rear-drive prototype, and the gap grows faster than linearly with speed.
  • The front inverter draws current at high speed even when the front torque command is zero.
  • The front stator warms up on long highway runs although the motor produces no torque.
  • City-speed range is within 1 % of target; almost all of the shortfall is at highway speed.

From Tesla Roadster and motor evolution · EV Powertrain

Real-world scenario

Afternoon sessions stuck at 50 kW

A highway site in California's Central Valley has four 150 kW dispensers with liquid-cooled cables, sharing power cabinets under a load-management cap that is rarely reached. In July, drivers start complaining: morning sessions run at 130-150 kW, but between 1 pm and 6 pm the same cars charge at about 50 kW. The load manager shows plenty of headroom and the utility reports no voltage problems.

Symptoms

  • Afternoon sessions on all four dispensers settle near 50 kW (about 125 A into a 400 V pack) within a few minutes of starting.
  • An 800 V car on the same dispenser in the afternoon gets about 100 kW, which is the same 125 A, not the same power.
  • OCPP MeterValues show the Temperature measurand at location Cable climbing to its configured limit just before each current drop; cabinet module temperatures stay normal.
  • Afternoon ambient is 41-44 °C and the dispensers face west in full sun.

From EV charging systems · EV Powertrain

Real-world scenario

The fillet fails after someone enlarges a hole

A team keeps a parametric aluminium L-bracket in a feature-tree CAD system. The tree reads: Sketch (70 × 44 mm L-profile, 6 mm thick), Extrude 40 mm, Hole 8.5 mm through the base, Hole 8.5 mm through the flange, then Fillet R12 on the inside bend, whose edge was picked by clicking it in the viewport. Procurement swaps the M8 anchor for an M10, so a junior engineer changes one number on the flange hole: 8.5 mm becomes 12 mm. The model turns red and the drawing package for the supplier cannot be released.

Symptoms

  • Rebuild stops at the Fillet feature with BRep_API: command not done, and everything after it is suppressed
  • Setting the hole back to 8.5 mm makes the error disappear, so the hole edit looks innocent
  • Opening the same file in an older release attaches the fillet to a different edge, and a rounded edge appears that nobody designed

From CAD kernels and parametric design · AI-Assisted Design

Real-world scenario

The bracket passes every DFM check and cannot be assembled

A design agent generates the fan-motor bracket for a heat-pump outdoor unit. The compile-time checker reports 41 rules and zero violations: 3 mm aluminium, two R6 bends, M6 clearance holes 12 mm from the edge, wall and flange rules satisfied. Fifty brackets are cut and bent. On the line, the first unit stalls: two of the four M6 screws that fix the bracket to the coil end plate sit behind the coil, and a socket with extension needs 40 mm of straight access on the screw axis while only 12 mm is free. The operators remove the coil, fit the bracket and refit the coil, adding about 20 minutes per unit.

Symptoms

  • DFM report: 41 rules checked, 0 violations, 0 warnings
  • Two of the four M6 screws cannot be reached with a socket and extension because the coil blocks the screw axis
  • Operators must remove and refit the coil to install the bracket, adding about 20 minutes per unit

From AI agents for hardware design · AI-Assisted Design

Real-world scenario

Claude keeps designing 0.5 mm walls

A startup lets Claude Desktop design lightweight brackets through its CAD MCP server. The engineer's rule, nothing thinner than 1.5 mm for 6061 on the shop's mill, lives in the project prompt. Three times in a row Claude returns a bracket with a 0.5 mm web, exports STEP and describes the part as optimised for weight. The quote request bounces: the shop cannot hold flatness on a 0.5 mm web and the part chatters under the cutter.

Symptoms

  • export_step succeeds every time and returns a path, so nothing in the chat looks wrong
  • The same 0.5 mm value shows up in three separate conversations, even after the engineer repeats the rule in chat
  • dfm_check exists, but Claude only calls it when asked, and the one time it ran it reported pass

From Build a Claude CAD tool with MCP · AI-Assisted Design