Calculator Methodology: How ArcheryEra Calculates It

1 Quick Summary

The visualizer treats an arrow as a point mass under gravity and an exponential drag term set by fletching and head type. Time-of-flight comes out of that drag model in closed form, drop follows from time-of-flight, and wind drift is scaled by how long drag has made the arrow linger in the air — not by the full flight time.

2 Inputs & Parameters

3 Constants & Static Values

4 Formulas & Mathematical Equations

5 Code Snippet (Logic Core)

// trajectory-core.js — verbatim from the live tool
var G = 9.81; // m/s²
var EFF_MASS = 30; // grains — same sitewide virtual-mass constant as the Arrow Speed Calculator

function speedFps(s) {
  if (s.bow === 'compound') {
    var vBase = s.ibo + 2*(s.dw-70) + 10*(s.dl-30);
    var baseline = 5*s.dw;
    var sw = s.sw || 0;
    return Math.max(100, vBase*Math.sqrt((baseline+EFF_MASS)/(s.aw+sw+EFF_MASS)));
  }
  return Math.sqrt(0.5*s.dw*(s.dl-1.75)/12*0.72*450240/s.aw);
}
function tof(d, v0, k)  { return (Math.exp(k*d) - 1) / (k*v0); }
function drop(d, v0, k) { var t = tof(d, v0, k); return 0.5*G*t*t; }
function ke(grains, fps)  { return grains*fps*fps/450240; }
function mom(grains, fps) { return grains*fps/225218; }
function impactFps(fps, k, d) { return fps*Math.exp(-k*d); }

6 Assumptions & Edge Cases

• Drag is modeled as a constant fraction of velocity lost per metre (the k value), not a full aerodynamic drag-coefficient simulation — it is calibrated to match observed field-point and broadhead behavior, not derived from a wind-tunnel model.
• The compound speed formula adjusts off an ATA-condition (70 lb / 30 in / 350 gr) rated speed linearly for draw length and draw weight, then applies the same virtual-mass ratio as the Arrow Speed & Performance Calculator for arrow weight (fixed 2026-09-14 to replace an older flat per-grain penalty that understated speed at heavy arrow weights) — see that tool's methodology below for why ATA and IBO numbers are not interchangeable inputs. This tool does not collect a string-weight input, so its estimate runs a few fps optimistic next to a build that adds real accessory mass.
• Wind drift only accrues during the time drag has already cost the arrow — a zero-drag arrow in this model would not drift at all, which matches the actual physics of a crosswind acting on lag time, not on distance traveled.

7 Out of Scope / Limitations

• No air density, altitude or temperature correction — the drag constants are calibrated at sea-level standard conditions.
• No spin-drift or gyroscopic precession modeling (negligible at archery velocities and distances, unlike rifle ballistics).
• Crosswind is treated as a steady, uniform value for the whole flight — gusting and shear are not modeled.

8 Worked Step-by-Step Example

9 Validation & Testing

The 37.2 in drop this example produces at 40 yards matches the figure the tool's own guide section cites for a 294 fps compound setup, and the drag constants are chosen so a hunting-vane, fixed-blade setup and a target-vane, field-point setup on the same bow diverge in the direction and rough magnitude bowhunters report when they chronograph both configurations. This is a physics-plus-calibration model, not a wind-tunnel measurement — treat the drift and drop numbers as planning figures to sight in against, not a replacement for your own sight tape.

10 Scientific References & Citations

Standard gravity (9.81 m/s²) per NIST's reference value. Rated-speed baseline per the Archery Trade Association's ATA speed standard (70 lb / 30 in / 350 gr), the modern successor to the AMO standard.

1 Quick Summary

A finished arrow is six lumps of mass on a rigid stick — nock, wrap, vanes, shaft, insert and point. Where it balances is the weight-averaged position of those six lumps, and FOC is just that balance point expressed as a percentage of arrow length ahead of center. All the modeling effort goes into getting each part's position right, not into the arithmetic itself.

2 Inputs & Parameters

3 Constants & Static Values

4 Formulas & Mathematical Equations

5 Code Snippet (Logic Core)

