I have been circling this problem for years. If you look through my ANTSHIV ROBOTICS YouTube channel, there are older videos where I talk through MOSFET internals, MOSFET datasheets, BLDC speed controllers, NXP motor-control boards, pre-drivers, switching losses, gate charge, the Miller plateau, and why a drone ESC is not just a magic box that spins a motor. Two useful references from that older work are my MOSFET characteristics video and this longer BLDC / MOSFET lab discussion.

Those videos were not random. They were me trying to understand the layer that most drone tutorials skip. A lot of people buy an off-the-shelf ESC, connect a motor, and move on. That is fine if the goal is only to fly. My goal is different. I want to build a drone stack for ecological monitoring that I can understand, repair, instrument, and improve. For that, the ESC is not an accessory. It is part of the product.

The problem is that this layer is tedious. A MOSFET can look overpowered on paper and still die instantly on a real motor. A reference board can work with the vendor's motor and still fail with my quadcopter motor. A SPICE plot can look clean while the real layout has source bounce, gate ringing, or drain-source overshoot. I have bought development boards, run demos, fabricated boards, blown MOSFETs, and stopped for long stretches because the work was too scattered.

This post is about changing that. The new goal is not to design a full ESC in one jump. The new goal is to build a pipeline where every layer becomes measurable.

The Old Way Was Too Scattered

My old process was something like this:

That is not a failure of effort. It is a failure of loop design. The work did not leave enough structured evidence behind. When a board blew up, there were too many possible causes:

So the new rule is simple: do not debug the whole ESC first. Debug one MOSFET under a controlled load.

The New Pipeline

The pipeline I am building now is this:

This is the same kind of thinking I use in software and AI projects. Do not hide the system behind a giant abstraction too early. Find the primitives. Define the measurement contract. Automate the boring parts. Then harden the loop.

The same pipeline is now represented as a Graphviz artifact so the process itself is not only prose:

The First Board Is Not An ESC

The first serious artifact is a MOSFET DUT: device under test. It is a board that lets me test one MOSFET as a low-side switch.

The current path is simple:

VIN -> load -> drain -> MOSFET -> source -> shunt -> ground

The measurement contract is the important part:

VGS = gate Kelvin - source Kelvin
VDS = drain Kelvin - source Kelvin
ID  = shunt voltage / shunt resistance
RDS(on) = VDS / ID
P(t) = VDS(t) * ID(t)

If I cannot measure those cleanly on one MOSFET, I have no business pretending I understand a four-motor ESC.

This is the waveform shape I want the pipeline to explain. The exact values will change with the MOSFET, gate driver, motor/load, PCB layout, and probe setup. The structure is the important part: VGS rises, the Miller plateau appears, VDS falls, current rises, and the power spike tells me where heat and margin are being spent.

This is the first generated visual contract for the low-side DUT:

The point is not that the drawing is beautiful. The point is that it forces the structure to be explicit:

Why Vishay AN957 Matters

I am basing the characterization philosophy partly on Vishay Siliconix AN957, Measuring Power MOSFET Characteristics. That paper is old-school and curve-tracer oriented, but it is valuable because it separates MOSFET measurements into concrete parameters:

• BVDSS: drain-source breakdown voltage.
• IDSS: drain-source leakage with the gate off.
• VGS(th): threshold voltage.
• IGSS: gate leakage.
• RDS(on): on-resistance.
• VSD: body-diode forward voltage.
• capacitance, gate charge, switching time, and reverse-recovery behavior.

One important thing AN957 reinforces is that RDS(on) should be measured with a pulse. If the MOSFET heats up during the measurement, the resistance changes, and the result becomes contaminated. The equation is simple:

RDS(on) = VDS / ID

The hard part is not the equation. The hard part is making sure VDS and ID are real measurements and not polluted by copper, connector, probe, or layout artifacts.

Why NXP Reference Designs Matter

I am also not randomly selecting MOSFETs. I am constraining the candidate set to parts that show up in NXP motor-control reference designs and my older NXP-inspired boards. In the KVx drone reference work I have been studying, the relevant pieces include:

• NXP AN5169 style quadcopter ESC architecture.
• Four MC34GD3000 three-phase gate pre-drivers.
• Twenty-four PSMN4R2-30MLD MOSFETs for four motors.
• WSL20106L000FEA 6 mOhm current shunts.
• KV5x motor-control timing: PWM, ADC sampling, commutation, and slow-loop/fast-loop separation.

The first candidate list is intentionally narrow:

The point is not to search DigiKey forever. The point is to say: start from a bounded set of MOSFETs with reference-design evidence, then measure.

Open-Source Toolchain

This is where the workflow starts to become interesting. I do not want this to live only as hand notes and screenshots. I want the pipeline itself to generate artifacts.

This is the useful role of AI in hardware for me. Not “the agent designs an ESC and I trust it.” That would be reckless. The useful role is closer to:

