Artificial Wasteland · physical

Weight Is the Table, Not the Earth

Your phone's accelerometer has never measured gravity. It measures being held up. Take the holding away for a quarter of a second and the reading collapses, and this page reads the collapse off your own handset, with the identical code first made to recover two fall times it was not told.

A phone lying on a table reports about 9.8 m/s². Everyone reads that as "gravity". It is not. The table is pushing the phone up, the tiny proof mass inside the chip lags behind that push, and the number is the push. Gravity pulls on the case and the proof mass in exactly the same proportion, so it moves neither relative to the other and the accelerometer cannot see it at all.

Which means the reading is not a property of the Earth. It is a property of the table. Take the table away and there is nothing left to measure.

Do it first

Two ways to run it, and they are not equally good. The page says which is which.

A drop gives the clean measurement: a real interval with no support at all, a fall time good to about one reading interval, and the whole lever-arm layer further down. Lowering it by hand gives a real measurement too, of a different thing: how much of the phone's weight your arm took away, and for how long. It is genuinely less precise, and here is the size of that: the shipped hand-lowering's window moves by 0.2285 s as the threshold is dragged across its range, about fourteen whole readings, while the shipped drop's does not move at all. It is not free fall, the page will tell you so in those words, and it will not report a value of gravity from it. Both buttons run the same capture and the same estimator.

What the number is, and what it is not

The headline is a ratio, and deliberately so. Your phone's 9.8 at rest is not a measurement of gravity where you live: it is a factory scale factor, set once on a production line, and nothing on this page can check it. So the honest thing to report is what the phone read while falling divided by what the same phone reads sitting still. That ratio has the scale factor on both top and bottom and does not care what it was.

On the drop this page ships, that ratio is 0.0595, with a 95 per cent interval of 0.0429 to 0.0762 once the reading step is added back. The window that contained it was opened by the reading falling below 0.75 of resting. The answer is more than twelve times smaller than the threshold that defined the window it came out of, which is the whole reason this is a measurement and not a definition. More on that below, because it is the first thing worth doubting.

Getting a real g out of it needs a ruler

There is exactly one route on this page to an absolute value of gravity, and it does not go through the accelerometer's calibration at all: g = 2h/t², where t is the fall time the accelerometer timed and h is a height you measured with something that is not this phone. Measure the drop, type it in.

Type a height above and this reads g = 2h/t² from your own fall.

What will actually cost you there, and it is your fingers

The window opens when support has fallen by a quarter, not when it has gone. Let go cleanly and that costs nothing: support is there in one reading and gone in the next. Open your fingers slowly and the window opens while the phone is still partly held, so the fall time runs long, and since g goes as 1/t² the answer runs low twice as fast. This one is one-signed. It does not average away over repeats, and it is not inside the one-reading interval quoted above, which covers the sampling and nothing else. The verifier builds the same drop with a hand that takes 20, 40 and 60 ms to let go, twenty noise seeds each, and none of those ship either:

Why you should not believe any of that yet

You have no second instrument. You cannot check this page, and a page like this is one hard-coded constant away from being a lie nobody can catch. So before the estimator is allowed to report anything about your phone, it has to recover two fall times it was never told, from two synthesised drops generated by research/free-fall-weightless/make-specimens.mjs from a forward model in which the fall time is an input.

running…

The two truths are 0.3200 s and 0.1800 s, which are 0.140 s apart, and each is judged to ±0.040 s. The tolerances sum to 0.080 s, so no single returned constant can satisfy both. That is not an assertion. Here is a deliberately hard-coded estimator, one that returns the anchor's answer whatever it is handed, run through the identical slate:

running…

Two honest notes about those traces, both of which cut against this page. The anchor's 0.3200 s is a 50 cm drop, longer than the safety box above will ask anyone to do; it costs nothing here because no phone was dropped to make it. And that is the second note: no real handset trace is shipped anywhere on this page. Every one of the nine is synthesised from the forward model, so what is established below is that the estimator recovers what was put in, not that it survives a real phone's sensor fusion, axis misalignment or timestamp behaviour. That is stated again, in full, at the bottom.

Five traces the estimator is not allowed to be right about

An estimator that only ever sees signals it can read is not being tested. These five go through the same estimate() by the same call, and what came back is printed verbatim.

The hand-lowering is the important one. It is not a broken signal: it opens a window, it closes one, and it ends in a set-down firm enough to register as a landing. It passes every structural test a drop passes. It is refused on the number, at 0.3832 of resting against a cutoff of 0.25, and that number is one the estimator could not have chosen for itself. The lift descent fails earlier and differently: its least reading is 8.55 m/s², 0.874 of its own resting reading, and a descent that never lets go never opens a window at all.

