Motor Database

What this is: a database of brushless motors used in slot car racing, with the electrical and mechanical specs, tuning data, and simple calculators to go with them.

What it's for: putting real numbers behind two practical questions — which motor should I buy for a given class or track, and how should I tune it so it performs well without burning out. Data can be created and maintained either through this web page or directly via its REST API. Reading is always open; creating, editing, and deleting requires an account — see the Account tab.

The science: comparing motors

Every motor's Km (motor constant — torque per √watt of resistive loss) is the single best apples-to-apples efficiency figure between motors of different winding turns — it's derived automatically from Kt (torque constant) and Rw (winding resistance), no bench test required beyond a resistance measurement. Use the Motors tab's Compare feature to line up Km, Kv (velocity constant — unloaded rpm per volt), and the rest of a motor's specs side by side for up to several motors at once before you buy.

Where enough is known about a motor (Ke [back-EMF constant], Kt, Rw, viscous damping, and the five thermal coefficients — see a motor's own (i) tooltips for how to measure each one), the app computes a full performance graph: torque, current, shaft power, and efficiency swept across the motor's entire speed range at a chosen supply voltage and track/wiring resistance. That same computation also answers the burnout question directly — it works out allowable continuous power (what the motor can dissipate forever at a given speed without overheating) and allowable overload power (a higher figure it can survive for a short burst, like a standing start, before crossing that line). Those two numbers are exactly what should be driving your eCom's duty_spup (spin-up limit), duty_ramp, and duty_rate choices for a given track and voltage — set them from the graph's own numbers rather than by guessing, and you get the motor's full performance without cooking it. AART accounts can generate/regenerate this graph from a motor's detail page; anyone can view one that's already been generated.

What to measure, what to estimate, what to skip

Not every field on a motor record is worth the bench time. The table below is in order of decreasing importance: the first group has to be measured because nothing else on the record can stand in for it, the second can be worked out reliably from numbers you already have, and the third can be left blank without hurting the performance graph or the comparison between motors. For the load-based tests, see the flywheel load and deriving a torque curve from one spin-up.

ESC firmware and distributions

Each eCom settings profile targets one specific firmware, and firmwares don't share a parameter vocabulary, so check a profile's own firmware/distribution/release tag (shown on its card) before importing it:

• ESCape32 — the parameter set (damp/timing/ freq_min/…) most profiles in this app use. Two distributions exist: the official neoxic/ESCape32 firmware (with its ESCape32-WiFi-Link eCom UI), and this org's own fork, aartech-dev/ESCape32 / aartech-dev/ESCape32-WiFi-Link, which builds custom ESC hardware targets and a rewritten eCom web UI. A profile tuned against one distribution isn't guaranteed valid on the other — this app doesn't validate params against either one, so check the target build's own limits first.
• Infinity Racing ESC — a from-scratch C++20 firmware built for hardware compatibility with ESCape32 ESCs, with its own configuration model rather than ESCape32's flat key/value preset. As of this writing it has no published, settled runtime preset format for end users — only board/feature build configuration — so there's nothing yet to download a tuned profile into for this firmware. Profiles can be tagged firmware: "infinity-racing" once one exists.

Brushless motors for slot car racing: background

A quick, non-technical run-through of what the numbers on a motor's spec sheet mean, where this app's data actually comes from, and how to generate a slot-car-relevant load on the bench without a real track.

The numbers on a spec sheet

Kv (velocity constant, rpm/V) is the single number every listing leads with: unloaded RPM per volt applied. Higher Kv means faster but less torque per amp at a given voltage - it's the main lever a winder pulls to trade speed against torque, and it's the first thing to match against your gearing and track voltage. Poles (always even - these motors are almost all 12-pole/9-slot) sets the electrical switching frequency at a given RPM, which drives the ESC's freq_min/freq_max choice. Once you have a bench-measured Rw (winding resistance) alongside Kv, this app derives Km (torque per √watt of resistive loss) automatically - the best single figure for comparing motors' torque-per-heat efficiency independent of winding turns, and what the Motors tab's Compare feature lines up side by side.

The model numbers themselves (1103, 1106, 1207, ...) encode the outrunner can's rough size: the first two digits are diameter in mm, the last one or two are stack length in mm - an 1103 and an 1106 share the same 11mm can diameter, but the 1106's longer 6mm stack gives it more torque for the same Kv than the 1103's 3mm one. It's a size-class code, not a precise dimension - always check a specific listing's own diameter/stack-length figures if you have them.

Almost every small slot-car ESC, including ESCape32, drives the motor with sensorless trapezoidal (six-step, 120°) commutation - the simplest, lowest-processing-power method: two of the three phases are energized at a time in a fixed sequence, switched from back-EMF zero-crossing timing. That's also its real limitation, not just a slot-car-specific quirk: sensorless commutation genuinely isn't operable at very low speed or standstill, because there's no usable back-EMF to read yet - exactly the window ESCape32's duty_spup ramp has to force/manage rather than sense (see the "Startup current" section on a motor's own performance graph). A sensored setup - Hall-effect sensors reading rotor position directly - sidesteps that limitation entirely, detecting position immediately even at rest, at the cost of the sensors themselves and their wiring/board space. ESCape32's timing parameter is an advance on the sensorless switching point - more advance trades a faster no-load speed for more current draw.

Getting a motor to actually start reliably against load takes three separate ESCape32 parameters working together, not just one: duty_spup caps the duty cycle (and so the current/torque) allowed at a dead stop; duty_ramp is the speed window, in kERPM, over which that cap is released back up to 100% as the motor picks up speed (set to 0, its default, this ramp is effectively disabled - the cap jumps to 100% the instant ERPM is nonzero, so duty_spup alone is protecting only the very first instant); and duty_rate is a separate slew-rate limiter on how fast the ESC's actual output duty is allowed to chase whichever of those two ceilings (or the commanded throttle) is currently lowest - it smooths the transition but doesn't raise or lower either ceiling itself. A motor that won't start clean is usually under-provisioned on one of these three, not necessarily on duty_spup alone. freq_min/freq_max, by contrast, don't gate whether the motor starts at all - PWM keeps running continuously through spin-up rather than switching off (that only happens, in effect, once duty reaches 100% and stays there). What freq_min actually governs is PWM timer resolution at low speed: a lower switching frequency gives more timer ticks per period, so a small duty_spup percentage is still represented by enough discrete steps to be delivered smoothly rather than coarsely/jittery - relevant to how clean a start looks and how much switching-loss heat it generates, not to whether there's enough torque to start at all.

Two real middle grounds exist between plain six-step and full continuous drive. Widening the conduction window to 150° instead of 120° ("pseudo-sinusoidal") trades a longer high-current window for noticeably better acoustics and higher achievable speed/torque, while still leaving enough of a gap to sense back-EMF zero-crossings sensorlessly. Separately, adding extra Hall sensors to resolve rotor position more finely gives higher-resolution stepped commutation - 12-step instead of 6, switching every 30 electrical degrees instead of 60 - smoothing torque between the coarser six-step points; historically the way to cut torque ripple before cheap FOC-capable microcontrollers made continuous sinusoidal drive practical (see US4758768A for a worked example). It's the same underlying technique - a Hall sensor picking up the rotor magnets' own field - as the external speed-measurement probe described above, just used to drive the commutation itself rather than to independently verify it from outside.

Sinusoidal drive energizes all three phases continuously with a smoothly-varying waveform instead of switching in steps - smoother and quieter, and more efficient for motors actually wound for sinusoidal back-EMF, but it removes the flat zero-crossing window sensorless six-step control reads, so it needs a real position sensor or a full computed back-EMF observer, plus more switching losses. Field-oriented control (FOC) goes further, actively holding the stator's field perpendicular to the rotor's (via the Clarke/Park transforms) to maximize torque per amp, efficiency, and top speed at the cost of real computational load - especially running sensorless. Newer/higher-end systems are starting to move that direction (Infinity Racing ESC's own board build configs already carry a selectable commutation_model field). This app's performance-graph model assumes simple six-step-style behavior throughout, same as ESCape32 itself. TI's own "Comparison of commutation methods" walks through all of these trade-offs in more depth.

Track wiring resistance and supply capacity

Everything electrically between the power supply and the motor - rail joints, wire gauge, braid/pickup contact, connectors - is resistance in series with the motor's own winding resistance (Rw). Under load that matters: Ohm's law means every ohm of track/wiring resistance steals I×R volts away from what actually reaches the motor, and it steals the most exactly when the motor draws the most current - at a stop or low speed, the highest-current part of the whole run. This is precisely what this app's performance graph parameterizes as radd ("Track resistance" on a motor's own detail page, 0–100Ω): raising it lowers the effective voltage available at a given current, shrinking the graph's whole torque/power/current curve rather than just shifting it - worth actually setting to a realistic figure for your own track/wiring, not leaving at the 0.1Ω default, if you want the graph to represent what your car will really see.

Available current isn't unlimited either - it's set by the supply itself. Real installations vary: the UK National Track, at Corby, runs one 40A Meanwell device per lane - a genuinely representative figure behind the 40A line this app shades as the danger zone on every Current chart, not an arbitrary round number. Drag-racing setups, with their very high peak currents off the line, push considerably higher: the well-known Bulldog RDC-90 (River Gate Distributing) is rated 90A specifically for that.

A lot of track power in practice - not just improvised bench setups - is a repurposed computer power supply: PC ATX units, or higher-wattage server/mining supplies for more current, chosen because they're cheap and readily available at real current capacity. Worth knowing their overcurrent protection (OCP) is tuned for a computer's own load profile, not for sustained near-stall slot car current or the repeated hard shorts a stalled or crashed car can produce: many don't current-limit gracefully on a dead short, they latch the output off entirely (or "hiccup" - brief retry pulses that never actually restart output) and need the AC input physically removed and reapplied to reset - not something you want happening mid-race, let alone mid-test. Programmable digital bench supplies (e.g. the popular Riden RD6024/RD6030 series) current-limit more gracefully, but units bought through marketplaces like AliExpress are frequently sold with a CE mark that hasn't actually been through CE compliance testing - check the listing and seller carefully, not just the price, before trusting one near a motor and a battery-level current source.

Where this data comes from

Most published brushless specs for this motor class - including the seed data behind several motors in this app - originate from drone thrust-stand testing, not slot-car bench testing: a dynamometer holds the motor, spins a specific propeller through a voltage/ throttle sweep, and logs thrust, torque, RPM, current, and voltage (see e.g. Wingflying's motor-test equipment for what this kind of rig looks like). That's genuinely useful for Kv, Rw, and a rough Kt/Ke - but a propeller's aerodynamic load has a completely different speed-torque relationship from a slot car's drivetrain, so it can't tell you the viscous-damping or thermal figures this app's performance graph feature needs. Those need measuring under a load that actually resembles a car.

If a motor you're cataloguing is a repurposed drone motor rather than a slot-car-native one - several already in this app are - it's worth checking whether it's already been through a thrust stand before you measure it yourself: Tyto Robotics' public motor database is a crowd-sourced collection of exactly this kind of drone/RC thrust-stand data, searchable by model. It won't have Do-Slot/Parma/AMAX/NSR-style slot-car-native motors, but for an FPV-class motor it can save a lot of bench time on Kv/Rw at least.

Bench-testing your own motor: a flywheel load

To get a slot-car-relevant load without a real track, AART designed a simple steel flywheel that reproduces the inertia a motor actually feels through a car's drivetrain. The physics: a motor doesn't feel the car's mass directly - through the gear ratio and wheel radius, it feels a smaller reflected inertia,

J_effective = m_car × (r_wheel / gear_ratio)²

For a 70g car on 16mm-diameter tyres with a 4:1 final drive, that works out to J_effective ≈ 2.80×10⁻⁷ kg·m². A solid steel cylinder 14mm in diameter and 9.4mm wide has almost exactly that same moment of inertia (J = ½mr² ≈ 2.78×10⁻⁷ kg·m², steel at ~7850 kg/m³ - we checked the numbers independently and they match to within 1%) - so spinning a motor against one of these flywheels on the bench loads it the same way that car would.

Two bore sizes cover this app's most common shaft diameters, held on with a grub screw:

With a thermal soak test on top, this also gives the five thermal fields this app's performance graph needs - see each field's own (i) tooltip on a motor's detail page for exactly how to measure it.

Build your own flywheel

Enter your own car's numbers below to size a flywheel for it - the calculator solves the same two equations as the table above, exactly (not rounded to a nearby stock size), and a "Download STEP file" button turns the result into a real solid model of the tube shape (outer diameter, bore, width) ready to hand to a lathe or a 3D metal printer. It doesn't model a grub-screw retention hole - its size and position aren't specified by anything on this page, so that's left for whoever machines the part.

Deriving a whole torque/speed curve from one spin-up

Because the flywheel's own moment of inertia is known precisely (it's the whole point of calibrating it against a specific car), a single full-duty spin-up transient against it can yield the motor's entire torque/speed curve directly, instead of needing a series of separate steady-state measurements: log the ESC's commutation output (or its back-EMF zero-crossings) through the spin-up with enough sample memory to capture the whole event at fine time resolution, and each commutation edge's timing gives instantaneous electrical speed at that instant - ω(t), converted through the motor's pole pairs. From ω(t), angular acceleration dω/dt follows directly, and Newton's second law for rotation gives the torque the motor was producing at that exact speed:

T(ω) = J_flywheel × dω/dt(ω) + T_loss(ω)

T_loss(ω) is whatever bearing/windage loss the motor has on its own - a no-load spin-up (no flywheel) isolates that term, and it should closely match this app's own kvd·ω^(mvd+1) viscous-damping model. One transient recording this way beats a whole sweep of individually-held steady-state points, and repeating it with different eCom settings (timing, freq_min/freq_max, duty_spup/duty_ramp, ...) turns it into an empirical way to see what a setting actually does to the motor, not just what this app's simplified model predicts.

The ESC's own commutation signal can be unreliable at the very lowest speeds, though - exactly the window duty_spup governs (see a motor's own "Startup current" control), where back-EMF is small and sensorless detection is least trustworthy. A Hall-effect probe placed near the motor, picking up the rotor magnets' own rotating field directly rather than inferring speed from the ESC's commutation, gives an independent speed measurement through that entire window - including before the motor is spinning fast enough for clean sensorless detection - so the very startup behavior this app's startup-current model predicts can be checked against a real, direct measurement rather than taken on faith.

Rotor balancing

Any mass offset from the spin axis produces a centrifugal force that rotates with the rotor - F = m × r × ω², where m is the effective imbalance mass and r its distance from the axis. Because it scales with ω², imbalance that's completely unnoticeable at low RPM becomes a real oscillating load at the RPM these motors actually run. Worked example: a 2mg imbalance (the figure often quoted for better Chinese-made motors) at a 4mm radius, spinning at 60,000 RPM (ω ≈ 6283 rad/s, i.e. a 1kHz oscillation), works out to F = 2×10⁻⁷⁵ × 0.004 × 6283² ≈ 0.32N - about 32 grams-force, oscillating at 1kHz, on a motor that likely weighs only 10-20g itself. That shows up as bearing wear and reduced bearing life, audible/felt vibration, and - if it happens to land near a chassis or axle resonance - genuine, non-negligible handling noise layered on top of whatever the motor is actually trying to do. It has nothing to do with a motor's electrical Kv/Rw figures, so nothing in this app's own model captures it; it's a purely mechanical manufacturing quality question, and one of the few places "you get what you pay for" is a real, physically justified statement about a slot-car motor.

Does a faster-revving motor actually corner better? (gyroscopic effect)

A spinning rotor carries angular momentum L = I×ω, and resists having that spin axis reoriented - exactly the mechanism a gyroscope uses to stay upright. As a car goes through a corner, its whole chassis yaws (rotates about a vertical axis), and that yaw forces the motor's spin axis to reorient along with it - producing a reaction torque τ = Ω×L, where Ω is the yaw rate. It's real physics, and a higher-Kv motor genuinely does produce more of it, roughly in proportion to Kv, because swapping to a higher-Kv winding in the same physical frame mostly changes RPM, not rotor mass or radius (so I stays about the same while ω scales up).

Which axis that reaction torque lands on depends entirely on how the motor is mounted, though - it's not automatically the "helps cornering" direction. A sidewinder chassis (motor spin axis parallel to the rear axle, i.e. transverse to the direction of travel) couples cornering yaw into a roll moment - the axis body-roll folklore is actually thinking of. An inline chassis (motor spin axis fore-aft, driving through a right-angle crown/pinion) couples the same yaw into a pitch moment instead, which has nothing to do with cornering grip at all. And even in the sidewinder/roll case, whether that moment resists or adds to body roll depends on the motor's rotation direction relative to which way the corner turns - there's no guarantee the effect ever points the "helpful" way.

Working out which way that reaction torque actually pushes needs two directions, not just the formula above: which way the rotor's angular momentum L points (set by which end of the motor you're looking at and which way the rotor turns), and which way the chassis yaw rate Ω points (set by which way the corner turns). The reaction felt by the chassis - not the torque needed to force the rotor to precess, but the equal-and-opposite kick that precession gives back to whatever's holding the rotor, i.e. the motor mounts - is τ_reaction = L×Ω.

