I have written about this tool three times now: the geometry that makes it possible, three occasions when the physics contradicted what I was building, and what it does and does not do. This is an update, not a rebuild. The tool is still not public.
The recurring theme of this blog is systems that return a well formed answer that happens to be false. This batch produced the cleanest example of it I have hit yet, and it took about four hours to find something that looked perfect the entire time.
Point at it
The form asks each observer for four angles: where the fireball appeared and where it vanished, in azimuth and elevation, to two decimal places.
Nobody standing in a field at two in the morning has those numbers. What they have is a memory of where the thing started, where it ended, and an arm to point with.
So now you hold a button and point the phone at it. The back of the phone is the sight, the sensors say where it was aimed, and letting go writes the angles into the form.
Three things it refuses to do matter more than the capture itself.
A plain orientation reading on some phones carries a heading with an arbitrary origin that looks exactly like a compass bearing. It is refused rather than returned. A real compass heading is magnetic, and the correction to true north is a local number this program does not carry, so it is asked for, and without it the captured bearings stay labelled magnetic instead of being quietly treated as true. That correction is under a degree in some places and over twenty in others, which is the difference between the right field and the next county.
And a shaky hold is thrown away. Past a couple of degrees of scatter the capture is refused and says so, because an angle you believe is good and is not is worse than no angle. The solver will converge on it happily and put the search area confidently in the wrong place. The scatter over the hold is also a real measurement of your own precision on that night, so it replaces the guessed error bar rather than sitting beside it.
The bug that pointed south
Here is the part worth the post.
The direction a phone is pointing is not its compass reading. It is the full rotation of the device applied to the axis coming out of the back of it. Reading the compass value as a bearing works while the phone is flat on a table and is wrong by tens of degrees the moment it is tilted up at the sky, which is the only way it will ever be held for this.
I got that part right. Then I dropped a sign in one component of the result.
Every azimuth came back reflected through the east-west line. A phone held up facing north reported south.
What makes it worth writing down is everything that still worked. Elevation was correct. Rolling the phone from portrait to landscape while keeping it aimed at the same point did not move the aim, which is the hard invariant and the one I had written a test for. Turning on the spot swung the aim by exactly the right amount, in the right direction. Every reading was stable, smooth and plausible.
It was a working compass pointing the wrong way, and nothing about using it would have told you.
The test that caught it is the dullest one imaginable: hold the phone upright facing north, and check that the answer is north.
The sea floor, and the ground that is missing
The globe used to be a graticule with a coastline. It now carries country borders and the real published depth contours of the ocean.
Everything on that sphere is real, precomputed and bundled, so it works with no signal.
Green for land and blue for water is doing work rather than decorating. The first version drew coast, borders and the graticule in the same dim slate, and three different kinds of line at one weight read as a single texture. Line thickness cannot separate them, because the browser ignores line width on essentially every desktop machine. Hue can.
There is no land elevation on that globe, and that is deliberate rather than pending. I could not obtain a real global elevation grid on the machine this was built on. I could very easily have generated one. A shaded relief map generated from nothing looks exactly like a shaded relief map generated from measurements, which is the whole argument of this blog in one image, so the app says outright in its own footer that the sea floor is ocean depth only and that no land elevation is carried.
The contours are not only a picture. They answer what is under a point, which turns the most under-appreciated fact about the fireball record into something you can read off an event instead of being told: most of them fall over water, because most of the planet is.
That lookup had two bugs of exactly the kind this project exists to catch, both of which drew a completely convincing ocean. The one I liked put a stretch of Arctic shelf, in fifty metres of water, under two kilometres of it. It is checked against the sea floor now rather than against itself: the Mariana Trench, the basin under the North Pole, and five places that had better be dry.
A camera you can fly
The solar system view had one camera, swinging around the Sun at a fixed distance. Good for a diagram, useless for standing inside the asteroid belt and looking back.
The property I spent the most care on is that switching between the two cameras does not move the picture. That sounds like a detail. On screen, a small error in the handover reads as the camera settling, which is indistinguishable from polish, so it would never get reported by anyone. The two conversions are written as inverses of each other and a test composes them and requires the identity back.
The readout also says what the speed is not. The 2.88 AU per second in that frame is about 1,400 times the speed of light, and out at Neptune the same control is past ten thousand. A figure in kilometres per second sitting next to real orbital velocities would invite exactly the wrong reading, so the readout says in as many words that this is a viewpoint and not a spacecraft.
A score that cannot be gamed by measuring less
The last piece is the one I expect to be most useful and was the most interesting to design.
The tool now rates your observation out of a hundred and tells you the single best thing to go and measure next.
The obvious way to build this is to score how tight the search area came out. It is exactly backwards, and I know it is backwards because this project already proved it: deriving the mass of the rock honestly from its light curve makes the search area grow, from 8 square kilometres to nearly 19 on the worked example. The smaller figure was never real. Walking it means a good chance the rock was never inside it.
A score that preferred the tighter number would rank the version that lies to you above the version that does not, and I would then spend months quietly tuning the tool toward the lie.
So the score is blind to what came out. Every point comes from how well constrained the answer is, and the test feeds the same observation alongside wildly different areas, masses and probabilities and requires an identical number back. Every ladder is monotonic, so it can never be improved by measuring less.
Two things in it were caught by tests rather than by me, and both would have been quietly demoralising. The largest missing item was being offered as the thing to do next, and since that item is decided entirely by where the two observers were standing, the suggestion amounted to telling somebody in a field that they should have been somewhere else. And a failed solve was reporting zero for the redundancy of the tracks, which told anyone who had just done the most useful thing available to them that they had gone backwards.
There are badges too. They record things that were actually true of the data, each with a real threshold, and they are never taken away. A badge that can be lost becomes a thing to protect rather than a thing to have done.
What it still cannot do
The same thing as last time, and it has not moved.
Everything in the test suite, now a bit over fifteen hundred assertions, checks the code against physics. That is necessary and it is not sufficient. A pipeline can satisfy every conservation law in it and still point at the wrong field, because the errors that matter live in the modelling choices rather than in the arithmetic.
Only a recovered fall tests that, and the list of validation cases in the code is still deliberately empty. Filling it from memory would produce a figure of merit computed from invented inputs, which would look exactly like a validation and be worse than having none at all.
Which is the whole point. The most dangerous output this tool could ever produce is not an error. It is a number with the right units, a plausible magnitude, and nothing behind it.