API Marketplace

Indoor-rowing (Concept2 erg) maths as an API, computed locally and deterministically — the watts, split and calorie numbers a rower, coach or fitness app works a piece out with, using the published Concept2 relations. The split-to-watts endpoint turns a 500 m split into power: on an erg the power is fixed by the pace, not the stroke rate, so watts = 2.80 ÷ pace³ where the pace is the seconds per metre (the split ÷ 500) — a 2:00 split is about 202 W. Because power goes as the inverse cube of pace, small split gains cost a lot of watts: pulling 1:50 instead of 2:00 is roughly 270 W, not 220. The watts-to-split endpoint inverts it — pace = (2.80 ÷ watts)^(1/3), split = pace × 500 — so a target wattage maps to the split on the monitor and a rower's power compares directly with a cyclist's or any other watts figure. The calories endpoint applies the Concept2 calorie formula, Cal/hr = (watts × 4 × 0.8604) + 300, where the +300 is a fixed resting-metabolism term that makes the erg's count run higher than pure mechanical work; 200 W is about 988 Cal/hr, roughly 494 calories over 30 minutes. Everything is computed locally and deterministically, so it is instant and private. Ideal for rowing and erg training tools, coaching and leaderboard apps, and fitness calculators. Pure local computation — no key, no third-party service, instant. Concept2 model — a machine estimate, not lab calorimetry. 3 compute endpoints. For running pace use a pace API; for cycling a cycling API.

Tempo di attività

100.0%

Latenza

76ms

Abbonati

3,356

Cross-stitch and embroidery maths as an API, computed locally and deterministically — the design-size, fabric and floss numbers a cross-stitcher, embroidery designer or needlework-shop works a project out with. The design-size endpoint turns a stitch count and a fabric count (stitches per inch) into the finished size: size = stitch count ÷ fabric count, so a 140 × 98 design on 14-count Aida finishes at 10 × 7 inches (25.4 × 17.8 cm), smaller on 18-count and larger on 11-count because a higher count packs more stitches per inch — and it returns the total stitch count (width × height) that drives the floss and the hours. The fabric-needed endpoint adds a margin on every side to give the fabric to cut: design size + twice the margin per dimension, with the usual 3 inches per side for hooping, framing and finishing, so a 10 × 7 design wants a 16 × 13 inch cut. The thread-length endpoint estimates floss from the geometry of a full cross — the front two diagonals plus the back returns is about (2√2 + 2) ÷ fabric count inches per stitch — so 5,000 stitches on 14-count is roughly 1,724 inches, about 44 m, and it estimates the skeins given the number of strands (a 6-strand skein is ~8 m). Everything is computed locally and deterministically, so it is instant and private. Ideal for cross-stitch and embroidery pattern tools, needlework-shop and kit apps, and craft-project calculators. Pure local computation — no key, no third-party service, instant. Floss figures are planning estimates — buy a little extra and dye-lot match. 3 compute endpoints. For sewing yardage use a sewing API; for knitting gauge a knitting API.

Tempo di attività

100.0%

Latenza

77ms

Abbonati

4,435

Ice-cream and gelato batch maths as an API, computed locally and deterministically — the overrun, yield and solids numbers a gelatiere, ice-cream maker or production planner balances a mix by. The overrun endpoint measures the air whipped into the mix during freezing by the weight method: from the same container filled first with mix and then with frozen ice cream, overrun = (mix weight − frozen weight) ÷ frozen weight × 100 — a cup that drops from 1000 g to 625 g ran 60 % overrun. Dense gelato sits around 20–35 %, premium ice cream 25–50 %, soft-serve and economy tubs 50–100 %+; more air means a lighter, cheaper, faster-melting product. The yield endpoint turns a mix volume and an overrun into the frozen volume (mix × (1 + overrun/100)) and the number of scoops at a given scoop size, so 2 litres of mix at 60 % overrun yields 3.2 litres and about 53 sixty-millilitre scoops — which is why overrun is a direct cost lever. The total-solids endpoint balances a recipe: total solids (sugar + fat + milk-solids-not-fat + other) as a percent of the mix weight, with the fat, sugar, MSNF and water percentages — a typical ice cream runs 36–42 % total solids, gelato lower in fat, and balancing solids against water is what keeps the texture smooth rather than icy. Everything is computed locally and deterministically, so it is instant and private. Ideal for gelateria and creamery tools, recipe-balancing apps, and food-production calculators. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For general cooking measure conversions use a cooking API.

Tempo di attività

100.0%

Latenza

75ms

Abbonati

4,166