For a sidewinder motor (spin axis parallel to the rear axle), L points left or right depending on rotation direction, and Ω points straight up or down depending which way the car turns. Their cross product always lands on the fore-aft axis - a roll moment, one side pushed down and the other lifted. Work through a left turn and a right turn for the same fixed rotation sense and something non-obvious falls out: because a left turn's "outside" is the right side and a right turn's "outside" is the left side, and the torque's own sign flips between the two turns in exactly the same way, the physical result - which side gets pushed down relative to the outside of whichever way you're turning - stays the same in both directions. A motor spinning one way consistently reinforces the weight transfer the corner is already producing, loading the outside wheel harder and lifting the inside one further, on every corner regardless of which way it goes; spinning the other way consistently opposes it, resisting weight transfer and helping keep all four contact patches loaded, on every corner too. Which of those you get depends only on the motor's rotation sense relative to which side it's mounted facing - get it backwards and a sidewinder's gyroscopic contribution is quietly working against you in every single corner, not helping.

An inline motor (spin axis fore-aft, driving through a right-angle crown/pinion) puts L along the direction of travel instead, and the same cross product with a vertical Ω now lands on the left-right axis - a pitch moment, nose up or down, not roll at all. Unlike the sidewinder case, this one doesn't self-correct across turn directions: a left turn and a right turn for the same rotation sense pitch the nose opposite ways (up in one, down in the other), so over a track with a normal mix of left and right corners the effect roughly cancels lap to lap. Where it doesn't cancel - an oval, or a track with a strong bias one way - it's shifting load between the front and rear contact patches (steering precision and guide-flag force at one end, traction at the other), which is a different trade-off from the sidewinder case's straightforward grip gain or loss.

