(Fwd) Re: (Fwd) Re: [find_orb] Trouble with calculating high-uncertainty orbits

Bernd Klemt Sep 10

Hello Bill, hello Sam,

here is Marcos answer.

------- Forwarded message follows -------

Op 10-9-2019 om 10:14 schreef Bernd Klemt:

> Hello Marco,
>
> perhaps you can help with the answer of this question which I repeat here (it
> occurs further down in this forwarded mail from Bill Gray, the author of the
> planetarium software "Guide" and orbit calculation software "FindOrb"):



Hi Bernd,

Hmmm, there is no real MPC-like central organization for these kind of objects.

The most logical place to report unknown satellites in low earth orbit is the
Seesat-L list:

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

Members of this list compile a catalogue of "classified" object orbits - objects
not in the public catalogue of CSpOC at www.space-track.org. This catalogue
currently contains some 200 objects. So in principle, anything not identifiable
from the CSpOC catalogue, has our interest on this list.

Members usually report their observations on the list (in IOD format, a format
used by satellite observers), and analysts (e.g. Mike McCants, who maintains our
catalogue) then scrape these from the list and calculate/udate orbits with them.
The current orbital catalogue of classified objects is at:
https://www.prismnet.com/~mmccants/tles/index.html

I have written some software (Windows) to ease reporting in IOD format:

https://drla.stackstorage.com/s/dAfPUpb5I2otnR5

I have not been able to find a match to Sam Deen's object.

- Marco



> -----------------------------------------
>> 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
> -----------------------------------------
>
> Thanks in advance. The email of Bill is: pluto@...
>
> ------- Forwarded message follows -------
>
> 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-
> 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@...>
> ------------------------------------
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
> ------- End of forwarded message -------
>
> Clear skies
> Bernd
>
> Bernd Klemt
>
> Sternwarte Herne, MPC code A18
> Herne, Germany
>
> e-mail: info@...
> http://www.sternwarte-herne.de
>
>


--
----
Dr Marco Langbroek

e-mail: marco@...
web: www.langbroek.org
Twitter: @Marco_Langbroek
----
------- End of forwarded message -------

Clear skies
Bernd
Bernd Klemt

Sternwarte Herne, MPC code A18
Herne, Germany

e-mail: info@...
http://www.sternwarte-herne.de