Wood-moisture maths as an API, computed locally and deterministically — the moisture-content, oven-dry-weight and drying-target numbers a woodworker, sawyer, kiln operator or firewood seller weighs timber by. The moisture-content endpoint takes a wet weight and an oven-dry weight and returns the moisture content on both conventions: the dry basis (water ÷ oven-dry weight × 100, the forestry and woodworking standard) and the wet/green basis (water ÷ wet weight × 100, common in agriculture and paper) — a board weighing 120 g that dries to 100 g holds 20 g of water and is 20 % dry-basis or 16.7 % wet-basis, so it always matters which is quoted. Above fibre saturation (~28–30 %) the wood is still shedding free water and has not begun to shrink. The dry-weight endpoint back-calculates the unchanging oven-dry weight from a current weight and a meter reading (wet ÷ (1 + MC/100)), the anchor for any drying plan because the wood substance does not change as water leaves. The target-weight endpoint uses that anchor to give the weight a piece should reach for a target moisture content and the water still to drive off — taking 120 g at 20 % down to 12 % means a 112 g target and 8 g of water to lose, so you simply weigh the piece down to that figure. Everything is computed locally and deterministically, so it is instant and private. Ideal for woodworking and lutherie tools, sawmill and kiln-drying apps, and firewood-seasoning calculators. Pure local computation — no key, no third-party service, instant. Mass-balance maths — pair it with a real moisture meter. 3 compute endpoints. For board feet use a lumber API; for a wood-stack volume a firewood API.

Tempo di attività

100.0%

Latenza

78ms

Abbonati

4,875

Gemstone weight maths as an API, computed locally and deterministically — the carat, gram, point and measured-weight numbers a jeweller, gem dealer, appraiser or lapidary works to. The carat-to-grams endpoint converts a carat weight to grams, milligrams and points: the metric carat is exactly 0.2 g (200 mg) and is split into 100 points, so a 1.5 ct stone is 0.3 g and 150 points and a quarter-carat is a twenty-five pointer — the carat is a mass unit, not a size, so a 1 ct diamond and a 1 ct emerald weigh the same but look different because their densities differ. The grams-to-carat endpoint inverts it (divide grams by 0.2, or multiply by 5), for a weight taken on a gram balance. The round-brilliant-weight endpoint gives the trade estimate used when a stone is set and cannot be put on a scale: carat ≈ diameter² × depth × 0.0061, with the girdle diameter and total depth in millimetres — a 6.5 mm round about 4 mm deep estimates near 1 carat, which is exactly why a 1 ct round brilliant measures roughly 6.5 mm across; the factor can be nudged for a thick girdle or a different cut. Everything is computed locally and deterministically, so it is instant and private. Ideal for jewellery and appraisal tools, gem-dealer and auction apps, and lapidary calculators. Pure local computation — no key, no third-party service, instant. Weight maths only — it does not price the stone or grade the colour and clarity. 3 compute endpoints. For gold karat and fineness use a gold-purity API.

Tempo di attività

100.0%

Latenza

79ms

Abbonati

3,955

Gold purity and karat maths as an API, computed locally and deterministically — the karat, fineness and alloy numbers a jeweller, goldsmith, assayer or refiner works to. The karat-to-fineness endpoint converts between the two purity systems: karat is the number of 24ths of a piece that is pure gold, so the fineness (parts per thousand, the figure on a hallmark stamp) = karat ÷ 24 × 1000 and the gold percentage = karat ÷ 24 × 100 — 24K is pure (1000‰), 18K is 750‰ (75 %), 14K is 583‰, 9K is 375‰. The pure-gold-weight endpoint gives the actual fine gold in a piece = its total weight × the gold fraction (karat ÷ 24): a 10 g 18K ring holds 7.5 g of gold and 2.5 g of alloy, the fine-gold content a refiner pays on and the basis of the intrinsic metal value. The alloy-mix endpoint inverts it for the bench: to bring refined fine gold down to a target karat, the total weight = the fine gold ÷ (target karat ÷ 24) and the alloy to add = the total − the fine gold, so 7.5 g of pure gold makes 10 g of 18K with 2.5 g of master alloy. Everything is computed locally and deterministically, so it is instant and private. Ideal for jewellery and goldsmithing tools, pawn and scrap-gold apps, and assay and metal-value calculators. Pure local computation — no key, no third-party service, instant. Purity maths only — it does not fetch the live gold price. 3 compute endpoints. For a metal part's weight from its dimensions use a metal-weight API.

Tempo di attività

100.0%

Latenza

75ms

Abbonati

3,617