The calculator below works the actual numbers for two motors sharing a frame (so the same assumed rotor mass/radius) at 18,000Kv and 22,000Kv, a corner taken at 2m/s with a 300mm radius (a tightish but not extreme corner) - defaults you should replace with your own if you have better rotor or track numbers. With a rough 3g/3mm-radius rotor, that comes out to roughly 68mN of equivalent force for the 18,000Kv motor and 83mN for the 22,000Kv one (22% more, tracking the Kv ratio exactly, as expected) - each only a few percent of a plausible ~2N of tyre grip. The physics is real and the direction of the Kv comparison is real, but at this scale the magnitude is small enough that it's very unlikely to be what a driver actually feels through a corner; other differences between a higher- and lower-Kv motor - more RPM headroom for gearing choices, a different torque/current curve shape, more heat - are much more plausible explanations for any real handling difference than gyroscopic precession from a rotor this size.

Where this should lead

Everything above - a motor's own torque/speed curve, ESCape32's firmware behavior (timing, freq_min/freq_max, duty_spup/duty_ramp/duty_rate), and now drivetrain/rotor mechanics - are all pieces of the same eventual model: add gear ratio, tyre diameter, car mass, and a real track layout (straight lengths, corner radii, banking, grip), and it becomes possible to simulate a whole lap and solve for the timing and gear ratio that actually minimize lap time for a specific motor on a specific track, instead of guessing and testing physically. That simulation is only as good as its calibration, though, which means it needs real measured data to check itself against - an instrumented eCom logging its own duty/ERPM/current/timing in real time, alongside a separate logger capturing what the car actually did on track (lap/sector times, ideally an onboard IMU), compared back against what the simulation predicted for the same conditions. Run that loop enough times and the same model, inverted, starts to answer a different question: not "how should I tune the motor I have" but "what motor - what Kv, what winding, what rotor - should I ask a winder to build for a specific car and track in the first place."

