Bernd Klemt Sep 10
> On 09/09/2019 01.06, Sam Deen planetaryscience@... [find_orb] wrote:info@...
> > ...the main source of uncertainty is the start/end point of the satellite'sClear skies
> > 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-do
> d-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
> >
> >
> >
> >
>
>
> ------------------------------------
> Posted by: Bill Gray <pluto@...>
> ------------------------------------