Circular-segment arch geometry as an API, computed locally and deterministically — the radius, arc-length and set-out numbers a mason, joiner, stonemason or CAD user lays a segmental arch out with. A segmental arch is an arc of a circle struck through the two springings and the crown: the from-span-rise endpoint takes the span and the rise (the height of the crown above the springing line) and returns the radius = (span²/4 + rise²) ÷ (2·rise), the central angle it subtends, the arc length along the curve, and the segment area of the void below it — flatter arches with a small rise have surprisingly huge radii. The from-radius-angle endpoint inverts it, returning the chord (span), the rise (sagitta), the arc length and the area from a known radius and central angle, the way a curve struck with a trammel or a router on a pivot is described. The setout-ordinates endpoint gives the practical numbers to mark a template: the rise of the arc above a straight base line at equally spaced stations across the span (y = √(R² − x²) − (R − rise)), so you can plot the heights, connect them and cut a plywood former or bend a batten without a giant compass — the ends come out zero at the springings and the middle equals the rise at the crown. Everything is computed locally and deterministically, so it is instant and private. Ideal for masonry and joinery layout tools, stair and window-head design, and CAD and woodworking calculators. Pure local computation — no key, no third-party service, instant. Segmental (up to a semicircle) arcs. 3 compute endpoints. For road curves use a horizontal- or vertical-curve API; for plain shape areas a geometry API.

Tempo di attività

100.0%

Latenza

78ms

Abbonati

4,123

Riveted-joint strength maths as an API, computed locally and deterministically — the shear, bearing and rivet-count numbers a structural, sheet-metal or aircraft fitter checks a riveted connection by. The shear-capacity endpoint gives the load a rivet group carries across its shanks = the rivet area (π/4·d²) × the shear strength × the number of rivets × the shear planes — a rivet in single shear is cut on one plane, in double shear (the centre plate of a butt joint with cover plates) on two, so it carries twice. The bearing-capacity endpoint gives the load the rivets can press against the sides of their holes before the plate crushes = the projected contact area (diameter × plate thickness) × the bearing strength × the number of rivets; thin plates fail in bearing long before the rivet shears, which is exactly why both must be checked — the joint strength is the lesser of the two. The rivets-required endpoint inverts it: the rivets a design load needs = the load ÷ the allowable load per rivet (area × allowable shear × planes), rounded up to a whole rivet, using the working shear (strength ÷ safety factor) not the raw value. Everything is computed locally and deterministically, so it is instant and private. Ideal for structural and sheet-metal estimating, mechanical-design and fastener tools, and engineering calculators. Pure local computation — no key, no third-party service, instant. Shank-shear and bearing only — also confirm edge tear-out and minimum pitch. 3 compute endpoints. For bolt preload and torque use a bolt-torque API; for thread geometry a thread API; for welded joints a welding API.

Tempo di attività

100.0%

Latenza

78ms

Abbonati

4,075

Tensioned-line point-load statics as an API, computed locally and deterministically — the line-tension and anchor-force numbers a slackliner, highliner or rigger works out before they weight a line. This is the V a loaded line makes under a person, not a self-weight catenary: the tension endpoint takes the span, the sag and the body load and returns the line tension and the horizontal anchor pull, because vertical balance is 2·T·sin(angle) = the body weight — so the flatter the line (the smaller the sag) the more the tension blows up, which is exactly why drum-tightening a line to kill the bounce can load the anchors to many times body weight. The sag endpoint inverts it: from a known line tension it returns the sag a mid-span load settles to (sin angle = weight ÷ twice the tension), and flags when the tension is too low to hold the load at all. The off-centre-load endpoint handles standing away from the middle, where the two halves carry different tensions: the horizontal pull is equal on both sides (H = weight × a × b ÷ (sag × span)) but the shorter, steeper segment runs at the higher tension and fails first — the reason a highliner near an anchor stresses that leash harder than one in the centre. Everything is computed locally and deterministically, so it is instant and private. Ideal for slackline and highline rigging tools, climbing and outdoor-gear apps, and tension-and-anchor calculators. Pure local computation — no key, no third-party service, instant. Geometric statics — combine with the real webbing and anchor ratings. 3 compute endpoints. For a self-weight hanging cable use a catenary API; for working-load-limit and safety factor a rigging API.

Tempo di attività

100.0%

Latenza

68ms

Abbonati

3,192

Textile-dyeing recipe maths as an API, computed locally and deterministically — the dye, water and auxiliary numbers a dyer weighs out to mix a repeatable dye-bath, whether for a swatch or a full bolt. The dye-weight endpoint gives the dye to weigh = the weight of fabric × the depth of shade, the percentage of dye on the weight of the goods: a 2 % shade on 100 g of fabric is 2 g of dye, pale shades run under half a percent, deep blacks 4 % or more — working on-weight-of-fabric is exactly what makes a recipe scale and repeat. The liquor-ratio endpoint gives the dye-bath volume = the weight of goods in kilos × the liquor ratio, the litres of bath per kilo (a 20:1 ratio is 20 L per kg); lower ratios save water, dye and energy and exhaust deeper, higher ratios level more evenly on delicate or pale work. The auxiliary endpoint gives the salt, soda ash or levelling agent to add = the bath volume × the dosing concentration in grams per litre — salt (50–80 g/L) drives reactive and direct dyes onto cotton, soda ash (10–20 g/L) raises the pH to fix them. Everything is on-weight or per-litre, so the same recipe gives the same colour and chemistry at any scale, and it is computed locally and deterministically, so it is instant and private. Ideal for craft and studio dyers, textile and yarn shops, and dye-recipe and batch-calculator tools. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For knitting yardage and gauge use a knitting API; for vegetable-ferment or meat-cure salt a fermentation or curing API.