Designing a motor

A first cut at that inverted question: given a winding and a can, not just an off-the-shelf part, what Kv and performance does it actually produce? The magnetic-circuit chain is genuine first-principles electrical-machine design, not a guess - magnet grade and air gap set the air-gap flux density, pole/slot count sets a winding factor, flux times turns times poles gives the back-EMF constant, and wire gauge plus turns gives winding resistance - and it's been sanity checked against this app's own catalog. The defaults below (a 12-pole/9-slot outrunner roughly 1106-can-sized) land at a clean, warning-free ~4570Kv at 6 turns per coil. Push magnet thickness up toward 0.95mm and drop to 4 turns, though, and it lands at ~5990Kv - within a fraction of a percent of this app's own real "EMAX RS1106 6000KV" entry, using nothing but geometry, materials, and turn count - while also correctly flagging that getting there pushes the stator into saturation and that a stall at that point would demagnetize the magnets permanently, not just heat them up. That's not the tool being unreliable at the edge; a real 6000Kv 1106-class motor plausibly is running close to both those limits, which is itself a genuinely useful thing to learn from trying to reproduce one.

Two real gaps, though, matched to what each part of the calculator is actually built on. Kv, Kt, and Rw come from a real magnetic circuit and Ohm's law - genuine electromagnetic design, with the usual small simplifying assumptions any hand-calculation makes (fixed magnet arc coverage, a single-layer concentrated-winding factor exact for common combinations like 9-slot/12-pole and approximate elsewhere, no iron saturation modeling beyond a basic warning). Viscous damping and thermal resistance are a different kind of number entirely - rough windage/bearing-friction and still-air convection formulas standing in for something this app has otherwise always insisted on actually measuring (see the flywheel and thermal-soak methods above). They're included because a ballpark beats nothing when specing a build, not because a formula has replaced the bench - treat the electrical outputs as a real design estimate, and the damping/thermal ones as an explicitly rough placeholder until someone actually spins the thing up.

