How does the Solar System Pipeline handle a very fast same-visit object spanning multiple Rubin detectors?

LienaDreams · June 28, 2026, 7:10pm

Hello,

I have a question for Solar System Pipeline experts.

I am seeing cases where a very fast object appears to cross multiple Rubin detectors within a single visit, producing several alerts with the same timestamp but different sky positions.

Example below has seven alerts across three detectors (118, 119, 126) line up perfectly in RA/Dec on the night of June 26, 2026, visit 2026062600737. Based on its flux, extendedness, trailLength, reliability score and cutouts it looks like the same object. But if interpreted as one moving object during a single exposure, the implied angular speed is extremely high (over 1000 deg/day).

Since a SkyBot/MPC search does not provide a consistent identification for these alerts, I am looking for a way to identify them, and, if possible, follow-up them with a telescope.

I understand that a meaningful orbit or velocity cannot be derived from alerts sharing the same timestamp, but I am curious how does the Rubin Solar System Pipeline treat these events? Have you found a practical way to identify or distinguish these events in the alert stream? Would an event like this be considered a many-point tracklet by the Solar System Pipeline, despite all seven alerts sharing the same timestamp?

Below are diaObjectId of these 7 alerts, their motion plot and cutouts

diaObjectId:
170591527057228257,
170591527057228205,
170591527053558166,
170591527053558053,
170591527053557997,
170591527053033643,
170591527053033605,

Motion plot

Cutouts

recoil77 · June 28, 2026, 8:35pm

I think this is probably not a Solar System object after all.

Since all seven detections come from the same visit / same timestamp, the line is most likely a single artificial object crossing multiple detectors during one exposure, rather than a many-point SSO tracklet.

Using the hard-trail detections, the visible span is about 2457.0 arcsec, or 0.683 deg. For a 30 s LSST exposure this gives roughly:

81.9 arcsec/s ≈ 1966 deg/day

In my Rubin alert data I see many tens of thousands observations, of similar same-visit linear events. On visit-level sky-position visualizations they often appear as long straight stripes crossing detectors. These have to be detected and filtered out at scale, otherwise they can easily contaminate moving-object candidate searches.

So I treat this as a likely satellite artifact, not as an SSO candidate for follow-up.

LienaDreams · June 28, 2026, 10:07pm

@recoil77 Thank you, Anton, yes, looks like a satellite, and it makes sense taking into account its speed and orbit. I also see many of these objects, so it’s good to know what they are. Now I can focus on more promising candidates.

jrob93 · June 29, 2026, 12:38pm

Hi @LienaDreams, thank you for sharing these interesting detections. I agree with @recoil77 that these are most likely associated with an artificial satellite, the trailAngle looks to be consistent with the ra, dec motion. The detections appearing as separate sources indicates that the object could be rotating rapidly and glinting. Cool stuff!

LienaDreams · June 29, 2026, 2:07pm

yes, thank you, it is rotating and glinting, the flux varies between 23, 255 and 55,316. Maybe it is not one satellite, but a Starlink train. Moreover I caught one just yesterday.

On the other hand, when I was observing 3I/ATLAS in November 2025, I also captured a Starlink train in one of my images and measured the magnitude of one of its satellites at about 12.8. The object we’re discussing here is around 20–21 mag, which is a very large difference. So perhaps this isn’t a Starlink train after all.

jrob93 · June 29, 2026, 4:33pm

I hadn’t thought of a satellite train, seems like a sensible explanation though. I’ve not done much satellite analysis myself but your findings gave me a good excuse to play around with SatChecker which can be used to identify satellites in the field of view.

Assuming I ran it correctly here’s the potential matches it finds for your visit, there’s a nearby Starlink but nothing that matches those detections:

nealmcb · June 29, 2026, 6:12pm

Good discussion and links! I’ve seen several Starlink trains visually and in binoculars; they’re usually much more spread out than these traces show, except very briefly after launch. I also doubt that a starlink sat would be tumbling like that - each should leave quite a trail for a 30-second exposure.