That cutoff is a choice and it is a slider further down, so you can reach the setting where this stops working: drag not free fall above past 0.3832 and the hand-lowering is no longer turned down, because the rule now admits it. The row goes amber and says which of the two answers was yours. A row that is right at the shipped settings and wrong at yours is your slider doing its job; only a row that is wrong at the shipped settings is a defect, and that one goes red.

The clipped trace earns its place the same way. Its landing is pinned at 19.6 m/s²: the rail was put at exactly two g, which is 19.6133, and the 0.1 reading grid puts every sample of it on 19.6. The whole-event average that the second route to g leans on comes out at 0.805 of its resting reading where the same drop unclipped gives 1.066. A page that did not notice the rail would have printed that 0.805 as physics. This one voids the route and keeps the fall time and the null, which are not affected by what the landing did.

"You picked the threshold, so the answer is a convention"

This is the right thing to doubt, and it is the trap this page was built around. The argument runs: you defined the fall as the bit where the reading is small, then reported that the reading there is small. Nothing about the world has been said.

It would be exactly right if the window were selected for being small. It is not. The window opens at three quarters of the way up to full support and reports the mean of what is inside, which is free to be anything up to that threshold: on the drop this page ships it comes out twelve times below it, and the hand-lowering comes out at 0.38 through the identical rule and is turned down. The test is what happens when you drag the threshold. An event has edges: move the threshold anywhere between them and nothing changes. A gradient does not: move the threshold and you get a different answer, because the threshold is the answer.

Across that whole range the drop's fall time reads 0.3199 s at every setting, to four decimal places, while the lowering's window runs from 0.1933 s to 0.4218 s. The drop's ratio does not move either, to five decimal places, where the lowering's runs from 0.2789 to 0.4632: on a slope, a quarter of the answer is whichever threshold you chose. That is the difference between letting go of something and putting it down slowly, and it is visible in the arithmetic rather than asserted in the prose.

The leftover is not slop. It is a second sensor's business.

Here is the sharper objection, and the one this page exists for. Your phone will not read zero. It will read 0.3, or 1.8, or something. Calling that "zero" is a rounding convention dressed as physics.

It would be, if the leftover had no account. It has one, and the account is an equation with a second sensor's fingerprints all over it.

The accelerometer is a chip. It is soldered to a board a couple of centimetres from the phone's centre of mass. In a torque-free fall the phone rotates about its centre of mass, and a point at r from that centre, on a body turning at ω with angular acceleration α, is genuinely accelerating:

a = ω × (ω × r) + α × r

The centre of mass reads zero. The corner of the phone never did. And here is the part that turns this from an excuse into a result: ω and α come from the gyroscope, a completely different sensor in the same package that knows nothing about the accelerometer.

Be exact about what that buys, because the tempting sentence is false. Nothing here is predicted before it is looked at, and r does not come out of the gyroscope: it is three numbers fitted by least squares to the accelerometer's own readings. Take the accelerometer away and there is no r and no centimetres. What the gyroscope supplies is everything except those three numbers. The equation above is linear in r, and every coefficient in it belongs to the gyroscope: the entire time course of the leftover, and how it divides between the three axes at every single reading, is settled by the other sensor before the accelerometer is consulted at all. On the drop this page ships that is 51 equations against 3 unknowns, and the three that come back are the distance from that phone's centre of mass to the accelerometer die inside it, in centimetres. It is not on a datasheet you can look up and nobody supplied it.

On the drop this page ships, the fit returns 2.32 cm, 95 per cent between 2.08 and 2.56 cm. The chip that generated that trace was put at (2.10, −0.80, 0.40) cm from the centre of mass, which is 2.2825 cm. Nothing in the estimator was told that.

Three unknowns is few enough that the length alone could be luck, so here is the part that could not be: the three numbers come back individually at (2.13, −0.83, 0.41) cm, each within a millimetre of where the chip was put, and together they account for 98.6 per cent of everything the accelerometer read inside the fall. Three free scalars cannot rescue a wrong shape across 51 equations. That is what makes this a measurement of the handset rather than an account of the leftover.

Which of the three numbers is actually measured

They are not equally supported, and this is the part a confident-looking centimetre figure can hide. ω × (ω × r) is blind to the part of r that lies along ω, and a body turning about one fixed axis has no angular acceleration to recover it with. So a phone spun about a single axis, which is what a wrist flick produces, leaves that component invisible however long the fall lasts. Two of the three numbers come back superbly and the third is invented, and their length looks perfectly reasonable while being wrong by a factor.