Stack length and winding configuration both feed the calculation, not just sit in the input list. A longer stack raises Kt (and lowers Kv) in direct proportion - more flux per pole, same turns - but it isn't free: the "estimated active material mass" line below (magnets, back-iron/ can, and copper, not the whole motor - no shaft, bearings, or housing) grows right along with it, so the torque-for-weight trade a longer can makes is an actual number, not just a general principle. Star versus delta is a separate lever entirely: the same physical winding reconnected star-to-delta multiplies Kv by √3 and divides Rw by 3 - the standard rewind-shop conversion for this exact swap - so it's a selectable input, not folded into any other field. There's no inrunner/outrunner selector - every motor either of us has ever actually built or bought has been an outrunner can, so that's the only geometry this calculator models (a real inrunner's stator-outside-in mapping is genuinely different, not a checkbox away) rather than offering a choice that would be unvalidated the moment you picked the other option.

The "50"/"52" in a magnet grade name is a maximum energy product figure in MGOe (mega-gauss- oersteds), not a flux density - it correlates with Br but isn't the same number, which is why the calculator keeps its own Br lookup rather than using the grade number directly. More relevant to an actual motor: NdFeB genuinely gets weaker with heat, and the calculator now models that rather than treating magnet strength as fixed. There are two separate effects, on very different footings. Br itself falls reversibly with temperature - about 0.12% per °C for standard N-grade material, recovering fully on cooling - so a magnet input field lets Kv/Kt shift with operating temperature the way a real motor's actually would. The second effect is not reversible: coercivity falls 5-6x faster than Br as the magnet heats, and above roughly 80°C (the standard N-grade's rated ceiling - higher-temperature-rated grades like N50H/N50SH push this further, not modeled here) a magnet under load can cross the demagnetization curve's "knee" and lose flux permanently, not just while hot. The calculator flags this - and it's worth calling out that the scenario where it's most likely to actually happen on a real car is exactly the one this app's own startup-current model already exists to manage: a stalled or hard-launching motor is simultaneously at its hottest and drawing its highest demagnetizing current, right when the magnet is least able to take it.

That's now a real, worked check, not just a general warning - sourced directly from Arnold Magnetics' own N50/N52 datasheets: α(Br) = -0.12%/°C, α(Hcj) = -0.62%/°C (just over 5x, confirming the rule of thumb above), and a minimum intrinsic coercivity of 875kA/m at 20°C for both NdFeB grades (SmCo's numbers are different again - see below). The calculator takes a stall at the entered supply voltage and winding resistance as the worst case, works out the demagnetizing field that current puts across the magnet (via the same simplified magnetic-circuit assumptions as everywhere else here - Ampere's law across the magnet only, ignoring iron and air-gap reluctance), and compares it against Hcj at the entered magnet temperature. Cross that line and the verdict is concrete: that motor needs rewinding or replacing, not just letting cool down - the flux loss already happened and cooling doesn't bring it back. It's also worth being honest about what stays a genuine approximation here: the demagnetizing-field calculation assumes all the winding's ampere-turns land on the magnet (a reasonable but not exact simplification), and it checks one worst-case instant, not a real transient - a brief stall recovers heat faster than it demagnetizes flux, so treat a flagged verdict as "this condition is dangerous," not as a promise that every stall of any length does this.

Pole count: would 8 beat 6 or 12?

AART has only ever built 6-pole and 12-pole motors. Worth actually checking whether that's leaving anything on the table, using the calculator above rather than guessing - hold everything else fixed (9 slots, same case, same wire, same target Kv) and vary only pole count:

Two real findings, not just a table of numbers. First: 6-pole and 12-pole are electrically identical at 9 slots - sin(60°) = sin(120°) exactly, so the winding-factor formula gives the same 0.866 either way. Whatever's made 6-pole worthwhile historically, it isn't winding efficiency; it's something this calculator doesn't model (cost, manufacturing, a different slot count in practice, mechanical constraints). Second: 8-pole is a real efficiency win - about 6.6% better Km (torque per √heat) than either existing option, from needing fewer turns of the same wire to hit the same Kv - but it isn't a free lunch. Tooth flux density at 9 slots is a function of the slots/poles ratio and the magnetic circuit alone (∝ B_gap × slots/poles) - completely independent of overall motor size, so scaling up the frame doesn't rescue it. 8-pole would need a thinner magnet or larger air gap than AART's existing 6/12-pole recipe to back the flux density down to where the stator isn't saturating - worth prototyping, not a drop-in swap with the current winding recipe.

Could a different magnet material do better? (SmCo vs NdFeB)

Cobalt-based magnets - samarium-cobalt (SmCo), not the alnico used in much older motors - were the high-performance choice for decades before NdFeB became cheap enough to dominate, and they're still specified today wherever temperature stability matters more than raw output: aerospace actuators, downhole drilling tools, magnetron sputtering targets. The "neo magnet strength" selector above now includes a real Sm2Co17 grade (Arnold Magnetics' Recoma 35E) alongside N50/N52, sourced from Arnold's own datasheet the same way the NdFeB figures were:

The trade is exactly what you'd expect from a material that costs several times more per gram: SmCo gives up about 17% of NdFeB's Br - lower Kv/Kt for the same winding, or more turns to match it - in exchange for roughly double the coercivity and 2-3x better temperature stability on both figures. Run the actual comparison rather than just reading the numbers off the table: at this page's own default winding (6 turns, 0.6mm magnet, 12V), a stall demagnetizes the N50 version PERMANENTLY at room temperature already - the design calculator flags it out of the box. Switch the same winding to Sm2Co17 and that exact stall - same current, same turns, same everything else - survives: the demagnetizing field (1658kA/m) stays under SmCo's coercivity (1689kA/m) at 25°C, where it had already blown past NdFeB's (848kA/m). That's not a marginal difference - it's the difference between "this motor needs rewinding" and "this motor is fine," for the identical stall, purely from the magnet material. If stall-related magnet damage turns out to be a real, recurring problem rather than a theoretical one, SmCo is the concrete lever this app can now actually show the size of, not just gesture at.

Gearing and tire diameter for a real track

Putting a motor's Kv together with an actual track answers "what gear ratio and tire diameter" directly, rather than leaving it as separate numbers to reconcile by feel. Worked here against Bolton - real data, not assumed: the track directory gives a 118ft lap and "best lap times close to 3 seconds"; a traced SVG of the track's four lanes (measured directly, not estimated - all four lanes come out within 0.01ft of each other in total length, and agree on the main straight to the same precision) puts the main straight at 21.4ft (6.53m), by a wide margin the longest straight run on the layout - the next-longest is under 3.3ft.

The calculator below takes a motor as just Kv and Rw (not a full performance-curve record - it needs to work for a motor that's still just a plan), a gear ratio built from real pinion/spur tooth counts at 48, 64, or 72 pitch, and a tire diameter, then simulates the run down that 6.53m straight from a standstill: fixed gearing slaves motor speed directly to car speed, so at every instant the resulting back-EMF, current, and torque follow directly, integrated forward to see how much of the drivetrain's own top speed the car actually reaches before running out of straight.

Where on the straight a gear ratio reaches its own top speed - not just the raw top speed number - is the right thing to check a ratio against, and checking it against a number you already gave us is a real validation, with a genuinely useful wrinkle in it. At this track's own 12.4V, an 8:1 reduction (5:40) - your own convention for this whole Kv band - lands close to "reaches top speed right around the end of the straight" for the low end of it: at 21,000-22,000Kv this model has the car just finishing its run to top speed in the back 10-25% of the straight, about as well matched as gearing gets. Run the same 8:1 at 24,000-26,000Kv, though, and the model says the car is still accelerating hard at the line - never quite finishing the job in 6.53m. Extending that logic, a strictly straight-line-optimal ratio would want to climb - toward 9:1 or so - as Kv climbs through that band, not stay fixed at 8:1. That AART runs one ratio across the whole range anyway isn't a mark against the model; it's a sign that pure straight-line physics isn't the only thing being optimized for. A corner comes right after that straight, and a single well-proven ratio across a Kv band - predictable, one fewer thing to re-tune per motor, not perched right at "still surging" for the most powerful motors in the range - plausibly beats chasing the theoretical straight-line optimum for each one individually. That's exactly the kind of real-world consideration this calculator can surface a question about but can't answer on its own. Worth remembering what else it leaves out even on the straight itself: the motor's own viscous damping, reflected drivetrain inertia, and tire wear are all real and all ignored - and ground clearance (this page's stated 15mm minimum diameter, sized to still clear the track at ~1mm or less once a tire's worn flat by race end) is a mechanical constraint this calculator checks but doesn't model the wear itself.

The pinion and spur choices below aren't arbitrary numbers - a slot car gearbox can only be built from what's actually manufactured, so they're drawn from real catalog parts (Cahoza, Mid- America/ARP/Sonic via slotcarstore.net, and JK Products, checked 2026-09-29), not every mathematically possible tooth count. 48 pitch is a coarser, larger-axle (1/8") convention with pinions 7-15T and spurs 31-33T. 64 pitch runs pinions 5-16T against spurs 31-39T. 72 pitch runs pinions 5-14T against spurs 37-44T - the finer pitch keeps a high-tooth-count spur physically smaller, which is why a fast 1/24's conventional 5:40 (8:1) reduction is built at 72 pitch, not 64 (a 40-tooth 64-pitch spur isn't a catalog part at all). Both 64 and 72 pitch spurs come for either a 2mm or a 3/32" axle; 48 pitch only for 1/8". Pinions are built for a 2mm motor shaft by default, but the smallest tooth counts (down to 5T) are also sold for a 1.5mm shaft - the shaft size fitted to small, high-Kv (18,000Kv and up) motors - which is why the calculator below flags a pinion above about 8 teeth as worth double-checking on a motor in that Kv range.

A second real data point looked at first like it complicated the story above, until the actual reason behind it turned out to be much simpler. A 4500Kv motor at 9:32 (3.56:1) has given real 4.1 second laps at Bolton; a more extreme 13:34 (2.62:1) also gets used with the same motor. Run through this same straight-only model, 9:32 reaches its own (modest, 47km/h) top speed at just 19% of the way down the 6.53m straight, and 13:34 only gets to about 47% before running out of road - both look like a lot of unused straight by pure physics. The reason isn't a flowing-track/corner-priority story, though: 9:32 is a known, deliberately restricted ratio, chosen specifically to slow racing down for its class, not a competitor's attempt at the fastest possible lap - it was never trying to be straight-line optimal in the first place, so this calculator correctly flagging it as such isn't a surprise or a model failure, it's the model doing exactly what it should with a ratio that's genuinely sub-optimal by design. Worth keeping that distinction in mind reading any of these worked examples: a real ratio in active use is evidence about what it's actually for, which isn't always "the fastest possible lap" - restricted classes, spec rules, and consistency/ durability choices are all real reasons a ratio might not match what a pure physics model would pick.