// foc-core.js — verbatim from the live tool
var parts = [
  { w: nock,               x: NOCK_X[nockType] },
  { w: wrapLen * wrapGpi,  x: wrapLen / 2 },
  { w: vanes * vaneWt,     x: vaneMargin + vaneLen / 2 },
  { w: len * gpi,          x: len / 2 },
  { w: insert,             x: len - insertLen / 2 },
  { w: point,              x: len + pointLen * POINT_COM[pointType] }
];
var total = 0, moment = 0;
for (var i = 0; i < parts.length; i++) {
  total  += parts[i].w;
  moment += parts[i].w * parts[i].x;
}
var bal = moment / total;
var foc = 100 * (bal - len / 2) / len;

6 Assumptions & Edge Cases

• Every part is treated as a point mass at a single x-position — a reasonable simplification for a nock, insert or point, but the shaft and vanes are distributed mass modeled at their geometric midpoint, which is exact only for uniform-density components (true for a constant-taper carbon shaft; not exactly true for a shaft with internal reinforcement).
• A point's own center of mass (0.42 for field points, 0.50 for broadheads) is a modeling choice, not a measurement of your specific point — the code's own comment notes that getting it wrong by 0.1 moves FOC by roughly a twentieth of a percent, which is why the tool does not expose it as an input.
• FOC is reported two ways: to AMO length (nock throat to end of shaft, excluding the point) and to overall length (point tip included) — the second always reads lower and is the number most often misquoted on forums.
• Site-wide audit, September 2026: this engine (AEFOC.build()) is now the single source for FOC across the site. The Dynamic Spine & Shaft Flex Calculator and the Arrow Build & GPI Weight Calculator, which used to each run their own separate simplified FOC approximation, both call it directly now (splitting their one combined rear-weight input into a nock/vane share via AEFOC.splitRearMass()) — see those tools’ sections for the fix.

7 Out of Scope / Limitations

• Does not model a bent or damaged shaft's actual mass distribution — assumes a straight, intact arrow.
• The 8% / 12% / 19% FOC grading bands are field-practice conventions, not physics constants — the tool says so directly rather than presenting them as a law.

8 Worked Step-by-Step Example

9 Validation & Testing

The balance-point arithmetic is exact — a physical weighted average has no calibration error, only measurement error in the inputs you provide. The FOC grading bands (low / target / hunting sweet spot / extreme) are convention, cross-checked against where target and hunting arrow manufacturers' factory-built arrows actually land, not derived from a single physics law.

10 Scientific References & Citations

FOC% = 100 × (balance point − L/2) / L is the standard formula published by the Easton Technical Products arrow-tuning literature and used industry-wide under the AMO (now ATA) measurement convention.

1 Quick Summary

Kinetic energy and momentum are exact physics — no fitting, no calibration, just unit-converted textbook formulas. Penetration depth and pass-through likelihood are a different animal: a calibrated ranking model built on broadhead type, FOC and game-animal vitals/body depth, tuned to track what bowhunters consistently report rather than derived from a single closed-form equation.

2 Inputs & Parameters

3 Constants & Static Values

4 Formulas & Mathematical Equations

5 Code Snippet (Logic Core)

// trajectory-core.js (exact) + ballistics-core.js (calibrated)
function ke(grains, fps)  { return grains*fps*fps/450240; }
function mom(grains, fps) { return grains*fps/225218; }
// ballistics-core.js — reuses trajectory-core.js's EFF_MASS=30 constant
function speedForWeight(v0, w0, w) {
  return v0 * Math.sqrt((w0 + T.EFF_MASS) / (w + T.EFF_MASS));
}

function focFactor(foc) {
  return Math.max(0.90, Math.min(1.20, 1 + (foc - 12) * 0.012));
}
function effective(grains, fps, head, foc) {
  return mom(grains, fps) * HEAD[head].pen * focFactor(foc);
}
function depth(eff, game) { return eff * game.k; }
function verdict(eff, game) {
  var d = depth(eff, game);
  if (d >= game.body)  return { label: 'Pass-through' };
  if (d >= game.vital) return { label: 'Sufficient' };
  return                      { label: 'Insufficient' };
}

6 Assumptions & Edge Cases