Tempo di attività

100.0%

Latenza

77ms

Abbonati

4,009

Solar-array row-spacing and shading geometry as an API, computed locally and deterministically — the shadow-length, inter-row-spacing and ground-coverage numbers a PV designer or installer lays a ground-mount or flat-roof array out with. The shadow-length endpoint gives the shadow an object casts = its height ÷ tan(sun elevation), longer the lower the sun (which is why layouts are designed for the worst-case winter-solstice low sun), stretched by 1/cos(azimuth difference) when the sun is off-axis. The row-spacing endpoint gives the minimum row pitch (front edge to front edge) to stop a row shading the one behind = the module's horizontal base (length × cos tilt) + the shadow its back edge casts (module height ÷ tan of the minimum sun elevation) — a 1.7 m module at 30° tilt clearing a 20° winter sun needs about a 3.8 m pitch — and returns the resulting ground coverage ratio. The ground-coverage endpoint gives that GCR = module length ÷ row pitch, the packing density: fixed-tilt fields typically run 0.4–0.5, higher packs more kW per acre but loses winter yield to mutual shading, lower wastes land. Everything is computed locally and deterministically, so it is instant and private. Ideal for solar-design and layout tools, EPC and site-assessment apps, and renewable-energy calculators. Pure local computation — no key, no third-party service, instant. Geometric model — use the real worst-hour sun altitude. 3 compute endpoints. For solar position/altitude use a solar-position API; for irradiance a solar API; for off-grid sizing an off-grid API.

Tempo di attività

100.0%

Latenza

79ms

Abbonati

3,276

Winch and cable-drum maths as an API, computed locally and deterministically — the rope-capacity, line-pull and rope-out numbers a winch operator, rigger or recovery driver works a drum with. The capacity endpoint gives the rope a drum holds by exact layer geometry: the sum over every full layer of the turns per layer × π × that layer's mean wrap diameter, where turns per layer = drum width ÷ rope diameter and the number of layers = the flange-to-barrel depth ÷ rope diameter — a 10-inch barrel, 20-inch flange, 12-inch-wide drum on half-inch rope holds about 940 ft over 10 layers. The layer-pull endpoint shows why pull falls as the drum fills: the rated pull is for the bare-drum first layer, and as rope piles on, the growing lever arm cuts the line pull and raises the line speed in the same ratio — pull × (first-layer diameter ÷ this layer's diameter) — so the top layer of a deep drum can pull barely half the bottom-layer rating, which is why you spool off to bare drum for a hard pull or add a snatch block. The length-at-layer endpoint gives the rope wound after a number of full layers, for marking the rope or knowing how much line is out. Everything is computed locally and deterministically, so it is instant and private. Ideal for winch- and hoist-sizing tools, recovery and off-road apps, marine and industrial-rigging utilities, and engineering calculators. Pure local computation — no key, no third-party service, instant. Geometric estimate — allow for nesting and freeboard. 3 compute endpoints. For capstan friction use a capstan API; for block-and-tackle a pulley API.

Tempo di attività

100.0%

Latenza

76ms

Abbonati

4,761

Mobile-Crane-Lift-Planungsmathematik als API, lokal und deterministisch berechnet – die Lastmoment-, Kippkapazitäts- und Abstützplattenzahlen, die ein Kranführer, Liftplaner oder Rigging-Ingenieur bei einem Hub überprüft. Der Lastmoment-Endpunkt gibt die Last × ihren Arbeitsradius (den horizontalen Abstand vom Drehzentrum zum Haken), die einzelne Zahl, die der Tragfähigkeitsbegrenzer eines Krans überwacht: Eine 5-Tonnen-Last bei 8 m ergibt ein Moment von 40 Tonnenmetern, dasselbe wie 10 Tonnen bei 4 m, weshalb die Diagrammkapazität steil abfällt, wenn der Ausleger ausfährt – das Moment, nicht das Gewicht, kippt den Kran. Der Kapazitätsendpunkt gibt eine vereinfachte Kippbilanz um den Drehpunkt: Die Last, die gerade kippt = Gegengewicht × sein Radius ÷ Lastradius, und die zulässige sichere Last ist ein Stabilitätsbruchteil davon (~75 % auf Abstützungen, ~66 % auf Raupen gemäß den Normen) – eine Lehr-/Plausibilitätszahl, die den Ausleger und das Überbaugerät ignoriert, niemals ein Ersatz für das Lastdiagramm. Der Abstützplattenendpunkt dimensioniert die Tellerplatte: Erforderliche Plattenfläche = Abstützbeinlast ÷ zulässiger Bodendruck (und die Seite einer quadratischen Matte), da Überlastung von schwachem Boden eine Hauptursache für Umkippen ist – ein 30-Tonnen-Bein auf 200 kPa benötigt etwa eine 1,2 m quadratische Matte. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Liftplanungs- und Rigging-Tools, Bau- und Kranbetriebs-Apps sowie Baustellensicherheitsdienstprogramme. Reine lokale Berechnung – kein Key, kein Drittanbieterdienst, sofort. Vereinfacht – verwenden Sie immer das Lastdiagramm des Herstellers. 3 Compute-Endpunkte. Verwenden Sie für Anschlag- und WLL-Lasten eine Rigging-API.

