The Sky Has Become a Distributed Sensor: How Edge ML on $200 Raspberry Pi Nodes Tells You Exactly When the Eta Aquariids Peak

The Eta Aquariid meteor shower peaks tonight. If you live in the Southern Hemisphere or the tropics, look toward the eastern sky in the pre-dawn hours of May 7 — between roughly 3 a.m. and astronomical twilight — and you might catch 40 to 60 meteors per hour streaking out of the constellation Aquarius. The bits burning up at 66 kilometers per second are dust grains shed by Halley's Comet on its passes through the inner solar system, the most recent of which was in 1986. Earth has been ploughing through the same debris stream every May for as long as humans have looked up.

That is the part that ends up in the science section of a general-news site.

The part that does not is how anyone knows the rate is 60 and not 30, why the peak is forecasted for the early morning of May 7 rather than the night of May 4 or 9, and how the orbital fit that links these specific meteors to Halley keeps getting tighter every year. Those numbers are not coming out of a small number of professional observatories with multi-million-dollar instruments. They are coming out of a distributed sensor network of more than a thousand low-light security cameras bolted to weatherproof housings on rooftops, garden sheds, and apartment balconies across six continents. Each one has a $35 Raspberry Pi behind it. Each one runs an open-source machine learning pipeline overnight, classifies tens of thousands of bright pixels, and uploads only the meteors to a shared trajectory solver in the morning.

If you are a CrashBytes reader, you should care about this for a reason that has very little to do with astronomy. The Global Meteor Network and its older cousin CAMS — Cameras for Allsky Meteor Surveillance, run out of the SETI Institute — are the closest thing in production to a clean, working, multi-decade reference architecture for the pattern that every "AI everywhere" pitch deck has been promising since 2019: cheap edge compute, on-device inference, sparse uplink to a cloud aggregator, open ground-truth data, federated continuous learning. Most of those pitch decks are vapor. This one ships meteors every morning.

Tonight is a good night to look at how it actually works.

The numbers, calibrated by an ML pipeline you have probably never heard of

A useful way to read this year's Eta Aquariid forecast is to read it as the output of a model. The numbers being quoted by every outlet covering the peak — zenithal hourly rate of 60, Southern Hemisphere observers seeing 40 to 60, Northern Hemisphere observers in the high latitudes capped at less than 10 because of the waning gibbous moon — are not raw observations. They are model-predicted rates derived from years of trajectory data, atmospheric modeling, and population statistics fitted to a parent body orbit. The model is fed by the network of cameras described below.

Two facts about the chart matter more than the absolute numbers. The first is that the global volunteer network outproduces professional radar by two orders of magnitude on raw counts, and outproduces it on a different axis that radar cannot touch at all: pin-sharp orbital fits anchored by multi-station triangulation in the visual band. Radar tells you how much mass is hitting the upper atmosphere; the camera networks tell you where the parent body's debris is and where it is going. The second is that this output sits on top of consumer hardware. The total bill of materials for one GMN station is documented publicly: a Raspberry Pi 4 single-board computer, a 2 megapixel low-light IMX291 sensor in an IP66 housing, a 4mm to 6mm CS-mount lens, an SSD for nightly video buffering, a Wi-Fi connection. The whole rig comes in under $300 and does not require a shed-mounted dome or a clock-driven mount. It just needs to be pointed at the sky and given power.

That setup is the unit cell. The interesting work happens overnight on each unit, and again in the morning when each unit's good detections fly up to a shared back end.

The on-device pipeline, in three classifiers stacked together

The software side is the part that an AI-infrastructure reader will recognize. The reference implementation, called RMS (Raspberry Meteor Software), runs entirely locally on the Pi and is written mostly in Python with C extensions for the hot loops. It does not assume a network connection during the night. The processing flow looks like this.