• Kinetic energy and momentum never change no matter what game or broadhead is selected — they are properties of the arrow alone. Only the penetration-depth estimate downstream depends on head type, FOC and target species.
• Fixed September 2026: the "what if I used a heavier/lighter arrow" comparison used to rescale speed with a flat "1 fps per 3 grains" shop rule of thumb, independently of — and inconsistent with — the virtual-mass model already validated and shipped for the Speed Calculator and Trajectory Visualizer (see the Dynamic Spine & Shaft Flex Calculator / Arrow Speed & Performance Calculator sections above). It was off by roughly 18 fps at a 400→600 gr comparison. Now reuses the same EFF_MASS=30 constant so a weight comparison explored here can't disagree with the same comparison run on those other tools.
• The FOC penetration factor is deliberately held to a modest ±20% range — the code's own comment notes the gains from FOC are real but their exact size is genuinely disputed among bowhunters, so the model does not overstate them.
• Broadhead penetration multipliers rank heads relative to each other (2-blade cut-on-contact highest, wide mechanical lowest) based on how bowhunters consistently report them performing, not from ballistic-gel testing done in-house.
• Site-wide audit, September 2026: this page's drag-coefficient table for fletching (FLETCH) used to be its own separate copy of the identical numbers already defined in trajectory-core.js. The values had not drifted, but nothing prevented them from doing so. It now reads FLETCH directly from trajectory-core.js instead of keeping a second copy — the broadhead penetration table (HEAD) stays local on purpose, since it carries penetration multipliers the trajectory model has no use for and is not a duplicate of anything.

7 Out of Scope / Limitations

• No bone-strike modeling — a hit on a scapula or major joint behaves nothing like the soft-tissue assumption behind the depth constants.
• Game vitals/body depth are broadside, average-mature-animal figures — a quartering angle or an immature animal changes the real distance the arrow has to travel.
• This is explicitly a ranking tool for comparing setups, not a promise of what will happen on a specific shot.

8 Worked Step-by-Step Example

9 Validation & Testing

The energy and momentum figures are unit-conversion arithmetic and cannot be "wrong" given correct inputs. The penetration-depth ranking is checked qualitatively against bowhunting-forum penetration reports across broadhead types and FOC ranges rather than against a single controlled experiment — it is presented on the tool page as a ranking signal, and this page repeats that framing rather than overstating precision the model does not have.

10 Scientific References & Citations

Kinetic energy and momentum constants derived from standard Newtonian mechanics (\(KE=\tfrac12 mv^2\), \(p=mv\)) using NIST's standard gravity value and the 7,000 grains-per-pound conversion. Minimum kinetic-energy guidance for game classes follows the bands published in Easton's bowhunting technical literature.

1 Quick Summary

Dynamic spine match is scored on a −100 to +100 Spine Match Index (SMI): the tool computes a "stiffness requirement" from peak bow weight, cam aggressiveness, front-of-arrow weight and cut length, compares it against a shaft's rated capacity, and scales the gap into a single index number.

2 Inputs, Constants & Formula

var requirement = (weight * cam) + ((front - 100) / 10) * 3.5 - (29 - cutlen) * 12;
var capacity = SPINE_CAPACITY[spine];
var smi = clamp(-(requirement - capacity) * 3.5, -100, 100);
var weak = (requirement - capacity) > 0; // positive gap = shaft too weak

3 Assumptions & Limitations

• SMI is a relative index, not a physical deflection unit — it is scaled so 0 sits at "requirement equals capacity" and ±100 are saturation bounds, not real Astatic-spine deflection.
• Draw length is not part of the stiffness arithmetic — only cut length is. Draw length is used separately as a clearance safety check against overdraw, not as a spine-matching input, because two archers with different draw lengths shooting the same cut-length arrow off the same cam load the shaft the same way at release.
• The capacity table only covers 250–500 spine — a build that calls for a stiffer or weaker shaft than that range falls outside the model.
• Site-wide audit, September 2026: FOC used to come from this page’s own simplified three-mass formula, which placed the whole rear-end weight (nock + fletching + wrap) at a flat 0.5in from the nock throat — not where fletching actually sits. FOC is now computed by AEFOC.build(), the same engine behind the Arrow FOC & Balance Point Optimizer, with the single rear-weight slider split into a nock share and a vane share using that engine’s own default proportions. The worked example below moved from 9.3% to 10.4% as a result.

4 Worked Example & References

Static/dynamic spine terminology follows the industry convention documented in Easton's arrow spine selection charts.

1 Quick Summary

Compound mode recommends a static spine off a linear model anchored on a 70 lb / 28 in / 100 gr front-weight baseline. Recurve/traditional mode was rebuilt in September 2026 to call the same Easton-chart-calibrated engine as the Recurve Arrow Spine Calculator (see /assets/js/ae-spine-core.js), instead of the flat "+120" approximation this tool used previously. The tool separately totals finished arrow weight, FOC and estimated speed and kinetic energy from the same inputs.