Tempo di attività

100.0%

Latenza

79ms

Abbonati

4,593

Traction-elevator engineering maths as an API, computed locally and deterministically — the counterweight, hoist-motor and rope-traction numbers a lift engineer or building-services designer sizes a passenger elevator with. The counterweight endpoint gives the balancing mass = the empty car plus a fraction of the rated load (the overbalance, typically 40–50 %, 45 % common), so a 1,000 kg car rated for 1,000 kg uses a 1,450 kg counterweight — the car and weight balance near half load and the machine is sized for the worst-case imbalance, not the full load. The motor-power endpoint uses that: because the counterweight cancels most of the car, the motor only lifts the out-of-balance load = rated load × (1 − overbalance), so power = that × g × speed ÷ efficiency (~65–75 % geared) — a 1,000 kg lift at 1.5 m/s needs only about 11–12 kW, half what a counterweight-less hoist would draw. The traction-ratio endpoint checks the friction grip: a traction elevator moves the ropes by friction over the sheave, so the available traction (e^(μθ), the capstan equation) must beat the T1/T2 tension ratio at both worst cases — a full car at the bottom and an empty car at the top — and it returns the governing ratio. Everything is computed locally and deterministically, so it is instant and private. Ideal for lift-design and building-services tools, vertical-transport and MEP utilities, and engineering calculators. Pure local computation — no key, no third-party service, instant. Sizing estimates — follow the lift code and maker data. 3 compute endpoints. For block-and-tackle use a pulley API; for capstan friction a capstan API.

Tempo di attività

100.0%

Latenza

78ms

Abbonati

3,189

Railway train-performance maths as an API, computed locally and deterministically — the tractive-effort, resistance and adhesion numbers a railway engineer, train planner or rail-sim developer rates motive power with. The tractive-effort endpoint gives the pulling force a locomotive develops = 375 × horsepower × efficiency ÷ speed (mph), the classic hyperbolic curve where a constant-power loco pulls hardest at low speed and tapers as it accelerates — 4,000 hp at 25 mph and 82 % efficiency is about 49,200 lbf at the rail. The resistance endpoint gives the forces a train fights: grade resistance ≈ 20 lb per ton per 1 % of grade (the weight component along the slope, the dominant force on a hill — a 5,000-ton train on a 1 % grade fights 100,000 lbf) plus curve resistance ≈ 0.8 lb per ton per degree of curve from flange friction. The adhesion endpoint gives the hard ceiling: however much power a loco has, it can only pull as hard as the wheels grip — maximum starting tractive effort = the adhesion coefficient (≈ 0.25 dry, more with sand) × the weight on the driving wheels, so 200 tons on the drivers is about 100,000 lbf before slip. Everything is computed locally and deterministically, so it is instant and private. Ideal for rail-operations and motive-power planning tools, train-simulator and railfan apps, and transport-engineering utilities. Pure local computation — no key, no third-party service, instant. Excludes the speed-dependent Davis rolling/air resistance. 3 compute endpoints. For highway curve geometry use a horizontal-curve API.

Tempo di attività

100.0%

Latenza

75ms

Abbonati

3,272

