On the night of 2 October 2026 I pointed a Seestar S30 Pro at HD 189733, a star 64 light-years away in the constellation Vulpecula, and recorded 544 ten-second frames over three hours. Halfway through, right on schedule, the star dimmed by about 2.5 %. That dip is its planet, HD 189733 b, passing in front of it.
In the headline view I fit only the depth and the mid-time. The transit's length and the planet's path across the star come from the published orbit, so my line meets the prediction at the start and end by design. The shaded band is the range my data allow: 68 % of the plausible fits fall in the darker band and 95 % in the lighter one, counting the spread from the choice of comparison stars and the uncertain baseline. It is about ± 0.24 % wide at mid-transit and widest, about ± 0.5 %, on the sloping edges, where a timing shift of a few minutes matters most. Choose “Shape from my data only” and the orbit's size and the planet's path float too. Then the transit could last anywhere from about 92 to 156 minutes (68 % range; published 109), the path could cross anywhere from near the center to near the edge (b from 0.18 to 0.86; published 0.66), and deep grazing paths can't be ruled out, so the depth's range stretches from 2.0 to 5.1 %. One night with a 30 mm lens pins down the depth and timing well once the shape is known, but not the shape itself, which is why the headline borrows it. The headline numbers are the middle and the 68 % range of the plausible fits in the published-orbit view. They differ slightly from the single best-fitting line (2.56 % and 0.3 minutes early), and the timing range is wider than my first quick estimate of ± 3.0 minutes, because the data allow a broad spread of mid-times around a sharp best fit.
The star dimmed by 2.50 % (± 0.34), against about 2.45 % measured by large telescopes, and the middle of the transit came 1.0 minute before the prediction (± 3.6).
The light curveSwitching from 7 hand-picked comparison stars to 98 chosen by fixed rules cut the scatter of the 10-minute averages 2.3 times and moved the mid-transit from 14 minutes late to on time. No cleanup step came close.
Choosing the comparison starsNoise shared by all three colors, most likely twinkling from the atmosphere, adds up to about 2.3 % to every 10-second frame, the largest single term. Cleaning the images didn't lower it; only collecting more light per measurement does.
Where the noise comes fromHD 189733 b is a hot Jupiter: a gas giant a little larger than Jupiter, circling its star so closely that its year lasts just over two days. Its orbit is edge-on to us, so once per orbit it crosses the face of its star and blocks about 2.5 % of the light. Measure the star's brightness carefully through the crossing, and the depth of the dip tells you how big the planet is, while the timing tells you exactly where it is in its orbit.
Yes, and the reason is limb darkening. We see deeper, hotter layers at the middle of a star's disk and cooler, dimmer layers near its edge. So the planet blocks more light when it is over the middle. For HD 189733 b in green light the dip is about 2.6 % at mid-transit but only about 2.1 % at the moments the planet's disk becomes fully inside the star's (about 30 minutes either side of the middle). Between those moments the curve sags; there is no flat floor. Large telescopes measure that curvature precisely. My data are noisier, so I fixed the curvature to published stellar-atmosphere values rather than measuring it. As a check, I also fitted a flat-bottomed (uniform star) model to my data: the rounded shape fits slightly better, but only at about the 2-sigma level, so on its own this night can only hint at it.
Not necessarily. The planet's path crosses the star at 66 % of the way from the center to the edge (astronomers call this the impact parameter, b = 0.66). A path that far above the center and one that far below it give exactly the same light curve, so brightness alone can't tell them apart, and on the sky "up" has no fixed meaning for a distant star anyway. I drew it below center. I also didn't measure the path myself: the orbit's size and tilt, and so the path across the star, come from published measurements. They are why the transit lasts 1 hour 49 minutes in my model, with the planet fully inside the disk for only about an hour of it. My data agree with that shape, but they are too noisy to pin it down on their own.
A 2.5 % dip is small. The atmosphere twinkles, haze drifts through, and the star sinks lower in the sky and fades. The trick is to measure HD 189733 against other stars in the same frames: whatever the sky does to them, it does to my star too, and dividing one by the others cancels it.
HD 189733 started high in the southwest and sank toward the west through the night. As it sank, its light passed through more air: the airmass doubled from 1.1 to 2.3, the sky behind it brightened, and the stars blurred a little.
Here is the raw brightness of HD 189733 and of the eleven reference stars I picked before the night, each scaled to its own median. Everything fades together by about 20 % as the field sinks into thicker air. The transit is in there, but buried under that fade.
Do the same for each reference star, dividing it by the rest, and you get the classic check: only HD 189733 dips. Every other panel stays flat within its own noise. The bright references stay flat to about 1 % per 10 minutes; the fainter ones wander more because they collect fewer photons, not because they vary. Each panel has its own scale, set by that star's noise, and the shaded band is the predicted transit.
The Seestar's frame is 2.2 by 3.9 degrees, which holds hundreds of usable stars. I chose them by rule from Gaia DR3, not by eye: magnitude 7.6 to 10, no bright neighbor within 37 arcseconds, at least 60 pixels from every edge in 95 % of frames despite the drift, not flagged variable by Gaia, and steady outside the transit. That gave 98 stars.
Why not just a handful of bright stars near the target? My first pass did exactly that with 7 stars, and two of them carried 60 % of the light. Any small set inherits the wobbles of its few members. The chart below shows what that does to the timing: I drew many random 7-star sets from the same field, refitted the transit with each, and plotted where the mid-time landed.
Small sets scatter by about 9 minutes, almost three times the formal error bar of a single fit. My first pass landed in their late tail. The large set holds steady within a few minutes.
In the green pixels alone, each 10-second frame measures HD 189733's relative brightness to about 3.2 % (2.7 % with all three pixel colors). Averaging frames beats that down: for pure random noise, averaging N frames shrinks the scatter by the square root of N. If the scatter stops shrinking, something slower (haze, drift, an imperfect reference) is in the way. Here it keeps shrinking all the way to 10-minute averages, which is why the transit stands out so clearly.
In the green pixels, each 10-second frame measures HD 189733 to about 3.2 %. That number breaks down into four ingredients, which add like the sides of a right triangle (in quadrature), so the biggest one dominates. The biggest is the atmosphere itself: turbulence high above the telescope makes a star twinkle, and through a 30 mm lens in 10 seconds that twinkling is worth up to about 2.3 % per frame. I estimated it from the noise that all three colors share: photon noise is independent in each color, but twinkling hits them all at once. Anything else the colors share, such as thin haze or errors in the comparison stars, lands in the same bucket, so 2.3 % is an upper limit on the twinkling itself. As a sanity check, the standard formula for twinkling (Young's) predicts about 2.7 % for a 30 mm lens at this airmass, with an uncertainty of tens of percent for lenses this small, so the shared noise is the size twinkling should be.
That explains why no clever processing step moved the scatter: there is no slow drift or haze left to remove, only twinkling and photon counting. I tried weighting the comparison stars by their own noise, throwing out single bad measurements, regressing against seeing, sky and position, and a Gaussian-process model of slow trends. None of them changed the result. What does help is more light per measurement: longer or more frames, a bigger telescope, or using more of the light the camera already records, which is what the three-color fit does. Twinkling is the same in every color, so combining colors shrinks only the photon and sky parts.
The light-pollution filter only lets two narrow slices of the spectrum through: one around 500 nm, where glowing oxygen shines, and one around 656 nm, where hydrogen does. Behind it, the sensor has red, green and blue pixels. The red pixels see the 656 nm window. The green and blue pixels both see the 500 nm window, so they catch the same color of light; blue pixels are simply less sensitive there, which makes them a noisier second look at it. So the camera really records two colors of light through three kinds of pixels.
A star's edge darkens more in bluer light, so the transit is a little deeper and more rounded at 500 nm than at 656 nm. Fitting all three pixel types together, each with the limb darkening for its window, uses about twice the light of the green pixels alone. That is the version at the top of this page.
Applying my four cleanup steps (hot pixels, a sky model, faint neighbors, a measuring circle matched to the seeing) to every color took two tries. The first time, the sky model broke the red and blue pixels. The camera records each pixel in steps of 16 counts. Green has two pixels in every 2 by 2 block, so its sky moves in finer steps; red and blue have one each, and the sky model, which looks for the most common value, jumped by about a dozen counts from frame to frame. That was enough to wash out the dip in red completely. Measuring the sky for red and blue in a ring around each star instead fixed it. At their best fits the cleaned version gives the same depth as the plain one, 2.56 %, and moves the mid-time from 1.1 minutes late to 0.3 minutes early: on this night the cleanup changes the timing a little, not the depth or the scatter.
The combined fit cuts the scatter per frame by 16 % and the 10-minute scatter from 0.57 % to 0.42 %, and its depth, 2.50 % (2.56 % at the single best fit), lands close to the published 2.45 %. A note on how sure I am: before each run I wrote down a test. The first one (inject a fake transit into some comparison stars and require the fit to recover it within one sigma) came back 1.9 sigma high on the plain three-color fit, because those comparison stars show small wiggles of their own in the same window; the green-only reduction fails it too. So for the cleaned version I wrote down a stricter set in advance: subtract each star's own wiggle before judging the fake transit, require all three colors to agree with the combined result, and require the depth to agree with the published value. It passed all three: the fake transit came back within 0.7 sigma, each color within 0.9 sigma of the combined depth, and the depth within 0.4 sigma of 2.45 %. This night was used to choose these steps, so it can't confirm them; the 22 October transit will.
I followed three extra stars exactly like the target. They should show nothing. Two are flat within their noise. The third, Gaia DR3 1833060194784500608, seems to dip by about 12 %: it read about 5 % brighter at one spot on the sensor, which it happened to visit before the transit. That is an instrument effect, not a second planet: perhaps where the star fell within the pixels of each color, perhaps an uneven patch in the sensor's response, and it is exactly why check stars are worth carrying.
Driven over Alpaca, the Seestar's mount ran about 3 % fast, so the stars slid across the sensor. Then its firmware corrected itself three times, each time jumping half a degree and pausing. After that the field crept along at about a pixel a minute. The chart traces where HD 189733 sat on the sensor all night.
The drift had an upside. Every star swept across hundreds of pixels, so by comparing each star with itself at different spots, I could map how the sensor and optics respond across the frame, without flat frames. The center reads about 1.7 % brighter than the edges along the drift direction.
Every observing run has surprises. These are the ones that shaped this light curve, and what I'm changing because of them.
The three firmware corrections, at 22:08, 22:14 and 22:19, landed exactly as the planet started to cross. I set the smeared frames aside, and the measurement holds up without them. One trick helped during the night: I re-centered the field ahead of the drift, so the drift carried my stars across the sensor instead of off it.
Recording began 49 minutes after plan, leaving about 20 minutes of steady data before the transit began. The depth doesn't mind, but the exact mid-time leans on that baseline, so my timing (1.0 minute from the prediction) carries a wide error bar, ± 3.6 minutes. Next time I start at least an hour early.
I set the focus once and never adjusted it, so stars came out about 1.7 times wider than the Seestar app gets them. For the transit that was probably a help. Each pixel covers 3.67 arcseconds, and on a color sensor each color only samples every other pixel, so a sharp star's brightness in each color depends on exactly where it lands within the pixels, and this star was drifting. Spreading the light over more pixels smooths that out, which is why transit observers often defocus on purpose. Sharp stars are better for star positions and for faint stars. So next time I'll keep the stars soft through the transit and focus sharply afterwards, for positions.
Going from 7 hand-picked stars to 98 chosen by rule cut the scatter by a factor of 2.3 and brought the timing from 14 minutes late to within 2 minutes. Removing Gaia-flagged variable stars from the set also moved the depth closer to the published value.
Once the comparison set was right, I added standard corrections one at a time and refitted the transit after each, to see what each one actually buys.
| Idea | Effect on this light curve |
|---|---|
| A larger, rule-based set of comparison stars | The big one: 2.3 times less scatter and a much better mid-time |
| Removing hot pixels using dark frames | No measurable change |
| Modeling the sky glow instead of a local ring | No measurable change |
| Subtracting faint neighbor stars from Gaia | No measurable change |
| Matching the measuring circle to each frame's sharpness | Small improvement |
| Summing all four color channels into one | 13 % less scatter, but a biased depth because each color darkens at the edge differently (fixed by the per-color fit) |
| Stacking frames in 5-minute groups before measuring | Same answer, slightly more scatter than averaging the measurements (below) |
| Weighting comparison stars by their own noise | No improvement (the flux cap was already close to optimal) |
| Rejecting single bad comparison measurements | No measurable change |
| Regressing against seeing, sky, position and airmass | None chosen by the fit statistics; no change |
| A Gaussian-process model of slow trends | Found no slow trends to model |
| Fitting each star's shape instead of a fixed circle | About 4 % less scatter per frame, no change per 10 minutes |
| Fitting all three pixel colors together | 16 % less scatter per frame |
| The four cleanup steps in every color, then the three-color fit | Same depth, mid-time 1.4 minutes earlier (the sky model needed a fix for red and blue): now my main result |
For a star this bright in 10-second frames, the limit is photon counting and atmospheric twinkling, which no calibration step removes. More light per measurement (more frames, a bigger telescope) is what buys precision.
The same frames also measure where every star is. Matching thousands of Gaia stars frame by frame, then averaging each star over the night, places the brighter ones to about a tenth of an arcsecond, around a thirtieth of a pixel.
I first ran my standard position pipeline unchanged, then improved it one step at a time: a Gaia catalog covering the whole frame, fitting each star's actual shape instead of a fixed bell curve, fitting faint neighbors so crowded stars can be used, and building an empirical star shape for every frame. The best version measures each faint star 19 % more precisely per frame and can use three times as many crowded stars.
Per frame, the improvements pay off. For the night average they barely move the bright stars, which sit well above what random noise allows. Something else limits them: a small error, about three hundredths of a pixel, that depends on where a star sits on the sensor. Fitting the star shapes revealed what it is. Away from one point on the sensor, the stars are slightly lopsided, with their light pulled outward like a faint comet tail. That is coma from the optics.
The pattern is not centered on the chip. Fitted as a pattern radiating from one point, it centers about 925 pixels above the middle of the sensor, toward the north end of the field. So at the same distance from the chip's center, stars at the top are skewed by about 0.03 pixel and stars at the bottom by about 0.18 pixel. That points to the lens's optical axis landing off-center on the sensor, or a small tilt between them.
Could it be the atmosphere instead? In this frame north is up and east is to the left, so the bottom of the frame is due south. The direction toward the horizon sat about 60 degrees away from that, down and to the right, and because the mount tracked the sky in equatorial mode it turned by only about 7 degrees all night. Air near the horizon bends blue light more than red, which smears every star a little in the same direction, toward the zenith. That would show up as arrows all pointing the same way across the whole field. The map instead shows arrows pointing outward from one spot, which is the signature of the optics. One night with the zenith almost fixed in the frame can't rule out a small atmospheric share. A night with the field rotating (alt-azimuth mode), or the same field on the other side of the meridian, would separate the two.
I then tried a star-shape model that changes across the field, built separately for 45 patches of the sensor. It sharpened the night-average positions of the brightest stars (Gaia G 9 to 10) from about 115 to about 90 milliarcseconds, and it beat a control run in which the patches were shuffled at random, so the gain comes from the real layout of the blur. Fainter stars barely changed, and the brightest stars still lean slightly toward the pattern's center, so the model captures only part of the coma. The patches were too small for the number of clean stars in this field; a simpler model with a few numbers for how the blur grows from its center is the next try. Like everything on this night, it's exploratory until a second night confirms it. The next step for positions is sharper focus, taken after the transit so it doesn't cost the brightness measurements.
HD 189733 b transits again on Thursday 22 October 2026, mid-transit at 22:21 PDT (ingress 21:26, egress 23:15 PDT), well placed for the western United States. Before that night I have written down every step of the reduction above, the comparison-star rules and what counts as a good result, so the second transit is a true test rather than a rerun. I'll start an hour early, keep the stars slightly soft through the transit, focus sharply afterwards for star positions, and keep the mount settled. I'll also keep the light-pollution filter, because the method I wrote down is built around its two windows. After that night I want to try without it: the filter throws away most of the starlight, so removing it should cut the photon noise, though from a suburban sky it also lets in much more sky glow. If you have a Seestar or any small telescope, join in: simultaneous light curves from several places separate what the sky does from what each instrument does.
The raw frames (with location details rounded), dark frames, 5-minute stacks, the full list of comparison stars with their Gaia IDs and weights, both light curves, and a write-up of the method are in a shared folder: HD 189733 b transit, 2026-10-02. Reduce it your own way and tell me what you find.