Sam Deen Sep 8
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