2 Formula & Code

var front = point + 0.35*ins;
var t;
if (recurve) {
  // Shared engine — same source as the Recurve Arrow Spine Calculator.
  var eff = AESpine.recurveEffectiveWeight(dw, dl, 'modern', point, al).eff;
  t = AESpine.recurveTargetSpine(eff);
} else {
  // Compound mode's own lightweight linear approximation (unchanged).
  t = 320 - 7*(dw-70) + 40*(28-al) + 1.0*(100-front);
}
var target = snap(t); // snapped to the nearest stocked spine: 1200…150

// FOC — shared with the Arrow FOC & Balance Point Optimizer (foc-core.js)
// instead of this page's own moment-sum formula (site-wide audit, Sep 2026).
var rearParts = AEFOC.splitRearMass(tail);
var foc = AEFOC.build({ len: al, gpi: gpi, point: point, insert: ins,
  nock: rearParts.nock, vanes: rearParts.vanes, vaneWt: rearParts.vaneWt,
  wrapLen: rearParts.wrapLen }).foc;

3 Assumptions, Worked Example & References

Why compound and recurve modes still use two different engines: this tool has no cam-profile input, unlike the Dynamic Spine & Shaft Flex Calculator and Carbon Arrow Spine Calculator (Smooth Target / Hybrid Binary / Aggressive Speed). Wiring compound mode into that cam-aware Requirement/Capacity engine without adding that input would silently change already-shipped compound presets (verified: it would shift the "Whitetail" preset's verdict at the default Hybrid-Binary-equivalent assumption) — a bigger, separate change we're leaving for a follow-up that adds the missing input rather than guessing a default cam. Recurve mode had no such constraint, since the effective-weight model never used a cam term, so it was switched over directly and now cannot drift from the Recurve Arrow Spine Calculator again. The compound coefficients (−7 per lb of draw weight, +40 per inch under 28 in draw, +1.0 per grain of front weight under 100 gr) remain a linear approximation of the standard archery spine chart, not a beam-deflection calculation.

This tool's recurve/traditional mode also offers the Shooting Style disclosure (Olympic/Target, Barebow/Stringwalking, Traditional/Instinctive) documented under the Recurve Arrow Spine Calculator above — same shared constant, same reasoning for why it's a disclosure and not a numeric shift.

Site-wide audit, September 2026: FOC used to come from this page's own moment-sum formula, which placed the whole rear-end weight (nock + fletching + wrap, this tool's single "tail" slider) at a flat 1.0in from the nock throat — a different flat assumption than the Dynamic Spine & Shaft Flex Calculator's old 0.5in, and neither matched reality. FOC is now computed by AEFOC.build(), the same engine behind the Arrow FOC & Balance Point Optimizer, with the "tail" total split into a nock share and a vane share using that engine's own default proportions (see AEFOC.splitRearMass()). All four preset descriptions on the tool page were re-checked and updated against the new formula.

Spine selection baseline cross-checked against manufacturer spine charts, e.g. Easton's arrow selection charts.

1 Quick Summary

A broadhead sitting at an angle to the airflow behaves like a small wing, pushing the arrow sideways for as long as launch yaw persists. This tool models that with flat-plate aerodynamics: side force from head/fletching area and dynamic pressure, a restoring moment from the fletching, and a yaw that decays as the fletching wins the argument.

2 Constants & Core Formulas

function margin(af, ah, a) { return (af*a.f) / (ah*a.h); }
function yaw(tear, len) { return Math.atan(Math.max(0, tear)/len); }
function deviation(ah, m, alpha, grains, fps, yards) {
  var q = 0.5*RHO*fps*fps, mass = grains/225218;
  var a0 = q*(ah/144)*CN*Math.sin(alpha)/mass;
  var lr = recovery(m, fps)*3, x = yards*3;
  return (a0*lr/(fps*fps)) * (x - lr*(1-Math.exp(-x/lr))) * 12; // inches
}

3 Assumptions, Worked Example & References

Ordinary flat-plate aerodynamics predicts side force well at the small angles a paper-tune yaw produces, but the recovery-distance formula (how fast the fletching wins) is calibrated, not derived — the tool's own source comment is explicit that "the shape is right… the constant is set so the outputs land on what bowhunters report." Head-area multipliers assume broadside averaging over arrow roll and do not model a specific roll phase at any single instant.

