What my Seestar S30 Pro's optics do to star positions
Over the last six weeks I measured where thousands of stars land on the sensor of my Seestar S30 Pro, night after night, and compared them with the Gaia catalog. I also looked at frames that three other S30 Pro owners shared. This page collects what the optics do to star positions: how much the lens bends the field, how good the telescope's own plate solution is, where the coma sits, and which of these things belong to the model, to each unit, or to each night.
Everything here is small. One pixel is 3.67 arcseconds, and most effects below are a fraction of a pixel, far too small to see in a stacked picture. They matter if you measure positions or brightnesses from your frames: astrometry, asteroid and occultation timing, variable stars, exoplanet transits.
1.8–2.4 pxhow far the lens moves stars at the frame's corners (7 nights, my unit); smooth and easy to model
0.56 pxmedian error of the Seestar's own per-frame plate solution against Gaia (17 bright stars, one frame)
60–140°how far the coma's lean on the other units points from mine; each camera kept its own direction
30–260 masper-star position error, in thousandths of an arcsecond, that survives a whole night's average (12 nights, 4 units)
The lens is smooth, but it isn't fixed.
0.6–0.8 px
After a plate solver's scale takes up most of the distortion, a curved part of 0.6 to 0.8 pixel is left at the corners, and it changes from night to night. Fit it per night if you need sub-pixel positions.
Star images are slightly lopsided, and the direction of that lean stayed put on each camera across targets, filters and nights while it differed between cameras. Its size grows when focus is soft.
On three alt-azimuth nights with the light-pollution filter, the night-average positions sat 3 to 5 times above what random noise allows, because each star carried an error that stayed put all night. It was largest on soft-focus nights. Sharp focus and moving the stars across the sensor are the fix.
My own unit (I'll call it unit A) gave seven sets: M 31, M 33, two nights on NGC 7000, M 16 and two nights on M 27, all 10-second frames in alt-azimuth mode, with either the built-in light-pollution (LP) filter or the standard IR-cut filter. Each frame was plate solved, and every star was matched to Gaia DR3, which knows where each star is to well under a thousandth of a pixel. What's left over is the instrument, the air, and my measurement.
For the other three units (B, C and D) I had frames of NGC 7000 that their owners shared: unit B in equatorial mode with 10-second frames, unit C in equatorial mode with 60-second LP frames, and unit D in alt-azimuth mode with 20-second frames, with the IR-cut and the LP filter. For those I worked from small cutouts around each star, so the lens itself could only be compared roughly. My unit runs newer firmware than the other three.
Later, on 2 October, I recorded the transit of the planet HD 189733 b with my unit in equatorial mode, with the stars drifting slowly across the sensor. That night is its own page; its star-shape map appears below.
How sure: everything on this page is exploratory. Each result comes from the nights it was found on, and none has yet been repeated on a fresh night or unit with the method set in advance.
Lens distortion: my unit only. Its size is a design property; I couldn't measure the other units' lenses well enough from cutouts to say how much it varies between units.
The built-in plate solution: a check on one frame plus 44 frames of another target, on the firmware of that time on my unit.
Coma direction per unit: it held against every test I could run on four units, but it hasn't been checked on a fifth. The 2 October night was new data, and its spot landed close to where my unit's earlier sessions put it, but I compared them after the fact rather than predicting it in writing first.
Errors that don't average away: size measured, cause unknown.
Star color: my unit only.
Lens distortion
How the lens bends the field
one line per night (7 nights)a perfect lens at the best scale
How far the lens puts a star from where a distortion-free lens at the best-fitting scale would, against distance from the frame center (the corner is 2,202 pixels out). Positive is outward. Hover for values.
The S30 Pro's lens stretches the field slightly toward the corners, a mild pincushion. A star in a corner lands 1.8 to 2.4 pixels farther out than a perfect lens would put it. That's about 0.1 % of the distance from the center, smooth and symmetric, and any plate solver with distortion terms takes it up. Most of it looks like a slightly different plate scale. What a solver has to model beyond the scale is the curved part in the chart: about 0.4 to 0.5 pixel inward at mid-field and 0.6 to 0.8 pixel outward at the corners.
That curved part isn't the same every night. Over seven nights it ranged from 0.59 to 0.82 pixel at the corner, far more than the measurement errors allow: no single fixed lens fits all seven nights. I expected temperature to drive it, but two nights on NGC 7000 at the same sensor temperature still differed. Focus position alone didn't explain it either. The best single match was star size: on nights with bigger stars the curved part was smaller. That fits a measurement effect (the centering of blurrier stars interacting with the lens fit) better than a real change of the glass, but I haven't proven which.
Two smaller findings. A third radial term (the next power of the distance) wasn't needed on any night. And there is a small part that isn't radial at all, set in the sensor's frame, worth 0.13 to 0.22 pixel at most; a simple off-center-lens model misses it, but a general second-order term in the solver catches it. On the 2 October drift night, after a per-night model, no lens pattern above 0.04 pixel was left anywhere on the sensor.
The built-in plate solution
The Seestar plate solves its frames to know where it's pointing, and some saved frames carry that solution in their header (a WCS, the standard recipe for turning pixel positions into sky positions, here with second-order distortion terms). In my early captures only 97 of 3,120 frames had one (3 %), in two unbroken runs on two nights; the headers don't say why those frames and not the others. The stacked images the app makes mostly do.
Where it's present, it's real and good. On a test frame of M 33, the 17 brightest stars sat a median 0.56 pixel (2.1 arcseconds) from the header solution's prediction, at most 0.90 pixel. At the frame center it agreed with two independent solvers to 2.6 arcseconds. At the corners it differed from a full solve by 2 to 6 arcseconds. On 44 NGC 7000 frames it matched my solves to 1.2 arcseconds at the center (median) and 2.3 arcseconds at the corners (median), with one frame off by 52 arcseconds in a corner.
That is what it's built for: knowing where the telescope points, framing, and lining frames up for stacking, which it does well. It isn't built for positions to a hundredth of a pixel: second-order terms can't fully describe a lens whose distortion grows with the cube of the distance, so the corners carry half a pixel to a pixel and a half of leftover. One more practical note: the RA and Dec keywords in the header are the target you asked for, not the solved center of the frame. On my frames they were 0.2 to 1.4 degrees apart, so use them as a search hint for a solver, never as the answer.
Coma: stars lean, and every unit leans its own way
Coma makes star images lopsided: the light gets a faint tail on one side, so the star's light-weighted center sits a little off its peak. On the 2 October drift night I mapped that lean across the whole sensor. Away from one spot the stars lean outward, more so toward the edges, the signature of an optical axis that doesn't land exactly on the center of the sensor (or a small tilt between lens and sensor).
On that night the spot sat about 925 pixels from the center of the chip along its long side. So in the 900 rows at one end of the chip the stars leaned by a median 0.03 pixel, and in the 900 rows at the other end by 0.18 pixel. Because the mount tracked in equatorial mode, the direction of the horizon barely turned in the frame all night, and atmospheric color smearing would have made arrows that all point the same way. These arrows radiate from a point. One night with the horizon fixed in the frame can't rule out a small atmospheric share.
How star images lean across my sensor on 2 October (north up, east left): each arrow is how far the light-weighted center sits from the fitted center in that 240-pixel cell, magnified 2,000 times. The ring marks the point the pattern radiates from; the dashed arrow points toward the horizon. Hover a cell for its value.
The same lean shows up as a constant offset of the star shape at the center of the field, and that offset has a direction. On my unit it pointed the same way, within 23 degrees, over seven sessions, five targets and both filters. On the other units it pointed 60 to 140 degrees away from mine, and stayed put on each of them across its own nights and filters. Unit C's was almost zero: as far as this measure goes, its optics were the best centered of the four. The map below shows where each session puts the spot where the coma vanishes.
unit A (mine), 7 sessionsunit B, 2 setsunit C, 2 setsunit D, 2 armsunit A, 2 October
Where the coma vanishes on the sensor, per session, in the sensor's own frame (the long side vertical, as the camera writes it). The ring is the spot from the 2 October map above. Each unit keeps its own place; my unit's sessions scatter along the long side, so the direction of the offset is steadier than the spot's distance from the center. Hover a mark for the session.
How big the lean is depends on focus. On my unit, the growth of the lean from center to corner went from 0.06 pixel on a sharp night to 0.32 pixel on my softest night. So the direction belongs to the camera, and the size belongs to the night.
I checked whether anything else could explain the direction. The direction didn't move with how fast the field rotated (a 13-fold change), with the target's altitude over a wide range, with how I computed star centers, with the green pixel used, or with star brightness or color: no test turned it more than 15 degrees on my unit. One caveat remains: in alt-azimuth mode the camera's frame stays locked to the vertical, and my unit's direction happens to point almost straight away from the zenith, so for my unit alone a cause tied to gravity can't be ruled out. Unit D, also alt-azimuth, points about 140 degrees away from mine, which argues against a shared alt-azimuth effect. Units B and C differ only barely, so the per-unit claim rests on A, B and D.
What belongs to the model, the unit, or the night?
For each quantity I asked two things: does it change from night to night on one camera (within-unit spread), and does it differ between cameras (between-unit spread)? Before running the comparison I set, for each quantity, the size that matters and three labels. A quantity is per unit if cameras differ by more than three times their own night-to-night spread; per session if one camera already moves more than the size that matters; unclear otherwise, or when the camera that differs also differs in mount, exposure or filter.
between unitswithin one unit, night to nightthe size that matters
Spread divided by the size that matters, decided before looking (log scale). To the right of the dashed line a quantity changes enough to matter. Hover a row for the numbers.
Almost nothing in the optics is a constant you could look up once for every S30 Pro. Star size, how fast the coma grows toward the edge, the lens's curved part and the per-star error a night keeps all change from night to night on one camera, so they have to be measured every session. The coma's direction is the one optical property that is a stable fingerprint of each camera. The only true model constants I found were in the sensor's electronics (the steps in which its converter rounds values, and the balance between its two green pixels), not in the optics.
Errors that don't average away
Average a star's position over a night of frames and random errors shrink. Some don't. On a few alt-azimuth nights, each star carried an offset that stayed the same in every frame, so the night's average kept it. It pointed mostly along the line from the center of the sensor and grew toward the edges.
alt-azimuth modeequatorial mode
Typical per-star error of the night average for moderately bright stars (Gaia G magnitude 11 to 12), in milliarcseconds (1,000 mas is one arcsecond, one pixel is 3,674 mas). “Fixed part” is the error that the night's odd-numbered and even-numbered frames share, so it can't be random noise. The number after each night is its median star size (FWHM) in pixels. Hover for details.
On three nights this fixed part was large: 260 mas on my softest-focus night on NGC 7000 (stars 4.8 pixels wide), and 140 and 257 mas on unit D's two LP nights. Unit D on the same field and night with the IR-cut filter instead kept only 57 mas. On my other five nights it stayed at 44 to 117 mas, and the two equatorial units, whose stars wander across the sensor during a mosaic, kept 30 to 48 mas. That's 0.01 to 0.07 pixel: small, but it sets the floor for anyone averaging positions over a night. Even on my unit, on the same field with the same filter, it ran from 54 to 260 mas between two nights, so its size belongs to the night.
The obvious explanation would be that alt-azimuth mode keeps each star on one spot of the sensor all night (my NGC 7000 field barely rotated), so whatever error that spot gives a star repeats in every frame. But I can't separate the mount from the unit and the focus here: the equatorial nights were also different cameras in sharper focus. I tried about a dozen candidate causes as corrections, each checked against a placebo version: refraction by the air, the star's color from Gaia and from the frames themselves, focus, field-rotation smear, faint neighbors, the nebula's glow under the star, and borrowing one night's offsets for another. None removed it. A term for star color times distance from the center took out about 20 % on one night and nothing elsewhere. What sets the rest is still open; the fix is in capture, not software.
Star color moves positions a little
Red and blue stars don't land in exactly the same place relative to each other. On my unit, a star one magnitude redder in Gaia's color index sat about 130 to 145 mas (0.04 pixel) away along one axis of the sensor, fixed to the sensor, on two targets. Along the other axis a smaller part remains after removing what the air's color refraction explains. The size depends on how a star's center is computed (2.7 times larger with one method than another on the same stars), which points to coma interacting with color rather than a simple prism effect. With the LP filter there's a hint of an extra color effect that grows toward the edges, seen on one soft night, not settled. A per-night position model that includes a color term handles most of it.
What this means for your stacks
For pictures, none of this shows.
A lean of 0.1 pixel is 0.4 arcsecond, a fraction of the star's own width. Stacking software lines frames up on many stars and takes up the smooth lens distortion as it goes. If your stars look fine, they are.
Focus is the biggest lever.
Soft focus made everything here worse: the coma's lean grew five-fold from my sharpest to my softest night, and the largest night-average errors came on soft nights. If your setup lets you refocus during a session, do it, especially as the evening cools; on my unit the plate scale follows the temperature through a night, and the focus position the telescope chose tracked the temperature from night to night.
Move the stars across the sensor.
Errors fixed to a spot on the sensor only average out if each star visits many spots. If your capture setup can dither, turn it on, and dither in both directions: on my 2 October night the stars drifted 900 pixels one way but only 85 the other, and the leftover error lined up with the direction that barely moved.
Keep what you measure near the middle.
Distortion, coma and the fixed per-star errors all grow toward the edges. For photometry or positions, put the target and its comparison stars in the inner part of the field. On my unit the best-behaved spot isn't the exact center of the chip, and on yours it will be somewhere else, so a quick map like the one above is worth doing once per camera.
Solve every frame, and fit the lens per night.
If you need sub-pixel positions, plate solve each frame with a solver that fits distortion, and fit the lens again each night rather than reusing one from another night. Treat the header's RA and Dec as a hint, not a position, and the built-in solution as good to about half a pixel.
Fair to the Seestar
Some of this is design and some is the normal spread between units, and they're worth keeping apart. The lens's pincushion is a property of the design: smooth, about 0.1 % of the field, and modeled by any good solver. The coma's direction is unit-to-unit spread, as you'd expect from assembling any small optic to a tolerance; the offsets are hundredths to a tenth or so of a pixel at the center of the field, and one of the four units was almost perfectly centered. I measured four units of one model, mostly on one field. I can't say how other units, other Seestar models or other brands compare, and I haven't tried.
The built-in plate solution does what it was designed for, pointing, framing and stacking, and does it well. It was never meant for positions to a hundredth of a pixel, and it shouldn't be judged as if it were. Everything on this page needed raw frames, a star catalog and a lot of fitting; that the telescope saves raw frames with full headers is what made it possible.
What was fixed and what was measured
Fixed in advance: Gaia DR3 star positions as the truth, moved to each frame's date; the camera's pixel size and focal length from the header (the measured scale, 3.672 to 3.674 arcseconds per pixel, agrees); for the unit comparison, the size that matters for each quantity and the per-model, per-unit and per-session rules, written down before the comparison ran (some per-unit numbers were already known from earlier work); and before each run, a written prediction of what I expected.
Measured: every number on this page. Errors come from resampling frames or stars; where a number is a range, it's the range over nights or units.
What went wrong, and what's still open
Early on, one night (M 31) seemed to need a stronger lens model at the very edge. It didn't: about 5 % of its stars sit in the crowded disk of the galaxy, and their bad positions piled up at the edge. Once I set them aside the edge was clean.
I expected temperature to drive the night-to-night lens change. It didn't, and I still don't know what does. Star size is the best match, which may mean it's partly my measurement.
I expected star elongation and the normalized coma growth to be per unit too. The data can't say: the unit that differs most (D) is also the only one with 20-second frames.
A failed drive took the other units' full frames with it, so the unit comparison runs on cutouts around stars. The lens couldn't be compared between units properly.
The equatorial and alt-azimuth nights also differ in unit and focus, so “alt-azimuth keeps the error” isn't proven. A night split into dithered and undithered halves would settle it.
What sets the fixed per-star error beyond star color is unknown.
The next steps are a fifth unit for the coma direction, and a dithered night with logged focus for the fixed per-star error.
Skycruncher
experiment, October 2026