I agree some other tumbling satellite or debris object makes sense. If it doesn’t show up in the usual searches, and since I think Rubin takes steps to deal with known / tracked satellites, perhaps it’s something we don’t have tracking data for. It might be worth sharing the time, field/visit, cutouts, apparent angular rate, and sky path with satellite/debris trackers — e.g. folks in SeeSat-L, Satobs, CelesTrak/Space-Track users, or observers who do optical satellite identification.

recoil77 · June 29, 2026, 6:40pm

Thank you, that makes sense. I agree that “Starlink” was probably too specific without an actual satellite match. “Satellite/debris/single-exposure trail” is a safer description.

I checked the scale in my local processing. So far my local satellite_trail_detected exclusion class contains 74,855 alert detections across 80 dates, from 2025-11-02 to 2026-06-27. My hard-trail grouping step has produced about 73,032 local trail hypotheses. The median group has 5 points, the 95th percentile is 8 points, and the largest group has 44 points.

Important caveat: these are my local alert-stream exclusions, not an official Rubin SSP/RSP classification. The filter is intentionally conservative: it normally does not remove groups with fewer than 5 points. Four-point groups are excluded only when the geometry and apparent motion are very strongly consistent. I would rather leave some satellite/debris artifacts in the candidate stream than accidentally remove real moving-object detections.

So I agree with your interpretation: for this particular case I will treat it as a likely artificial object / debris trail, not as an SSO follow-up target. Your suggestion about sharing stronger examples with satellite/debris trackers is useful. If helpful, I can provide either a compact package for a few representative cases, or the full set of IDs/metadata/artifacts for the local trail hypotheses. I can adapt the format to whatever would be most useful.

recoil77 · June 29, 2026, 11:49pm

Small follow-up, and thank you to everyone in this thread — especially for raising this issue in the first place. It made me go back and re-check my satellite/debris filtering more carefully.

I think the earlier 74,855 number should not be interpreted as “74k confirmed satellite trails”. That was the old exclusion layer based mostly on same-visit line-group membership. After re-auditing it with better use of trailLength / trailAngle, I now treat line membership only as context, not as hard evidence by itself.

The updated logic is:

same-visit line group = trail/artifact hypothesis
hard exclusion = only if the individual alert has supporting trail morphology

In numbers:

old satellite_trail_detected rows:     74,855
hard satellite/debris rows after audit: 21,825
kept from satellite layer:              53,030

The important caveat is that most of the difference comes from already-bad dense January visits. Those visits look technically/astrometrically unusable in my processing and were already excluded by a separate bad-visit/raw-visit layer. They produced huge numbers of alert-like detections, so the old line detector also found many line-like groups inside them.

kept from satellite layer:              53,030
actually returned to active surface:     9,579
still excluded by bad-visit layer:      43,413

So the main correction is not “74k were false and now active”. It is that many rows inside bad January visits should not be called confirmed satellite trails just because they lie in same-visit line groups.

For the active search surface, the practical rule is now more conservative:

line membership alone is not enough;
trailLength must be significant;
trailAngle must agree with the fitted line axis modulo 180 degrees;
angle outliers, short trails, and points without local trail evidence are kept;
very small groups are only removed in strict cases.

This seems safer for blind Solar System candidate search: remove alerts only when there is per-alert evidence for a satellite/debris trail, and keep ambiguous detections for later hypothesis testing.

Comments from Rubin pipeline / SSP people would be very useful here, especially on whether this is a reasonable downstream way to handle same-visit multi-detector line structures in the alert stream.

LienaDreams · June 30, 2026, 2:06pm

exactly and thank you for sharing your logic. I agree with filtering using trailLength and other parameters. I also think that older data may differ and create false expectations depending on your goal.