After local sunset, the camera begins recording at 25 frames per second into a circular buffer on the SSD. Once a configurable amount of frames has been buffered, RMS flat-fields, dark-subtracts, and runs frame differencing to extract bright transient pixels — anything brighter than a threshold above the rolling background. This is conventional difference imaging. It produces tens of thousands of candidate events per night per camera in a typical light-polluted suburban sky. Most of those events are not meteors. They are aircraft, satellites, planes with strobes, birds illuminated by city lights, lightning flashes through clouds, drifting dew on the lens, sensor noise, and the occasional passing cat.

Three classifiers downstream are responsible for getting the meteor count right.

The first is a random forest binary classifier that takes a flat feature vector for each candidate event — track length, angular velocity, photometric profile, frame coverage, color channel ratios — and decides meteor or non-meteor. This is the cheap stage. It runs on every candidate and discards roughly 95% of them. The features and the trained tree weights are versioned in the open-source repo and updated periodically as new false-positive classes show up.

The second stage is a convolutional neural network that takes image stacks of the surviving candidates and outputs a per-event probability score. This is the stage that catches the cases where the random forest is uncertain — particularly the satellites with rotational glints, which look meteor-like in their photometric profile but have a characteristic visual signature in the stacked frames. The CNN was trained on a labeled archive of confirmed meteors going back more than a decade, with hard-negative mining from operator review.

The third stage is a long short-term memory network that takes the light curve of each event — the brightness as a function of time, sampled across the frames the candidate appears in — and predicts the likelihood that the curve corresponds to atmospheric ablation. Real meteors have a distinct profile: a fast brightening, a peak, a slower decay sometimes followed by flaring or a wake, all on the order of fractions of a second to a few seconds. Birds and aircraft do not. Geostationary satellite glints do not. Lightning does not. The LSTM is the cheapest second opinion in the pipeline on the temporal axis.

Three percent. That is the share of bright transient pixels that survive to become a confirmed meteor on a typical suburban camera. Without the three-stage classifier stack the operator would be drowning in false positives every morning. With it, what gets uploaded to the central server is a small bundle per detected meteor: a short clip, the extracted track, a few timestamps, the camera calibration, and the photometric profile. The bandwidth budget is trivial. A single GMN station typically uploads under 200 megabytes per clear night.

Triangulation: the part that needs the network to be a network

What you have at this point is a high-confidence catalog of meteors per camera. That is useful. What you do not have is an orbit. A single camera sees a meteor as a streak in a 2D plane projected onto the sky. To recover the actual three-dimensional trajectory through the upper atmosphere, you need at least two stations with overlapping fields of view, separated by some baseline (typically 50 to 200 kilometers), looking at the same event from different angles.

This is where the second tier of compute kicks in. Each morning, the GMN back end ingests detections from every station, indexes them by absolute timestamp (the cameras are synchronized to NTP within a handful of milliseconds, which is good enough at the relevant geometry), and looks for spatially and temporally coincident detections. When it finds two or more stations that saw the same event, it solves a non-linear least-squares fit for the trajectory through the atmosphere — entry point, velocity vector, deceleration profile.

Once you have an entry trajectory, the orbit is essentially free. You propagate the meteoroid backward from the top of the atmosphere using the equations of motion under solar gravity, with planetary perturbations as needed. The result is a heliocentric orbit — semi-major axis, eccentricity, inclination, ascending node, argument of perihelion. If the orbit matches the orbit of a known parent body within a Drummond similarity criterion threshold, you have an association. For the Eta Aquariids, the parent body is 1P/Halley, and the associations are unambiguous: highly inclined, retrograde, Halley-class.

This is the piece that turns a regional hobby project into a planetary instrument. No single station can recover an orbit. A pair can. A network of more than a thousand stations recovers tens of thousands per year, with high-precision orbits for a substantial subset.