So the interval above is not the width along the fitted vector. It is the widest the 95 per cent region reaches in any direction, taken from the eigenvalues of the fit's own covariance, and the page reports a length only when that worst direction is under half of it. Here is what the two rules do to the same phone spun about one axis at 8.9 rad/s, over 150 noise seeds:

The old rule kept quiet on seven eighths of those drops and then, on the rest, printed a number that was wrong more often than it was right. The new one prints a bound on all of them and the bound holds. On the shipped tumble it costs almost nothing: 2.10 to 2.54 becomes 2.08 to 2.56, the point value survives all 150 seeds and covers the truth on 146 of them. The whole difference is in what it refuses. And it names the culprit rather than the reader: on a single-axis spin the direction the fit cannot see comes back within a tenth of a degree of the axis the phone was turning about, and the page prints that angle beside the answer.

Two shipped traces close the layer, and they are the reason it is a measurement and not a story. A drop of the same phone with the same chip offset, barely spun, returns no value at all: below 7.64 cm, which is most of the case and therefore next to nothing, and the page says so instead of quoting a number, because at a mean of 0.43 rad/s the term being fitted is under the reading step. And a drop with the chip placed exactly at the centre of mass returns 0.00 cm, 95 per cent within ±0.61 cm, which covers zero and excludes 2.2825 by more than a factor of three. Same code, three different answers, set by where the chip is and how hard the thing was spun.

So: tumble it, briskly rather than violently. Give the phone a deliberate flick as your fingers open, over the bedding, and the layer comes alive. Drop it flat and it will honestly tell you it cannot see anything. A clean spin about one axis is the case in between, and it is the one worth knowing about: it will read a length off the two components it can see and decline to report it, naming the axis it went blind along.

There is a ceiling at the other end too, and it is the instrument's rather than the physics'. Past 2.87 turns a second on the drop this page ships, the chip's own lever arm alone puts more than a quarter of a resting reading on the accelerometer and a genuine fall stops looking like one. That figure is this handset's, not a constant: only the part of r lying across the spin axis makes the reading, so a chip 2.28 cm out that happens to sit square to the axis you spun about trips the same cutoff at 1.65 turns a second, and one lying along it never trips it at all. This page will not call any of that your arm. It says instead that the reading is inside what your own gyroscope shows rotation could produce, so either something was still holding the phone or the spin accounts for it, and it cannot tell which.

Two things your phone has that none of these traces do

Every trace here is generated with the centre of mass at exactly zero proper acceleration through the fall. That is true in a vacuum and nowhere else. A real phone falling into a real room carries two more terms, each of them reaching past the 0.1 m/s² the browser reports in, and between them they are the honest answer to my phone read 0.3, not zero.