Flat-plate normal-force modeling follows standard low-speed aerodynamics (see any introductory aerodynamics reference on flat-plate lift/drag at small angles of attack).

1 Quick Summary

This is a rule-based scoring engine, not a physics model — the same distinction the tool's own "Under the hood" panel makes up front. Eight candidate causes each collect points from the answers that are real diagnostic evidence for them, direct observations (a marked arrow, a wobble on the spinner) outweigh the tear-direction inference, and a rest-move retest carries the heaviest single weight of all, because it's a result you produced, not a shape you're reading into a hole in paper.

2 Constants & Core Logic

// abridged — see papertune-core.js for the full 8-cause scoring function
if (horiz) {
  c.centershot += 30 * sizeMult;
  if (s.bow === 'compound') c.camlean += 15 * sizeMult;
}
if (s.dir !== 'clean' && s.afterMoves === 'closed') {
  var primary = horiz ? 'centershot' : (vert ? 'nockheight' : null);
  if (primary) c[primary] += 45;      // the retest result outweighs the initial tear reading
  c.spine = Math.max(0, c.spine - 20); // a tear that closes on a rest move argues against spine
}

3 Assumptions, Worked Example & References

The weights are a diagnostic ranking, not a probability — they encode how tuning technicians actually triage a tear (test before you adjust, adjust before you assume spine is wrong), which is why a clean rest-move retest can outweigh the entire initial tear reading. The engine deliberately never lets a low-confidence tear-direction guess outrank a result the archer actually produced by moving something and re-shooting.

Rest-position vs. cam-lean disambiguation follows the same rest-travel test discussed at length on Rokslide and covered in Bow International's technical breakdown of cam lean. Nock-pinch-mimicking-nocking-point-error pattern documented in a long ArcheryTalk thread on a stubborn nock-low tear.

1 Quick Summary

Gravity only pulls an arrow down, never along the shot's slant line, so an elevated or declined shot needs a shorter aim-point than the slant-range reading. This tool solves for the level ("true") distance whose flat-ground trajectory would produce the same drop as the actual angled shot, using the same exponential-drag model as the Trajectory Visualizer.

2 Formula & Code

function alphaReq(R, th, v, k) {
  var sp = pathLen(R, th, v, k), t = tof(sp, v, k);
  return 0.5*G*Math.cos(th)*t*t/sp;
}
function trueRange(R, th, v, k) { // bisection: alphaLevel(d) rises monotonically
  var want = alphaReq(R, th, v, k), lo = 0.4, hi = 250, mid;
  for (var i = 0; i < 60; i++) {
    mid = (lo+hi)/2;
    if (alphaLevel(mid, v, k) < want) lo = mid; else hi = mid;
  }
  return (lo+hi)/2;
}

3 Assumptions, Worked Example & References

This solves the actual trajectory equation for the equivalent level shot rather than using the popular cosine rule-of-thumb (level distance ≈ slant × cosθ) — the two agree closely at moderate angles and archery ranges, which the worked example below confirms, but the physics-based solve stays accurate at steeper angles where the cosine approximation drifts.

Angle-compensation principle documented in standard bowhunting ballistics references and rangefinder manufacturer manuals (e.g. Leupold, Vortex angle-compensating rangefinder documentation).

1 Quick Summary

Rated speed is adjusted for draw length and draw weight with the same flat per-unit coefficients used across the whole site, then scaled for real arrow-plus-string mass with a square-root mass-ratio term rather than the old "1 fps per 3 grains" flat penalty, which the tool's own source comment notes was off by 40+ fps at the heavy end.

2 Formula & Code

// estimate() now calls the site's one shared speed function directly —
// it used to run its own separate copy of this same formula.
var clamped = AETV.speedFps({ bow:'compound', ibo:st.ibo, dw:st.dw, dl:st.dl, aw:st.aw, sw:st.sw });
// (unclamped vBase*massRatio is still kept locally, only to flag the 100fps floor)

3 Assumptions, Worked Example & References

The rated-speed input is assumed to be an ATA-condition number (70 lb / 30 in / 350 gr) — an IBO number reads a few fps hot when run through this formula because IBO's own heavier draw-weight test condition already baked in extra speed the formula does not know to remove. The 30-grain "effective mass" constant represents string and cam-system inertia the bow always has to accelerate regardless of arrow weight, keeping the ratio from overstating speed gains at very light arrow weights.