Hardware still has to be soldered, probed, measured, and sometimes destroyed. AI does not remove that. It can reduce the grunt work around it.

What We Created In This Pass

The first local pipeline artifacts now exist in the repository:

• A copied v1 MOSFET breakout evidence folder from my older Altium project.
• A v2 MOSFET DUT change plan.
• A generated KiCad schematic skeleton for the low-side DUT.
• A CircuiTikZ circuit drawing.
• A SPICE skeleton.
• A project-local Python virtual environment for plotting.
• An ngspice automation script.
• A vendor-subcircuit run using PSMN1R2-25YLD.
• Generated waveform plots and sweep summaries.

I also created a standalone SPICE transient file:

workspace/robotics/pcb/projects/mosfet_dut_v2/analysis/psmn1r2_25yld_low_side_transient.cir

ngspice can run it directly. LTspice can open the netlist-style file too, but it will not magically become a clean drawn LTspice schematic. For the drawn circuit, KiCad and CircuiTikZ remain the cleaner documentation path. The SPICE file is the simulation contract; the KiCad schematic is the PCB contract.

This is the cleaner CircuiTikZ view of the low-side switch:

Then I automated one ngspice sweep. The configuration defines the MOSFET model, supply voltage, load, shunt value, gate drive, gate resistor sweep, and loop-inductance sweep. The script generates ngspice cases, runs them, parses waveforms, writes CSV, and generates plots.

The first real-vendor-model proof used PSMN1R2-25YLD, because I already had its Nexperia/Transim SPICE model locally and the model is also available from Nexperia: PSMN1R2-25YLD.lib. The product page is here: Nexperia PSMN1R2-25YLD.

This is the sweep summary produced by the automated run:

And this is one generated waveform plot for a representative case:

One sweep I care about early is the gate resistor. A smaller Rg can switch faster, but it can also make ringing and overshoot worse. A larger Rg can calm the edge, but it can increase switching time and heat. This is exactly the kind of tradeoff the DUT board should measure instead of guessing.

I should be precise about what these plots mean. They do not prove the final ESC works. They prove the pipeline works:

• The model can be included.
• The netlist can be generated.
• ngspice can run from the command line.
• The waveform data can be parsed.
• The same run can produce CSV, SVG, PNG, and PDF outputs.
• The simulation can later be compared against real oscilloscope data.

What We Are Doing Differently Now

The old work taught me the concepts, but the new workflow is stricter. The difference is not simply “now I use AI.” The difference is that every step should leave behind an artifact.

That is the main shift. I am not trying to be faster by skipping understanding. I am trying to be faster by making understanding repeatable.

The Hardware Roadmap

The immediate board is not a final drone ESC. It is a MOSFET characterization board. The roadmap should look like this:

1. Finish the low-side MOSFET DUT schematic and layout in KiCad.
2. Fabricate the board.
3. Test with bench supply, electronic load, signal generator, and oscilloscope.
4. Measure VGS, VDS, shunt current, source bounce, overshoot, and temperature.
5. Compare lab waveforms against ngspice / LTspice.
6. Repeat with NXP-baseline PSMN4R2-30MLDX.
7. Build a half-bridge DUT.
8. Add the GD3000 gate-driver path.
9. Only then move to the full three-phase and four-motor ESC.

This may look slower than buying an ESC. It is slower if the only goal is to spin a motor today. It is faster if the goal is to build a stack I can trust for years.

Why This Matters For Ecological Monitoring

My drone work is not only about making something fly. Ecological monitoring needs endurance, repairability, efficient compute, good sensors, useful field data, and hardware that can be trusted outside the lab. A few percent of efficiency can matter. Weight matters. Heat matters. Power electronics matter.

That is why I cannot treat the ESC as a black box forever. The motor, propeller, MOSFET, gate driver, shunt, PCB layout, battery, firmware timing, and flight controller all interact. If I want a drone stack that is cheap, repairable, and instrumented, I need to understand this layer.

This is also why I think open-source tools matter. KiCad, ngspice, Python, matplotlib, and text-based artifacts let the process become inspectable. I can put the pipeline under version control. I can rerun a sweep. I can compare a measurement against a simulation. I can generate reports. I can use AI to harden the workflow without handing away the engineering judgment.

Current Status

The current status is modest but important:

• The MOSFET DUT v2 workspace exists.
• The first KiCad schematic skeleton exists.
• The first visual circuit diagrams exist.
• The first ngspice automation path works.
• The first vendor MOSFET model run works.
• The plotting/reporting path works.

The next serious missing piece is the exact vendor SPICE model for the NXP-baseline PSMN4R2-30MLDX / PSMN4R2-30MLD, followed by the real KiCad layout for the DUT.

This is the start of the hardware hardening loop. Not a finished ESC. Not a claim of success. A measured restart.