The growth in the GMN station count has tracked the falling cost of single-board computers and the maturation of the RMS software stack. The growth in cumulative orbits has tracked the station count more or less linearly, which is what you would expect from a network that scales by adding clients to a back end that does not need to know about each client in advance. CAMS, the older project run out of SETI, has slower station growth (it uses a more bespoke camera and a Linux PC rather than a Pi) but deeper per-station data and substantially better long-period coverage. The two networks are increasingly cross-validating each other's catalogs.

The CAMS angle: ML-discovered comets

The reason this story belongs in front of an AI/tech audience and not just a stargazer audience is what CAMS has done with the same kind of data.

CAMS started in 2010 with a more conservative goal: catalog the 100 known meteor showers in detail. By around 2015 it had enough data to pivot to something nobody had really attempted at scale before: searching the trajectory catalog itself for shower clusters that were not associated with any known parent body. Meteor showers usually have a parent — a comet or an asteroid that left the debris stream. If you find a tight cluster of meteor trajectories with a coherent orbit and there is no known body in that orbit, you have either a previously unknown parent or a parent that has since disintegrated.

The team built a machine learning classifier that scans the catalog for these clusters. It is not flashy. It is essentially a custom density-based clusterer with a learned similarity metric, run nightly against the accumulating trajectory archive. Over the last decade it has produced more than three dozen new meteor shower identifications, and crucially it has flagged candidate parent body orbits that were subsequently found by optical and radar follow-up.

This is the kind of result that "AI for science" has been promising for a long time and has rarely delivered at this scale on this small a budget. There are no foundation models involved. There is no gigawatt training run. The compute footprint of the entire classifier stack across all stations combined is a low-power data center the size of a closet. The data flywheel runs on volunteer time and consumer hardware. The discoveries are real and peer-reviewed.

Why this is a reference architecture, not a hobby

Step back from astronomy for a moment.

What you have is a deployed, working, multi-year-stable example of a pattern that the AI infrastructure community has been arguing about since at least the 2020 wave of edge ML hype. The pattern looks like this:

1. Cheap, ubiquitous sensors (low-light camera + Pi), deployed by the end users of the data, not by a central operator.
2. On-device classifiers stacked in increasing-cost order — random forest first, CNN second, LSTM third — running entirely without a live network connection during peak workload.
3. Sparse, asynchronous uplink to a shared cloud aggregator. Most of the data is discarded at the edge; only the high-confidence detections travel.
4. A central back end whose job is not to do inference but to do triangulation, association, and population statistics — the things that fundamentally require the full network view.
5. Open data, open code, open trained-model weights. Anyone with a Pi can join. Anyone with a hard drive can pull the catalog.
6. Continuous improvement of the classifiers via labeled corrections from operators, fed back into versioned model updates.

That is, with the names removed, the architecture every IoT-meets-AI roadmap has been pitching since the AWS Snowball launches in the late-2010s. The difference is that this one was not assembled by a hyperscaler. It was assembled by a small group of astronomers and their volunteer network, in the open, on a budget that would not buy a single H100 today.

If you have spent the last few years trying to get a sensor mesh, agricultural network, wildlife camera trap deployment, or distributed acoustic monitoring program to converge on a similar pattern, the GMN stack is worth two evenings of your time. The design choices are defended in the published methodology paper and the operator wiki. The trade-offs are made out loud. The thing works.

For more context on how open-source coordination scales against hyperscaler-assembled infrastructure, see my analysis of the open-source frontier model pincer of early 2026 — different domain, very similar shape of trade-offs around governance, data flywheel, and economic gravity.

Cost economics: why this only works because the unit cell is cheap

The reason this is a reference architecture and not just a fluke is that the unit economics work. A station deployment under $300 means the network can grow by accretion — operator by operator, each one pulling the trigger on their own budget. There is no procurement cycle. There is no central capex line. The marginal cost of adding the thousandth station is the same as the cost of the first.

For comparison: a single all-sky station built around a CCD camera, shutter, mount, and dedicated PC was a $5,000 to $8,000 build a decade ago. The Pi-based design did not just lower the cost — it lowered it enough that the procurement decision moved from institutional to individual. That is what made the network grow into the thousands.