Sea-horizon and visibility maths as an API, computed locally and deterministically — the distance-to-horizon, geographic-range and dip numbers a mariner, coastal navigator or marine app works sightings with. The horizon endpoint gives the distance to the sea horizon ≈ 1.169·√(height of eye in feet) nautical miles, including the standard atmospheric refraction that bends the line of sight a little past the geometric edge — at 9 ft of eye height the horizon is about 3.5 nm off — together with the dip, how far below true horizontal that watery edge lies (≈ 0.97′·√h), the correction subtracted from a sextant altitude shot to the sea horizon. The geographic-range endpoint gives how far off a light or landmark first peeps over the horizon = the sum of two horizon distances, your own plus the object's: 1.169·(√h_eye + √h_object), so a 100 ft lighthouse from a 9 ft cockpit lifts above the sea at about 15 nm — purely geometric, before the light's own luminous range and the visibility. The object-height endpoint inverts it: how tall a tower, light or headland must stand to break the horizon at a target range, or how close you must be before a known landmark appears. Everything is computed locally and deterministically, so it is instant and private. Ideal for marine-navigation and chartplotter apps, coastal-pilotage and lighthouse tools, and sailing utilities. Pure local computation — no key, no third-party service, instant. Geometric/refraction model. 3 compute endpoints. For great-circle distance use a geo-distance API; for set & drift a set-and-drift API.

Tempo di attività

100.0%

Latenza

85ms

Abbonati

3,283

Current-sailing (set and drift) navigation maths as an API, computed locally and deterministically — the course-over-ground, course-to-steer and current numbers a mariner, navigator or marine app plots a passage with. The course-made-good endpoint adds the boat's velocity through the water to the current vector to give the real track: the course over ground (COG) and speed over ground (SOG), with the drift angle the current pushes you off your nose — steering 090° through the water at 10 knots with a 2-knot current setting north comes out around 079° over the ground at 10.2 knots. The course-to-steer endpoint solves the other way: the heading to steer to make good a desired ground track, steering up-current to cancel the across-track set (sin(H−T) = −drift·sin(set−track) ÷ speed), and the resulting SOG — usually slower into a current, faster with it astern, and impossible if the current across the track beats your speed. The current endpoint finds the set and drift from the offset between a dead-reckoning position and an observed fix: the set is the bearing DR-to-fix and the drift is that distance ÷ the elapsed time, ready to carry forward. Everything is computed locally and deterministically, so it is instant and private. Ideal for marine-navigation and chartplotter apps, sailing and boating tools, and maritime-training utilities. Pure local computation — no key, no third-party service, instant. Degrees true. 3 compute endpoints. For great-circle distance use a geo-distance API; for tide times a tides API.

Tempo di attività

100.0%

Latenza

79ms

Abbonati

4,178

Hay and forage bale maths as an API, computed locally and deterministically — the weight, dry-matter and feed-supply numbers a rancher, hay producer or livestock manager plans winter feed with. The round-bale endpoint gives the weight from the cylinder volume (π·r²·width) × the dry-matter density (typically ~9–12 lb/ft³ for cured hay), so a 5×5 ft bale runs about 1,000 lb, and reports the dry-matter weight (≈88 % of as-fed) that actually feeds the animals — buy and ration on dry matter, not gate weight. The square-bale endpoint gives the weight of a rectangular bale from its length, width and height (÷ 1,728 for cubic feet from inches) × the density — a typical 14×18×36-inch small square is about 50 lb, big 3×3 or 4×4 ft bales hundreds — with a reminder that high moisture both adds weight and risks mould and barn-fire heating. The feed-supply endpoint sizes the stack: feed needed = head × daily intake × days (cattle eat ~2–2.5 % of bodyweight, about 25–30 lb of dry matter for a beef cow), and bales = that ÷ the bale weight, so 30 cows for 120 days at 30 lb is about 108 thousand-pound bales — add 10–20 % for feeding waste. Everything is computed locally and deterministically, so it is instant and private. Ideal for ranch- and farm-management tools, hay-trading and livestock apps, and ag calculators. Pure local computation — no key, no third-party service, instant. US units; densities are estimates. 3 compute endpoints. For grain storage use a grain-bin API; for rotational grazing a grazing API.

Tempo di attività

100.0%

Latenza

75ms

Abbonati

3,845

Planting seed-rate maths as an API, computed locally and deterministically — the plant-population, seed-spacing and seeding-rate numbers a farmer, agronomist or precision-ag tool sets a planter or drill to. The population endpoint gives the plants per acre = 6,272,640 ÷ (row spacing × in-row seed spacing) in inches (the 6,272,640 is the square inches in an acre), so 30-inch rows with seeds 6 inches apart give about 34,800 plants per acre — closer spacing raises the population and the competition. The seed-spacing endpoint runs it the other way: the in-row spacing for a target population = 6,272,640 ÷ (target plants × row spacing), so 35,000 plants per acre in 30-inch rows means a seed about every 6 inches, the value to set on a singulating meter or seed-rate drive. The seeding-rate endpoint gives the pounds of seed per acre = the target population ÷ the germination rate ÷ the seeds per pound, over-seeding for the seeds that never come up — 35,000 plants of a 1,500-seeds-per-lb crop at 95 % germination needs about 24.6 lb/acre, working from the seed lot's own tag. Everything is computed locally and deterministically, so it is instant and private. Ideal for precision-ag and farm-management tools, planter-calibration and agronomy apps, and seed-retail utilities. Pure local computation — no key, no third-party service, instant. US units. 3 compute endpoints. For sprayer rates use a spray API; for fertiliser a fertilizer API.