Air. Drag makes a falling body push on its own sensor, and it is easiest to read as a fraction of terminal speed: the proper acceleration is g·(v/v_t)² with v_t = √(2mg / ρC_dA). For the 190 g, 160 by 75 by 8 mm slab whose inertia tensor generated these traces, tumbling, the mean projected area is a quarter of the surface area (that is Cauchy's theorem for a convex body, not a guess), which is 69.4 cm² and a terminal speed of 20.1 m/s. Flat-on it is 120 cm² and 15.3 m/s. A half-metre drop ends at 3.14 m/s, so at the moment of landing the sensor is reading 0.24 m/s² tumbling or 0.41 flat-on, two to four whole steps of Chrome's grid, and the average over the whole fall is a third of that. The air density is PM/RT for dry air at 20 °C and one atmosphere, 1.204 kg/m³. The drag coefficient of order one is the softest number in that line and it is an assumption rather than a measurement.

Air has a signature, which is what makes it worth naming rather than lumping into slop: it grows as the square of the speed and so as t² through the fall, where the lever arm's ω² term is roughly steady and a sensor offset is exactly constant.

The chip's own zero. A MEMS accelerometer reads something with nothing acting on it. Bosch specify the part in this class at ±20 mg of zero-g offset (BMA456 data sheet, BST-BMA456-DS000-09 revision 3.6), which is 0.196 m/s² on one axis and up to 0.34 as a three-axis magnitude. Free fall is the first thing that ever shows it: at rest the magnitude only carries the part of the offset lying along gravity, where it hides inside the 9.8, and in free fall the true vector is zero so the whole of it is the reading. It is constant in the body frame, which is exactly what the also fit a free accelerometer zero offset switch below fits, and turning that on costs the shipped drop its lever arm outright, which is the honest price of not knowing your own chip's offset.

Neither term is in any trace on this page, and putting them in would trade a clean test of the estimator for a test of somebody's model of a phone. What they are for is your own arithmetic: if your interior mean comes back at a couple of tenths of a m/s² with the phone barely turning, that is where it came from, and none of it is this page rounding in its own favour.

That is the honest part. Here is the useful part, which is what air does to this estimator. The offline verifier builds the same tumbling drop with drag in it, at three heights, twenty noise seeds each, and puts the identical estimate() in front of it. None of these traces ship.

Every free choice, and the two grids you cannot get under

Drag any of these and the whole page re-runs: the slate, the five refusals, the sweep, and your own record. If a setting breaks the slate, the instrument disarms and this page stops reporting numbers altogether: not your ratio, not your centimetres, not your g, and not the shipped drop's either. An estimator that cannot recover two known fall times has nothing to say about an unknown one, whoever the record belongs to.

running…

Two of those numbers are not choices at all, and they set the floor on everything above. Measured here in headless Chromium on 2026-08-17, by injecting exact values over the debug protocol and reading back what a page actually received:

accelerometer   9.81 -> 9.8      0.2079 -> 0.2     -3.14159 -> -3.1    0.04 -> 0
                a 0.1 m/s^2 grid, about 1 per cent of g

gyroscope       0.2079 rad/s -> 0.20769418 rad/s        -8.9 -> -8.899433856
                3.3333 -> 3.33357887                    0.01 -> 0.010471976
                every one an exact multiple of 0.1 DEGREE per second
                (0.2079 rad/s = 11.9118 deg/s -> 11.9 deg/s = 0.20769418 rad/s)
                so the gyroscope grid is pi/1800 = 0.001745 rad/s

Chromium rounds both as a fingerprinting mitigation, and both numbers above are that browser's, measured on the Generic Sensor path: they are not a property of a phone, and the iOS Safari fallback is a different engine this page never injected. The estimator does not take either on trust, it measures the step off your own record. That grid is why a good drop reports its ratio as a bound rather than a point: when every reading inside the fall lands on the same grid point, that is not zero uncertainty, it is the reading step, and the headline above switches to below a number rather than quoting a precision the hardware cannot express. The shipped traces carry both grids, so the estimator is never flattered by a specimen smoother than a phone.

checking…

What this is not

It is not a redefinition of the word weight. The resolution this page takes 9.80665 from is the one that fixed that word, and it fixed it the other way. 3rd CGPM (1901), Resolution 2 declares, in the same three numbered points that give the standard value: the word "weight" denotes a quantity of the same nature as a "force": the weight of a body is the product of its mass and the acceleration due to gravity. By that definition your weight does not change when the table goes. The title above uses the word the way a bathroom scale does: the force holding you up, which is the thing an accelerometer actually reads and the thing that goes away. Both senses are in ordinary use, the CGPM's is the one with the mass in it, and the citation in the footer is for the number rather than for the slogan.

It is not a test of the equivalence principle. A composition test compares two different materials falling side by side and asks whether they fall at the same rate. Here the proof mass and the frame it hangs in are both silicon on the same die, so nothing whatever about composition-independence is tested. What is demonstrated is the observable consequence: the instrument cannot separate gravity from acceleration, so removing the support removes the reading. For scale, and as a different experiment rather than a rougher version of this one, the MICROSCOPE satellite compared titanium and platinum test masses in orbit and found their accelerations equal to η = [−1.5 ± 2.3(stat) ± 1.5(syst)] × 10⁻¹⁵, quoted in the paper at 1σ in statistical errors. Add those two in quadrature and the bound is about 2.7 × 10⁻¹⁵, at that same 1σ. A phone in Chrome reads in steps of 0.1 m/s², which is one part in 98 of its own resting reading, so MICROSCOPE is twelve orders of magnitude finer than the instrument in your hand, and it is asking a question this page does not ask.

It is not a measurement of local gravity from the rest plateau. The 9.8 your phone shows is a calibration constant. Only the 2h/t² route escapes it, and only because it needs a length that came from somewhere else. The impulse route, which averages the reading over the whole event, inherits the same factory scale on both sides and is reported as a consistency check with that said out loud.

It is not a claim about space. "Astronauts float because there is no gravity up there" is a different and older confusion, and the correction already lives at Moon Cannonball with the orbital numbers worked. This page stays on the instrument in your hand.

It is not about your body. Nothing here measures a person, a fall risk, or any health quantity. It is a phone on a duvet.