Re: Neo Search and satellite imaging

From: Ian Roberts via Seesat-l <seesat-l_at_satobs.org>
Date: Tue, 04 Nov 2014 14:41:40 +0200
APEX can run two simultaneous processes using a standard FITs image:- 
APEX "sat" for sats and APEX "MPC" for asteroids.
When scanning for asteroids, every item on the plate has to be 
identified, including satellites which may show little or no movement 
against the star/asteroid background at times, where nearby asteroids 
show movement anyway.
APEX identifies every object on the plate using the provided star 
catalogues which will probably be UCAC3/4, Tycho 2, and USNO-A (to get 
to magnitude 19).
What it cannot ID, such as ex-catalogue items or noise spots, is 
presented as a list of unid items for the user to chase up manually. 
This is what the professional asteroid-seeking observatories do anyway.
Asteroid results are typically around 0.2 - 0.3 arcsec RMS 
astrometrically and about 0.5 magnitudes photometrically on objects 
imaged using a cheap az/el refractor with some blurring resulting and 
surplus DSLR camera.
The output is in standard MPC format for submission to the MPC.
In my case the MPC logged my observatory as L24 Gauteng.


On the same plate obtained where the scope is tracking at sidereal rate, 
satellites show up as streaks and the user is required to locate and 
mark the centre position of each streak. After reduction, APEX then uses 
a standard KEP elements file to ID the sat and drop the information into 
IOD format. What it cannot ID shows up in a unids file, also in IOD format.

Where APEX occasionally fails is labelling close satellites with the 
correct ID, especially where the DEC is similar, and the user is best 
served by checking these IDs in s/ware such as Heavensat.

For sats APEX has a recommended format, especially for extremely faint 
satellites, where the scope's motors are stopped at each location. Stars 
then streak, and APEX determines the position and ID of a sufficient 
number of stars on the plate for astrometric and photometric purposes, 
which are then used to convert plate X and Y into RA and DEC for sat ID 
purposes and where the user would normally mark the satellite, but there 
is also a 80% efficient mode where the user does not have to mark 
satellites, but where a half dozen images need to be taken at the 
location and presented to APEX for auto reduction.

rgrds,
Ian.


On 11/4/2014 12:13 PM, Greg Roberts via Seesat-l wrote:
> Actually Marco APEX is also used for minor planet processing - I think 
> Ian Roberts has done this
> It is one aspect of APEX that I have not investigated since I am not 
> particularly interested in
> asteroids etc.....
>
> Cheers
> Greg
>
> On 2014-11-04 11:54 AM, Marco Langbroek wrote:
>> Greg Roberts via Seesat-l schreef op 4-11-2014 8:18:
>>> Good morning - as Marco states there are so many images that it 
>>> presents a
>>> problem in processing them. Whilst there are no doubt many treasures 
>>> lurking
>>> there it will take a fair amount of work, and given that a large 
>>> number will NOT
>>> be of interest to us,   the return may be too small too justify the 
>>> time
>>> spent.
>>
>> The reason I do not measure satellites in our asteroid imagery, is 
>> that it would interfere with the speedy progress of the actual 
>> asteroid search. Measuring and ID-ing all the satellites as well 
>> would slow down the main objective (finding asteroids).
>>
>>
>>> Of course it also depends on where the images are taken as in some
>>> areas of the geo belt the amateur coverage is rather limited or even 
>>> non-existent
>>
>> Brad's is US imagery I think, mine is from Hungary.
>>
>>
>>
>>> As to using Astrometrica, Obsreduce  etc , if the images have the 
>>> standard FITS
>>> header, then the logical solution is to use APEX which was designed for
>>> processing  satellite trail images .
>>
>>
>> I was thinking along the line that you have the images loaded in 
>> Astrometrica (astrometric software for asteroids) any way to measure 
>> the asteroids. In principle, if you already loaded the image in 
>> Astrometrica measuring the trail then is a matter of clicking one 
>> end, clicking the other end, and you are done. I do have self-written 
>> software to convert measurements in MPC format to IOD format.
>>
>> The data I sometimes present on this list from the two 'remote' 
>> telescopes in the US I use (and the one in Australia I am currently 
>> testing out) are obtained this way.
>>
>>
>>> Time may be a problem though depending on how the time  given in the
>>> fits header was obtained.
>>
>> For NEA work the time needs to be accurate to subsecond level, so 
>> with images from a professional survey timing accuracy will be no 
>> issue. It is more a matter on whether including geosats would not 
>> interfere too much with the primary objective of timely hunting for 
>> asteroids.
>>
>> - Marco
>>
>>
>> -----
>> Dr Marco Langbroek  -  SatTrackCam Leiden, the Netherlands.
>> e-mail: sattrackcam_at_langbroek.org
>>
>> Cospar 4353 (Leiden):   52.15412 N, 4.49081 E (WGS84), +0 m ASL
>> Cospar 4354 (De Wilck): 52.11685 N, 4.56016 E (WGS84), -2 m ASL
>> Cospar 4355 (Cronesteyn): 52.13878 N, 4.49937 E (WGS84), -2 m ASL
>> Station (b)log: http://sattrackcam.blogspot.com
>> Twitter: _at_Marco_Langbroek
>> PGP key: http://tinyurl.com/kur7xm8
>> -----
>>
>>
>>
>
> _______________________________________________
> Seesat-l mailing list
> http://mailman.satobs.org/mailman/listinfo/seesat-l
>

_______________________________________________
Seesat-l mailing list
http://mailman.satobs.org/mailman/listinfo/seesat-l
Received on Tue Nov 04 2014 - 06:42:31 UTC

This archive was generated by hypermail 2.3.0 : Tue Nov 04 2014 - 12:42:31 UTC