On 09/09/2019 01.06, Sam Deen planetaryscience@... [find_orb] wrote:

> ...the main source of uncertainty is the start/end point of the satellite's streak. It appears to be chaotically tumbling, so measuring exactly where its streak starts & ends introduces a gigantic amount of uncertainty. Fortunately, it's mostly constrained to the direction of motion anyway because i can tell the path it's traveling along quite well.

A very common situation. Much of what I've been calling
"timing uncertainty" really isn't uncertainty in how well the
clock is set; it's uncertainty caused by not being able to
measure the endpoints well, especially for objects that are
changing a lot in brightness.

> With the new orbital solution, the object is still somehow completely unidentified. I wasn't really expecting that to be honest...

I'm not all that surprised. It's true that Space-Track TLEs
tend to be reasonably good for low objects like this. (For very
high objects, as you probably know, Space-Track is nearly useless,
and I have to compute my own orbits and TLEs from observations.)
Space-Track mostly relies on radar, which is great for tracking
closer objects and quickly becomes useless with increasing distance.
It really ought to have gotten something this low, but it may not
be very bright and/or radar-reflective.

Also, they are a US Government agency. If your object is a
"classified" object, you won't see TLEs. There are efforts to
change that situation, and they've started (within the last few
months) posting TLEs for a lot of previously unlisted objects.
The hope is that the probability of collisions can be decreased.
Apparently, this is encountering some resistance within some
elements of the US military/intelligence community :

https://breakingdefense.com/2019/08/intel-communitys-secrecy-culture-frustrates-dod-sat-safety-effort/

So your object might not be listed, even if you, China, Russia,
and East Absurdistan are all perfectly capable of tracking it.

> What do you do if you have an unidentified satellite? Is there some place to report that to?

I'm not really an artsat guy. I mostly got involved with them
because they've been a nuisance for asteroid observers. If there's
somebody on this list with better knowledge, I hope they'll jump
in here. You might get a more informed opinion on the SeeSat-L list :

http://www.satobs.org/seesat/seesatindex.html

But... as far as I know, there isn't anything resembling an "MPC
for artsats". I collect data on the high-fliers, but there are only
about 30 of those at any given time. I'm not really set up to handle
the quantities of objects I'd be getting if I extended my efforts to
include lower objects.

-- Bill