Site-wide audit, September 2026: this page and the Trajectory & Sight-Pin Visualizer used to each carry their own separate copy of the same mass-ratio formula. They matched numerically, but two copies of one formula only stay identical until someone tunes one and forgets the other — the exact failure mode that split the Recurve Arrow Spine Calculator from the Arrow Build & GPI Weight Calculator earlier this month. This page's headline fps number now calls trajectory-core.js directly instead of hoping its own copy stays in sync. Verified against five preset builds spanning 280–620 grain arrows: identical output before and after, to floating-point precision.

IBO vs. ATA test conditions per the IBO's own published rules and the Archery Trade Association's ATA speed standard. Minimum 5 gr/lb safety floor is the manufacturer-published minimum used industry-wide to prevent dry-fire-equivalent limb shock.

1 Quick Summary

Wingspan divided by 2.5 is the primary read, height is a cross-check only and is never blended into the primary number, and a flat +0.5 in is added for recurve/traditional to account for a deeper anchor and more back tension.

2 Formula & Code

function estimate(span, height, bow) {
  var dlSpan = span/2.5;
  var dlHeight = (height-15)/2;
  var dl = dlSpan + (bow === 'recurve' ? 0.5 : 0);
  return { dl: dl, dlHeight: dlHeight, arrowLo: dl+1.0, arrowHi: dl+1.5 };
}

3 Assumptions, Worked Example & References

The wingspan/2.5 rule is the standard method published across the archery industry; height is included only to flag a likely bad wingspan measurement (the tool warns when the two disagree by 1 in or more) and never overrides the wingspan-based number. Arrow-cut length adds a flat 1.0–1.5 in for broadhead/riser clearance rather than modeling a specific rest and riser cutout.

Wingspan-to-draw-length method as published by Nock On Archery's draw-length fitting guide and used across archery pro-shop fitting practice.

1 Quick Summary

Total finished weight is shaft weight (direct entry, or length × GPI) plus point weight plus a fixed components preset lumping nock, vanes, wrap and insert together — a deliberately minimal three-number model for a tool built to answer one question fast.

2 Formula & Code

var COMP = { light: 20, standard: 35, heavy: 50 }; // grains
function shaftGrains(mode, length, gpi, shaft) {
  return (mode === 'lengthgpi') ? Math.round(length*gpi) : Math.round(shaft);
}
var total = shaftGrains(mode, length, gpi, shaft) + point + COMP[comp];

3 Assumptions, Worked Example & References

The Light/Standard/Heavy components preset (20/35/50 gr) lumps nock, vanes, wrap and insert into one number by design — the site's more detailed FOC & Balance Point Optimizer exists for anyone who needs each component weighed and positioned separately. This tool trades that precision for a three-input, under-a-minute answer.