For example, when I used Rubin alerts from February 2026, I saw many good tracklets for asteroids: up to 200 detections per night, which allowed me to identify the object with high confidence and predict coordinates for telescope follow-up. Starting from March 2026, Rubin switched (correct me if I am wrong) to the standard cadence of two visits per night. For moving objects, this immediately increased the lack of data needed to build an orbit and predict coordinates for unknown objects. Nevertheless, even with only two detections there are interesting candidates almost every night, so I continue my observations.

For my goal of finding unknown moving objects for telescope follow-up, I use the following filters on the Fink broker data stream:
1. alerts cross-matched as unknown or failed in SIMBAD;
2. diaSource.extendedness > 0.5;
3. diaSource.trailLength > 1.0;
4. diaSource.apFlux > 1000;
5. diaSource.reliability > 0.8.

Why these filters? I studied how known comets and asteroids appear in Rubin alert data and selected these parameters as the most useful for identification. Of course, I could relax the filters, but I don’t do that because my experience shows that broader filters produce many unreal candidates simply because Rubin detects so much. The sky is full of alerts, and if I consider all of them and try to build meaningful orbits, there is a high risk of combining detections from different objects into one candidate.

After filtering, my pipeline builds ranking tables by speed, flux, extendedness, and comet-like score, based on additional configuration that I apply before ranking, including the minimum number of detections and minimum speed. Then I manually inspect the TOP 20 candidates and decide whether any of them are worth telescope follow-up.

The object that started this discussion appeared several times in my TOP 20 extendedness ranking table with the configuration “1 detection” and “minimum speed = false”. That is how I discovered it.

Zhuoxiao · June 30, 2026, 2:47pm

The PA and speed matched a sub-meter size rocket debris object [25809, 1987-079U] perfectly, when it was passing its apogee ~9000km above surface.
And the 7 arcmin cross-track offset, could come from the radar orbit determination error for this tiny debris with high altitude.

Astropaparazzo · June 30, 2026, 2:48pm

“The object we’re discussing here is around 20–21 mag” solidly put the satellite issue in perspective for me in relation to LSST.

I image deep-sky objects from my location just about as often as I have clear nights, and satellite trails are a familiar nuisance to me, but my equipment only includes a 100mm refractor, a 127mm Maksutov, and a 203mm SCT, primarily feeding a passively cooled camera based on the IMX715 detector managed with the SharpCap software. Everything I can detect, I can assume is already cataloged by someone else with more powerful equipment, and can presumably be identified from existing databases.

I confidently predict that LSST is going to record artificial satellites (probably a great many) that have never been cataloged before, and that previous or existing satellite tracking projects have been unable to detect. I’m very new here, and am not yet familiar with much of the work that is already being done at Rubin.

Has artificial satellite tracking data discovered by LSST been considered as a deliverable, rather than just as a nuisance to be filtered? I expect that there exist user communities that would find it useful.

nealmcb · June 30, 2026, 3:55pm

Cool - thanks, @Zhuoxiao !
Here is a record for the object: SL-12 DEB (NORAD 25809) - Satellite Tracker | KeepTrack with more details and visualizations.
I don’t see that rotation speed is being tracked, but that’s something these sorts of observations could add.

The object we’re discussing here is around 20–21 mag

Determining the magnitude for something moving this fast strikes me as being tricky. Can you share where that estimate comes from?

recoil77 · June 30, 2026, 4:42pm

Thank you, this is very interesting. I agree that the goal changes the whole filtering strategy.

Your workflow sounds like a high-purity follow-up selector: reduce the alert stream to a small number of promising objects, inspect the TOP candidates manually, and decide whether telescope time is justified. In that mode, strong early filters like extendedness, trailLength, flux, and reliability make a lot of sense.

My workflow is almost the opposite: bulk hypothesis generation first, then destruction or confirmation later. I try to remove known objects and obvious artifacts as aggressively as possible, but for unknown candidates I prefer not to apply too many strong priors before building hypotheses.

At the moment my active hypothesis surface contains roughly:

active tracks:    ~2,800
active tracklets: ~2,800

These are not confirmed discoveries, only working hypotheses.