This is the same dynamic that happened to home weather stations in the 2010s, to cheap GNSS receivers in the 2020s, to consumer LiDAR in the last few years, and that will happen to whatever the next consumer sensor revolution turns out to be. When the unit cell drops below the threshold where a hobbyist will eat the cost out of pocket, the network densifies on its own. The role of the central organization is to make sure the data format and the back end can absorb that growth without breaking.

This is also where the AI/ML choices matter. If RMS required a GPU, the network would not exist at this scale. The classifier stack was designed deliberately to run on a Pi 4 in the time available between sunrise and the operator wanting their morning email. CNN inference on a few tens of thousands of tiny image stacks per night fits that budget. A more expressive model — a vision transformer, say — would not. The constraint shaped the architecture, and the architecture shaped what was possible at this price.

Limits, failure modes, and the thing the marketing decks always skip

Nothing about this is magical. The same architecture that lets the network scale also sets hard limits on what it can do.

The first limit is sensor diversity. The cameras are good at bright meteors in the magnitude -2 to +4 range. They miss the faintest meteors entirely (too dim) and saturate on bright fireballs (camera-dependent). Radar fills in the dim end; dedicated fireball networks like NASA's All Sky Fireball Network fill in the bright end. The visual GMN/CAMS stack is in the middle.

The second limit is geographic. The network is densest in Europe, North America, and Australia, with growing coverage in South America and East Asia. Africa and the high latitudes (above 60 degrees) are sparse. This matters because the radiant of any given shower is observable only from parts of the world. The Eta Aquariid radiant is far enough south that Northern Hemisphere stations contribute much less to the orbital fits during the peak; the Southern Hemisphere stations carry the load. A shower with a polar radiant — which is rare but happens — would be barely covered.

The third limit is cloud cover. Optical networks are dependent on clear skies. Cloudy nights produce no data. Multi-station triangulation requires at least two clear stations with overlapping fields. During extended weather systems, large parts of the network go dark.

The fourth limit, and the one that should worry the architecture-pattern people most, is the brittleness of the volunteer back end. The whole thing depends on a small group of maintainers — fewer than ten in the case of GMN — who keep the code, the schemas, the back-end servers, and the operator support thread alive. If they burn out or move on, the network reverts to a thousand independent cameras producing data that nobody is fitting orbits to. This is a bus-factor problem that every "open-source citizen sensor mesh" has, including the agricultural monitoring systems and the seismic networks. The reference architecture includes the maintainer dependency. The marketing decks rarely mention it.

For more context on how that bus-factor risk plays out at scale, see my piece on the recent compaction of open-source maintainer responsibility around critical infrastructure projects — the shape of the problem is depressingly similar across domains.

What the next 24 months will probably look like

The trends that drove the network to where it is now are unlikely to reverse. The Pi 5 is in the wild and is comfortably faster than the Pi 4 on the relevant workloads. Low-light CMOS sensors continue to drop in price. The classifier stack is being incrementally retrained on a richer labeled archive. The operator base has been growing roughly linearly for six years.

The big near-term wins are predictable.

First, deeper coverage. The network will probably hit 1,500 active stations within 18 months at current growth, with most of the new growth coming from Latin America, India, and East Asia. That fills the geographic gaps and makes shower coverage less Northern-Hemisphere-biased.

Second, better classifier performance. The CNN and LSTM stages are due for a refresh as labeled archives grow. Modest accuracy improvements at the event-level translate into substantial improvements in shower-population statistics, because the quadratic effect of pairwise station triangulation amplifies per-station gains.

Third, more discoveries. CAMS-style cluster mining over the combined GMN+CAMS catalog is going to find more parent bodies. Some of those parents will turn out to be long-period comets that have not yet been optically observed. This is the headline-grabbing part: ML systems on $200 hardware finding comets that the world's largest survey telescopes have not yet seen.