Component weight ranges cross-checked against typical manufacturer-published nock, vane and insert weights (e.g. Easton's component catalog).

1 Quick Summary

Marked bow weight is adjusted for draw length, limb material, point weight and arrow length into one effective bow weight, then matched against a recurve-specific spine family table rebuilt directly off Easton's own recurve (finger-release) hunting chart — deliberately not the compound-bow table the Carbon Arrow Spine Calculator uses, since the two diverge sharply at lower poundage.

2 Inputs, Constants & Formula

var drawAdj = 2 * (drawlen - 28);
var limbAdj = (limb === 'trad') ? -5 : 0;      // wood/fiberglass vs carbon/foam-core
var pointAdj = 3 * (point - 125) / 25;
var lenAdj = 5 * (arrowlen - 28);
var eff = weight + drawAdj + limbAdj + pointAdj + lenAdj;

var FAMILY = [
  { hi: 26.999, label: '600–700' },  { hi: 36.999, label: '500–600' },
  { hi: 46.999, label: '400–500' },  { hi: 61.999, label: '340–400' },
  { hi: 72.999, label: '300–340' },  { hi: Infinity, label: '250–300' }
];

3 Assumptions & Limitations

• The point-weight rate and limb adjustment come directly from Easton's own published Target Shaft Selection chart; the draw-length rate (2 lb/in) is a conservative, widely cited AMO convention — some limbs run closer to 2.5–3 lb/in, so a bow scale reading at your real draw is the way to confirm it exactly.
• The FAMILY table was recalibrated in September 2026 directly against Easton's own recurve (finger-release) hunting chart at its 28in arrow-length column. An earlier version of this table briefly shared the Carbon Arrow Spine Calculator's compound-cam table, which reads far too soft at low poundage for recurve (a 22–26 lb recurve bow is roughly 600–700 spine on Easton's own chart, not 1000+) — the two tools now use separate, independently sourced tables.
• This is a starting-point selection model, not dynamic spine — it does not model how a specific cut shaft actually flexes in flight the way the Dynamic Spine & Shaft Flex Calculator does for compound bows.
• Single source of truth (added September 2026): the EffectiveWeight formula and FAMILY table now live in one shared file, /assets/js/ae-spine-core.js, loaded by this page, the Arrow Build & GPI Weight Calculator's recurve mode, and the Wood Arrow Spine Calculator. A previous version of the Arrow Build & GPI Weight Calculator used its own independent approximation (a flat "+120 spine units" offset for recurve/traditional) that disagreed with this table by a full shopping step or more across most of the practical draw-weight range — flagged by a reader comparing the two tools directly. Both tools now call the same recurveEffectiveWeight()/recurveTargetSpine() functions, so they cannot drift apart again silently.
• Shooting style (added September 2026): this tool and the Arrow Build & GPI Weight Calculator now offer an optional Olympic/Target, Barebow/Stringwalking, or Traditional/Instinctive selector. Barebow/stringwalking archers commonly report needing a weaker spine than a generic finger-release chart suggests, and community tuning writers (including well-known barebow-specific voices) echo this — but no manufacturer or standards body publishes a validated numeric offset for it, and the primary community threads with real reported numbers sit behind logins we could not independently verify. Rather than invent a coefficient, selecting Barebow or Traditional shows a plain-language disclosure instead of silently shifting the effective-weight number. Confirm the real number with a bareshaft tune.

4 Worked Example & References

Static-spine test per Easton's Making Sense of Arrow Spine and the ASTM F2031 breakdown at targetcrazy.com. Point-weight and limb-adjustment rates from Easton's own Arrow Shaft Selection chart. FAMILY table rebuilt from Easton's recurve bow spine chart.

1 Quick Summary

This tool runs the exact same Requirement/Capacity formula documented above for the Dynamic Spine & Shaft Flex Calculator — same cam multipliers, same front-weight and cut-length terms, same Capacity anchor table — just inverted: instead of grading one shaft's printed spine, it solves for the spine range whose Capacity falls inside the ±15 SMI Optimal Match band around your Requirement. A "starting range" here and an "Optimal Dynamic Match" reading there can never contradict each other for the same setup.

2 Inputs, Constants & Formula

var requirement = (weight * cam) + ((point - 100) / 10) * 3.5 - (29 - arrowlen) * 12;
var tol = 15 / 3.5;                     // Optimal-Match half-width, lbs-equivalent
var spineLo = spineForCapacity(requirement + tol);  // stiffer bound
var spineHi = spineForCapacity(requirement - tol);  // softer bound
// spineForCapacity() is the piecewise-linear inverse of the Dynamic Spine
// Calculator's own capacityForSpine() over the same CAP_ANCHORS table.

3 Assumptions & Limitations

• The Capacity table only covers 250–500 spine, same as the Dynamic Spine Calculator — a build that calls for something stiffer or weaker falls outside the model and the page shows an out-of-range warning.
• Because this reuses the Dynamic Spine Calculator's own point-weight (3.5 lb per 10 gr) and cam-multiplier rates rather than Easton's gentler published shopping-chart rates (roughly 3 lb per 25 gr point weight, an additive −10 to +15 lb cam range), a result here runs a little more sensitive than Easton's own online selector for identical inputs. This is intentional — it keeps every ArcheryEra tool that touches compound dynamic spine mathematically consistent with each other — not an attempt to reproduce Easton's chart cell-for-cell.
• Recurve and wood/traditional bows have no cam, so this Requirement/Capacity model does not apply to them; the Recurve and Wood Arrow Spine Calculators above and below use their own, separately sourced tables instead.

4 Worked Example & References

Static-spine test per Easton's Making Sense of Arrow Spine. Easton's own gentler comparison rates are published in its Arrow Shaft Selection (Hunting) chart. Full Requirement/Capacity derivation: Dynamic Spine & Shaft Flex Calculator methodology above.

1 Quick Summary

Marked bow weight is adjusted for draw length, bow style (center-shot recurve vs non-center-shot selfbow/longbow) and point weight into a floor value, then presented as an 8 lb-wide pound-rated shopping range — deliberately never converted into a carbon .300/.400-style spine number, since no solid cross-material conversion exists.

2 Inputs, Constants & Formula

// drawAdj/pointAdj/lenAdj now call ae-spine-core.js (shared with the
// Recurve Arrow Spine Calculator) instead of running their own copy.
var drawAdj = AESpine.drawLengthAdj(drawlen);
var styleAdj = (style === 'selfbow') ? -3 : 0;   // non-center-shot archer's-paradox adjustment, local to this tool
var pointAdj = AESpine.pointWeightAdj(point);
var lenAdj = AESpine.arrowLengthAdj(arrowlen);
var floor = weight + drawAdj + styleAdj + pointAdj + lenAdj;
var range = [Math.round(floor), Math.round(floor) + 8];

3 Assumptions & Limitations

• The 8 lb range width sits inside — but is not itself lifted from — 3Rivers Archery's documented guidance that experienced shooters run a shaft rated roughly 5–10 lb stiffer than actual draw weight; the range floor is your build-adjusted bow weight, not that guidance's own starting point.
• Wood is a natural material: grain, density and moisture content all shift a given shaft's real spine around its printed rating, which is exactly why wood shafts are sold pre-sorted into pound ranges rather than exact numbers in the first place. This tool never fabricates a carbon-equivalent number for that reason.
• No Simulation Lab tool currently models wood/traditional dynamic spine, so unlike the Carbon Arrow Spine Calculator, there is no sibling Requirement/Capacity formula for this tool to stay consistent with — its adjustment directions and magnitudes are cross-checked against 3Rivers Archery's and Easton's own recurve/traditional guidance instead.
• Site-wide audit, September 2026: the draw-length, point-weight and arrow-length adjustment terms used to be this page's own separate copy of the identical arithmetic already used by the Recurve Arrow Spine Calculator's effective-weight model. Both pages now call the same ae-spine-core.js functions for those three terms, so they can no longer drift apart the way the Recurve Arrow Spine Calculator and the Arrow Build & GPI Weight Calculator did. The selfbow/non-center-shot style adjustment stays local — it is not shared with any other tool's formula, so there was nothing to unify there.

4 Worked Example & References

Pound-rated wood spine convention and the 5–10 lb stiffer-than-draw-weight guidance for experienced shooters from 3Rivers Archery's published spine selection charts.

1 Quick Summary

This tool doesn't invent a new sizing system. It layers directly on the same three-class diameter taxonomy (Micro/4mm, Small/5mm, Standard/6.5mm) the Arrow Shaft Finder already uses, then maps each class to the nock letter code and bushing product name that physically fits its bore. Pick a catalogued shaft or type a measured inside diameter, and it returns the matching component names instead of a spine number.

2 Constants & Core Logic

function classifyId(inches) {
  var d = { micro: Math.abs(inches-0.1655), small: Math.abs(inches-0.204), standard: Math.abs(inches-0.245) };
  var best = 'micro', bestD = d.micro;
  ['small','standard'].forEach(function (k) { if (d[k] < bestD) { best = k; bestD = d[k]; } });
  var sorted = Object.keys(d).sort(function (a, b) { return d[a]-d[b]; });
  var ambiguous = (d[sorted[1]] - d[sorted[0]]) < 0.012; // within ~.012in of a tie
  return { key: best, ambiguous: ambiguous };
}

3 Assumptions, Worked Example & References

The 18-shaft catalog is the same list and the same dia-class bucket already assigned in the Arrow Shaft Finder — this tool deliberately does not maintain a second, independent dataset that could drift out of sync with it. Two shafts in that list (Easton FMJ 6mm and Easton 5mm FMJ Max) carry a hybrid:true flag: their aluminum-carbon "Full Metal Jacket" construction uses Easton's own HIT (Hidden Insert Technology) system and a Broadhead Alignment Ring rather than a generic bushing of their numeric class, and the tool surfaces that distinction instead of quietly recommending a part that won't seat correctly.

Bore-size-based component naming confirmed on Easton's own bushings product category page, which lists the G/X/S nock pairing directly in each bushing's product description, including the HIT and Broadhead Alignment Ring references for FMJ construction. Nock letter codes cross-checked against Feradyne's published Nockturnal nock-to-ID size chart.