Bernd Klemt Sep 10
> Hello Marco,Hi Bernd,
>
> 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"):
> -----------------------------------------across
>> 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
>> > 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
>
>