This is also exactly the kind of falsifiable claim that you can put a target date on, which is why I have a prediction running on it for Q4 2027. You can read the reasoning and the validation criteria there.

The fourth trend is the one I find most interesting: the architectural pattern is going to start being copied. Some of the copying is already happening — the same RMS-on-a-Pi shape is being used in fireball networks, in low-frequency radio interferometry, in cosmic-ray detection networks for citizen science. Some of it will happen in adjacent domains that have very little to do with astronomy: dark-sky monitoring, bioacoustic surveys, atmospheric chemistry, agricultural pest detection, distributed transportation incident logging. The pattern is general. The astronomy community got there first because they had the data flywheel already running before edge ML got cheap.

Five lessons your enterprise observability team can actually steal from a meteor network

Before we get to tonight, the bit of this story I most want non-astronomers to take away is that the operating principles of GMN are immediately transferable. Strip the words "meteor" and "telescope" out of the preceding sections and re-read with the words "transaction trace", "log event", or "telemetry sample" substituted in. The architecture maps almost one for one onto the hard parts of cost-bounded distributed observability — which, as it happens, is one of the live problems for every team trying to use full-fidelity tracing across a fleet of more than a few hundred services.

The first lesson is to pre-classify at the edge, ruthlessly. RMS does not ship video to a back end and then decide what is a meteor. It ships only the bundles that survive three classifiers locally. Most enterprise observability stacks ship everything, then sample, then aggregate. The GMN inversion — sample at the edge using a lightweight learned classifier, ship only the high-information events — is uncontroversial in networking-land but rare in observability-land. The reason is mostly historical: log shippers were built before edge ML was cheap. They are not anymore. A small-footprint binary classifier that drops 90% of duplicate or low-information events at the agent level would change the economics of every full-fidelity tracing pitch the industry is currently making.

The second lesson is to make the unit economics fit a hobbyist budget. That sounds glib. It is not. The reason GMN scaled past every institutional sensor mesh of the same era is that the marginal operator did not need anyone's permission or budget to bring a station up. Enterprise systems do not have hobbyists, but they have something close: team-of-one engineers who will deploy a thing because it took them an afternoon. If your sensor agent or your tracing sidecar requires a quarterly capacity review to land, you have already lost. If it takes a single afternoon and a single laptop, you will have nineteen of them running by Friday. The internal procurement friction is the single biggest difference between a network that grows and a network that stalls at the pilot.

The third lesson is to tier your compute by stage cost. The random forest is cheap. The CNN is medium. The LSTM is more expensive than the CNN. They are run in that order, with each stage filtering for the next. This is a basic pattern from cascade detectors going back to Viola–Jones, but it remains the right answer for any pipeline where most candidates are negatives and the cost of inference is non-trivial. Most production ML pipelines do not stage their classifiers this way. They should. The cost ratio between the cheapest and the most expensive stage in a real-world pipeline is usually two orders of magnitude. Not running the cheap stage first is leaving free margin on the table.

The fourth lesson is to keep the central back end stateless about clients. The GMN back end does not have an inventory of stations that it polls. Stations push. New stations show up by uploading detections in the right format. Stations that go offline simply stop showing up in the morning batch. There is no enrollment server, no per-client capacity planning, no auth-token rotation cron job. The schema does the work that configuration management would otherwise do. Your distributed tracing back end almost certainly does not work this way, and I would bet that the engineering effort spent maintaining client-server state coherency is more than the effort spent on the analytics.

The fifth lesson is the one I think is most underappreciated, which is that the data format and the wire schema are doing a lot of the load- bearing work. The GMN detection bundle format is small, versioned, and boring. It has been backwards-compatible for years. It is what makes the "new station shows up by pushing" model possible. If the schema were churning every quarter, the network would have fragmented long ago. This is the part of the architecture that is least visible to the casual reader and most expensive to get right. It is also the part that foundation-model-era observability stacks tend to neglect, on the implicit assumption that the back end can absorb arbitrary client behavior. It usually cannot, and the cost shows up in operator pain later.