Tempo di attività

100.0%

Latenza

76ms

Abbonati

4,531

Landwirtschaftliche Spritzentechnik als API, lokal und deterministisch berechnet – die Kalibrierungs-, Flächenleistungs- und Tankmischzahlen, mit denen ein Landwirt, Agronom oder Lohnunternehmer eine Feldspritze einstellt. Der Kalibrierungs-Endpoint liefert die Ausbringungsmenge in GPA = 5940 × der Düsendurchfluss (GPM) ÷ (Fahrgeschwindigkeit in mph × Düsenabstand in Zoll), wobei die 5940 die Einheiten für einen vollflächigen Gestänge umrechnet – eine 0,4 GPM-Düse bei 5 mph und 20-Zoll-Abstand bringt etwa 24 Gallonen pro Acre aus, und schnelleres Fahren oder größerer Düsenabstand senkt die Rate. Der Flächenleistungs-Endpoint liefert die Acres, die ein Tank bedeckt (Tank ÷ GPA), und für eine Feldgröße das gesamte Spritzvolumen und die Anzahl der Tankladungen, wobei die letzte Teilfüllung separat ausgewiesen wird, damit sie auf die restlichen Acres gemischt werden kann. Der Produkt-Endpoint liefert das Pflanzenschutzmittel oder den Nährstoff pro Tank = die Acres pro Tank × die Aufwandmenge pro Acre (in der Einheit der Aufwandmenge – Unzen, Pints, Pfund), plus das Gesamtprodukt für das Feld. Alles wird lokal und deterministisch berechnet, daher sofort und privat. Ideal für Präzisionslandwirtschafts- und Betriebsführungstools, Spritzenkalibrierungs- und Tankmisch-Apps sowie landwirtschaftliche Einzelhandelsdienstleistungen. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Befolgen Sie stets das Produktetikett und kalibrieren Sie mit einem echten Auffangtest. 3 Compute-Endpoints. Für Düngemittelraten verwenden Sie eine Dünger-API; für Beregnungs-/Bewässerungsplanung eine Bewässerungs-API.

Tempo di attività

100.0%

Latenza

75ms

Abbonati

3,615

RTD (Widerstands-Temperatur-Detektor) Sensor-Mathematik als API, lokal und deterministisch mit der IEC 60751 Callendar-Van Dusen Gleichung berechnet – die Widerstands-, Temperatur- und Toleranzzahlen, die ein Instrumentierungs- oder Steuerungsingenieur von einem Pt100 oder Pt1000 abliest. Der Widerstands-Endpunkt gibt den Sensorwiderstand aus der Temperatur: über 0 °C, R = R₀·(1 + A·T + B·T²) mit A = 3,9083×10⁻³ und B = −5,775×10⁻⁷; unter 0 °C fügt ein dritter Term C·(T−100)·T³ hinzu – ein Standard-Pt100 (100 Ω bei 0 °C) zeigt 138,51 Ω bei 100 °C und 80,31 Ω bei −50 °C, und ein Pt1000 ist das Zehnfache. Der Temperatur-Endpunkt kehrt dies um, um einen gemessenen Widerstand wieder in Temperatur umzuwandeln – analytisch über 0 °C, iterativ darunter – genau das, was ein Messumformer mit der Brückenablesung macht, und eine Erinnerung daran, dass eine 3- oder 4-Leiter-Verbindung den Leitungswiderstand aufhebt, sodass er nicht als zusätzliche Grad gelesen wird. Der Toleranz-Endpunkt gibt die IEC 60751 Genauigkeitsband in °C und Ω nach Klasse an – AA ±(0,10 + 0,0017·|T|), A ±(0,15 + 0,002·|T|), B ±(0,30 + 0,005·|T|), C ±(0,60 + 0,010·|T|) – der Fehler wächst mit der Entfernung von 0 °C. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Instrumentierungs- und Steuerungssoftware, Datenlogger- und Messumformer-Firmware, Kalibrierungs- und industrielle IoT-Tools. Reine lokale Berechnung – kein Key, kein Drittanbieter-Dienst, sofort. 3 Compute-Endpunkte. Für NTC-Thermistoren verwenden Sie eine Thermistor-API; für Thermoelemente eine Thermoelement-API.

Tempo di attività

100.0%

Latenza

77ms

Abbonati

4,661