The rough flow is: build same-night tracklets, link tracklets across nights, let orbits stabilize as new data are added, then re-run daily and attach new observations to existing tracks. After that I use orbit fits, residuals, photometry checks, conflict resolution, partial refits, cutouts, and MPC/SkyBot checks to destroy weak hypotheses or promote stronger ones.

I have not fully moved this processing to the newer sparse-cadence regime yet, because I am still working through the earlier dense hypothesis space. The February data are very valuable, but also combinatorially difficult. Once the existing database of tracks and tracklets becomes more stable, the sparser cadence should become easier in one sense: stable tracks can immediately absorb new detections and reduce the search space.

Of course, the most interesting hypotheses still need strict manual review before any serious claim or follow-up/reporting decision: cutouts, astrometry, photometry, orbit stability, residuals, known-object checks, and MPC-style reporting standards.

So I think both approaches are valid, but they optimize for different things:

manual follow-up selector -> strong early filters, high purity
bulk discovery search     -> broad hypothesis generation, later verification

Your TOP-20 approach is probably much better for immediate telescope follow-up. My approach is more about trying not to miss weak or non-obvious linkages, even if that means dealing with a much larger false-positive surface later.

Zhuoxiao · June 30, 2026, 4:45pm

I ran 32k cataloged objects (orbit retrieved from space-track.org), filtering by PA, angular speed and fov. So far this one is the closest. Noting, the elongated trails in cutout , are parallel to the motion.

I think this kind of (relatively) high altitude rocket fragmentation debris, is always hidden in telescopes before Rubin, only poorly tracked by radar. Based on the 20-21 mag estimation at 9000km, we were looking at something centimeter size tumbling at a period of several seconds. This kind artificial object, small sized and further away, is a realm of unknown.

Astropaparazzo · June 30, 2026, 4:46pm

I was quoting LienaDreams,

Originally, my post was sequentially close to hers, which is where I got the inspiration for mine. Unfortunately, it was held in moderation until it got posted today. So it goes…

Well, I see that won’t be recurring. . Thanks, mods!

LienaDreams · June 30, 2026, 5:07pm

@Astropaparazzo

right, the magnitude comes from the Rubin data, f.e. you can see it here: https://lasair.lsst.ac.uk/objects/170591527057228257/
and you can also click there Antares broker button and it will show magnitude 21 as well.

nealmcb · June 30, 2026, 6:58pm

I’m no expert, but it seems like those alert pipeline magnitude estimates wouldn’t properly model individual image streaks coming from the fast motion of a tumbling irregular object.

The photons from each streak only accumulated over a fraction of the rotational period. If it is travelling 80 arcsec per second, and we’re seeing consecutive glints 235 arcsec apart (for the first two in the original table) then the rotation period is about 2.9 sec. If those are 6 arcsec cutouts, we’re just seeing a detection based on perhaps an 4 arcsec trail out of each 235 arcsec, so just 2% of the period, or perhaps 60 ms.

That implies a much brighter object at peak, which is not detected during the rest of the period.
Of course there may be other aspects of the pipeline, detection, deblending that would impact such estimates as well.

mrawls · June 30, 2026, 7:25pm

Great detective work folks. Here is my own SatChecker query result, which indeed shows a Starlink likely passing through the FOV within 30s of the exposure time, but not at the correct angle (the detections in question appeared in detectors 118, 119, and 126). Typically Starlinks manifest as brighter wide streaks, not trailed glints like this. I strongly suspect this is a piece of small (~10 cm) debris that is tumbling, glinting reflected sunlight, and not in the public catalog (due to being small/faint). We aim to flag detections like this as trailed glints and not alert on them, but clearly we can’t catch everything. As others have said, Starlink trains (multiple recently launched satellites clumped together) are significantly brighter than these diaObjects.

LienaDreams · June 30, 2026, 7:37pm

@mrawls
Amazing work, thank you, Meredith! I was looking for Rubin detectors schema, and here it is. Very helpful!