If you take only one transferable thing away from this whole post, I would make it the schema-stability point. Edge ML is the cool part. Backwards-compatible serialization is the load-bearing part. Both have to be there for the network to grow.

A note on the radiant geometry, for the readers who want the math

For completeness, the bit of the model that converts station-level detections into a zenithal hourly rate involves three corrections that non-astronomers are sometimes surprised to learn about.

The first is the radiant elevation correction. Meteors per hour scales with the sine of the radiant altitude above the horizon, plus a small atmospheric extinction term. A radiant low on the horizon produces fewer visible meteors than a radiant high overhead, because the line-of-sight path through the atmosphere is longer and more meteors burn up before becoming visible. The Eta Aquariid radiant for Northern Hemisphere observers does not get more than about 40 degrees above the horizon before sunrise, even at peak — which is why the rate caps at single digits at northern latitudes regardless of moon phase.

The second is the limiting magnitude correction. The visible rate depends strongly on the dimmest star you can see. A dark-sky site with a limiting magnitude of 6.5 sees substantially more meteors than a suburban site with a limiting magnitude of 4.5. Tonight's waning gibbous moon raises the effective limiting magnitude floor across the sky, suppressing the dim end of the meteor population. A factor of two to three reduction in observed rate from a moonless equivalent night is typical.

The third is the population index correction. Different showers have different magnitude distributions. The Eta Aquariids are a relatively bright shower with a population index around 2.4, meaning each step fainter in magnitude multiplies the count by 2.4. Showers with steeper indices have many more dim meteors than bright ones. The model has to know the population index for each shower to convert from counts at a given limiting magnitude to a "what would you see in dark, no-moon conditions" zenithal hourly rate.

All three corrections are encoded in the central pipeline, and all three are required to make the rate predictions match the network observations. None of them require novel machine learning. They require careful engineering and decades of cross-comparison data. This is the part that the network hands to the model as priors. The ML earns its keep on classification and clustering. The astrophysics earns its keep everywhere else. Both have to be right.

What to do tonight, and what to do tomorrow

Tonight, if you live somewhere south of about 30 degrees north and the weather cooperates, go outside between roughly 3 a.m. and twilight, look toward the eastern sky, and watch. The meteors come out of the constellation Aquarius, which will be rising in the east. You do not need binoculars. You do not need a telescope. (For people deciding what gear to buy if they want to take their amateur astronomy further into the AI-augmented direction, my smart-telescope comparison is the easiest place to start.) You do need a horizon and a dark sky. The waning gibbous moon will wash out the dim stuff, but the bright Eta Aquariids — and they tend toward bright, with long persistent trains because of their high entry velocity — will punch through.

Tomorrow morning, around 1,100 cameras will have done what they always do. They will have flat-fielded their frames, run the random forest, the CNN, the LSTM. They will have uploaded a few hundred megabytes of confirmed detections each. The back end will have triangulated, fit orbits, associated to Halley, run the cluster miner against the running catalog. The morning report will say something like "Eta Aquariid activity: zenithal hourly rate observed N at peak, consistent with model prediction."

The cleanest thing about this stack is that the report will be true, checkable, peer-reviewable, and produced for less money than a single month of inference on a frontier-model API. The infrastructure pattern is already deployed. The data is already public. The code is already on GitHub.

Most of "AI everywhere" still gestures at this kind of pattern as a future possibility. Look at the meteor people. They are five years ahead of the marketing.

Sleep early tonight. Set an alarm for 3 a.m. While you watch the sky, remember that the rate you are seeing has already been predicted, will be measured against, and will be used to refine the model that predicts next year's. The whole loop is running on consumer hardware in a volunteer's backyard. That is not a metaphor for the future of edge intelligence. That is what edge intelligence already looks like when it is allowed to grow without a procurement cycle.

The Eta Aquariids will peak whether you watch or not. The sensor network will not.