Bill Gray Sep 9
> ...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
> 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
> 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
> ~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
>
>
>
>