> ~Sam
>
> On Sunday, September 8, 2019, 7:12:54 PM PDT, Bill Gray pluto@... [neo_followup] <neo_followup@yahoogroups.com> wrote:
>
>
> Hi Sam,
>
> An interesting problem...
>
> I was able to get the observations to load, after making two
> corrections. The second lines have to show the designation 2019-01
> as well, and the first lines should show a 'V' for the observation
> type instead of 'C'. See the observations (and orbit and resids) at
>
> https://projectpluto.com/temp/sdeen.htm
>
> Mis-formatted roving observer data seems to happen a _lot_,
> judging from the error logs for on-line Find_Orb. I should have
> the program warn you about 'C' lines from (247) and 'v' lines that
> didn't match to a corresponding 'V' line. (In fact, I thought
> it _would_ object to that. It does a good job of warning you about
> problems with satellite and radar observations, where you can get
> the same sort of issues.)
>
> Roving observations tend to be a pain to work with. MPC (and
> Find_Orb) allow one to specify an (XXX) temporary observatory code :
>
> https://projectpluto.com/xxx.htm
>
> which you may find less irritating : just use code (XXX), add
> a comment line giving its lat/lon/alt, and you're good to go. As
> an example, your observations for this object transformed to use
> MPC code (XXX) are shown below.
>
> In addition to reformatting designations and changing 'C'
> to 'V', I added the line
>
> COM Posn sigma 50
>
> at the top of the file containing the astrometry. (Large
> sigmas are fine, but you essentially have to tell it, "these
> are uncertain observations, not bad ones.") I left the timing
> uncertainty at one second. Both of those were essentially wild
> guesses. However, if you look at the second set of residuals
> at the above pseudo-MPEC (the "cross-track and along-track" ones),
> you'll see that it appears to be about right. The residuals are
> terrible in the traditional position-only sense, but once you
> take into account the fact that much of the error lies in the
> direction of apparent motion, you get much more information from
> them, and the orbit converges on the sort of low-earth one shown
> on the pseudo-MPEC.
>
> The times were given to 0.00001 day precision. During that time
> (slightly under a second), the object could move about 800 arcseconds,
> and that truncation causes much of the error in the results. If you
> can get the time to an extra decimal place, the truncation error
> would drop to 80 arcseconds. You probably don't actually know
> the absolute times to the "microday" (86.4 millisecond) level, but
> if the times of the observations relative to one another are
> reasonably consistent, you'd still see some improvement in the orbit.
> A good thing to keep in mind for any fast-moving object... of
> course, getting the absolute timing right also matters, and I'll
> put in my standard plug for calibrating timing of astronomical images
> "the easy way" :
>
> https://projectpluto.com/gps_expl.htm
>
> -- Bill
>
> (Observations transformed to use code (XXX))
>
> COD XXX
> COM Long. 263 29 48.1 E, Lat. 41 26 08.5 N, Alt. 366m, Google Earth
> OBS S. Deen et. al.
> COM Posn sigma 50
> COM Unknown artsat
> 2019-01 *C2019 09 05.06986 00 20 57.7 +54 54 52 XXX
> 2019-01 C2019 09 05.07021 23 56 11.8 +49 07 31 XXX
> 2019-01 C2019 09 05.07031 23 45 38.5 +46 04 31 XXX
> 2019-01 C2019 09 05.07066 23 27 01.6 +39 03 18 XXX
> 2019-01 C2019 09 05.07074 23 22 35.9 +37 01 21 XXX
> 2019-01 C2019 09 05.07109 23 08 36.3 +29 36 27 XXX
> 2019-01 C2019 09 05.07118 23 04 40.8 +27 14 42 XXX
> 2019-01 C2019 09 05.07153 22 54 06.4 +19 42 41 XXX
> 2019-01 C2019 09 05.07162 22 51 34.5 +17 46 03 XXX
>
> On 06/09/2019 03.05, Sam Deen planetaryscience@... [find_orb] wrote:
> >
> >
> > Hi Bill, all,
> >
> > A friend of mine detected an object in some wide-angle images that he had been taking of the sky. The object was moving ridiculously fast, about ~15 arcminutes per second, and he decided we should investigate further when it didn't show up as any identified object among any of the ~16000 known artsats with TLEs. Unfortunately, due to the huge movement speed (and the huge aperture that he was using to even detect it for so long) the resolution of the images we have is exceptionally terrible for astrometric purposes, on the order of about 10-15 arcminutes (600-900 arcseconds) for each observation. It seems find_orb really doesn't like sigmas this high, but I think if it properly processed these the observations would be very good for calculating the orbit of the object and determining whether or not it's even a satellite (considering that this range is over 45 degrees across
> > the sky, I'd be surprised if something couldn't be gained from this.) So do you know any way to force it to process these observations and not throw a fit whenever I try to give it inaccurate observations like this?
> >
> >      2019-01 *C2019 09 05.06986 00 20 57.7  +54 54 52                        247
> >               v2019 09 05.06986 1 263.4967   +41.4357     366                247
> >      2019-01  C2019 09 05.07021 23 56 11.8  +49 07 31                        247
> >               v2019 09 05.07021 1 263.4967   +41.4357     366                247
> >      2019-01  C2019 09 05.07031 23 45 38.5  +46 04 31                        247
> >               v2019 09 05.07031 1 263.4967   +41.4357     366                247
> >      2019-01  C2019 09 05.07066 23 27 01.6  +39 03 18                        247
> >               v2019 09 05.07066 1 263.4967   +41.4357     366                247
> >      2019-01  C2019 09 05.07074 23 22 35.9  +37 01 21                        247
> >               v2019 09 05.07074 1 263.4967   +41.4357     366                247
> >      2019-01  C2019 09 05.07109 23 08 36.3  +29 36 27                        247
> >               v2019 09 05.07109 1 263.4967   +41.4357     366                247
> >      2019-01  C2019 09 05.07118 23 04 40.8  +27 14 42                        247
> >               v2019 09 05.07118 1 263.4967   +41.4357     366                247
> >      2019-01  C2019 09 05.07153 22 54 06.4  +19 42 41                        247
> >               v2019 09 05.07153 1 263.4967   +41.4357     366                247
> >      2019-01  C2019 09 05.07162 22 51 34.5  +17 46 03                        247
> >               v2019 09 05.07162 1 263.4967   +41.4357     366                247
> >
> > ~Sam
>
>
>
>