Sauna-Heizer-Berechnungen als API, lokal und deterministisch berechnet – die Heizleistung, Steinmasse und elektrischen Werte, die ein Saunabauer, Installateur oder Wellnesshändler für eine Kabine dimensioniert. Der Heizgrößen-Endpoint gibt die Leistung: etwa 1 kW pro 1,3 m³ gut isolierter Kabine (Raumvolumen ÷ 1,3), wobei kalte Oberflächen, die der Heizer ebenfalls erwärmen muss – eine Glastür oder -wand, nackter Stein, Fliesen oder ungedämmtes Holz – etwa 1,2 m³ äquivalentes Volumen pro Quadratmeter hinzufügen, sodass ein 10 m³ Raum mit einer 2 m² Glastür etwa einen 10 kW Heizer benötigt, aufgerundet auf die nächste Standardgröße. Der Steine-Endpoint gibt die empfohlene Saunasteinmasse, etwa 10–20 kg pro kW (mehr Steine für einen weicheren, dampfigen Löyly, weniger für eine schnellere Aufheizzeit), mit einem Hinweis, richtige Peridotit/Olivin-Steine locker gestapelt zu verwenden. Der Elektrik-Endpoint gibt den Strom an, den der Widerstandsheizer zieht – Leistung ÷ Spannung für einphasig oder ÷ (√3 × Spannung) für dreiphasig, da die meisten Heizer über ~4 kW dreiphasig angeschlossen werden, um den Strom pro Leitung und Kabelquerschnitt gering zu halten – zur Dimensionierung des Schutzschalters und des dedizierten FI-geschützten Stromkreises. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Sauna- und Wellnesshändler, Heimwerker- und DIY-Tools sowie HLK-/Elektro-Schätzungs-Apps. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Schätzungen – folgen Sie der Tabelle des Heizerherstellers und den örtlichen Elektrovorschriften. 3 Compute-Endpoints. Für Dampfkesselberechnungen verwenden Sie eine Boiler-API; für Raumwärmeverlust eine U-Wert-API.

Tempo di attività

100.0%

Latenza

70ms

Abbonati

4,237

Hot-air-balloon lift maths as an API, computed locally and deterministically — the thermal-lift, envelope-temperature and air-density numbers a balloon pilot, designer or physics teacher works a flight out with. The lift endpoint gives the buoyant lift from heating the air: gross lift = envelope volume × (outside air density − inside air density), the densities from the ideal-gas law — a 2,500 m³ envelope at 100 °C on a 15 °C day lifts about 698 kg gross, from which you subtract the envelope, basket, burner and fuel for the payload, and the hotter the air and colder the day the more it lifts. The required-temp endpoint inverts it: to carry a target lift the inside air must reach a particular density and so a particular temperature, with a check that it stays under the ~120 °C that nylon envelopes can take — the everyday pre-flight question of whether the balloon can lift today's crew and fuel. The air-density endpoint gives the moist-air density ρ = (P − 0.378·Pv) ÷ (R·T), and explains the counter-intuitive fact that humid air is LESS dense than dry air, slightly cutting the lift. Everything is computed locally and deterministically, so it is instant and private. Ideal for ballooning and aviation tools, STEM and physics-education apps, and buoyancy calculators. Pure local computation — no key, no third-party service, instant. Idealised dry-lift model. 3 compute endpoints. For Archimedes flotation in water use a buoyancy API; for party-balloon helium lift a balloon API.

Tempo di attività

100.0%

Latenza

80ms

Abbonati

4,252

Water-hammer (hydraulic-transient) maths as an API, computed locally and deterministically — the surge-pressure, wave-speed and valve-timing numbers a piping or plumbing engineer guards a system with. The surge endpoint applies the Joukowsky equation Δp = ρ · a · Δv: a sudden stop of the flow spikes the pressure by the fluid density × the pressure-wave speed × the velocity change — stopping 2 m/s of water at a ≈ 1200 m/s adds about 24 bar (348 psi), far above the line pressure, which is what bangs the pipes and can split fittings. The wave-speed endpoint gives that pressure-wave speed: a = √(K/ρ) in a rigid pipe (≈ 1,480 m/s for water), slowed in a real elastic pipe to √(K/ρ) ÷ √(1 + (K·D)/(E·t)) — a thin or plastic pipe gives a lower wave speed and a gentler surge, which is why PVC tolerates hammer better than steel. The critical-time endpoint gives 2L/a, the round-trip time of the wave: close a valve faster than this and you get the full Joukowsky surge, slower and the returning relief wave eats into it, so sizing closure times (or fitting a surge tank or air chamber) above the critical time is the standard cure. Everything is computed locally and deterministically, so it is instant and private. Ideal for piping- and plumbing-design tools, pump-station and pipeline-surge analysis, and hydraulic-engineering utilities. Pure local computation — no key, no third-party service, instant. Idealised single-pipe transient. 3 compute endpoints. For steady pipe pressure drop use a Darcy API; for pump head and affinity a pump API.

Tempo di attività

100.0%

Latenza

76ms

Abbonati

3,906