Author: dvida

SkyFit2 tutorial

SkyFit2 tutorial

We have a new version of our astrometry and photometry calibration software which is much faster and better than the old version! Here is a tutorial on how to use it:

The effects of Starlink satellites on meteor observations

The effects of Starlink satellites on meteor observations

Effects on different systems

The effect of Starlink will vary depending on the observation method. For example, back scatter meteor radars such as CMOR will not be affected at all. All-sky fireball cameras which aim to record meteorite falls (e.g. the NASA fireball network, the Desert Fireball Network, etc.) should also not be affected much because their limiting magnitudes are quite bright (they aim to record meteors brighter than magnitude -3).

A bright meteor recorded by the NASA fireball network camera in Huntsville

In contrast, meteor orbit and flux cameras have much fainter limiting magnitudes. State of the art Global Meteor Network cameras have limiting magnitudes of about +7 at 25 frames per second, and they might record many more Starlink satellites.

Co-added image of all meteor detections from the night of Dec 30-31, 2019. BE0001 camera in Grapfontaine, Belgium.

How bright will they really be?

In this section a way to simulate the Starlink constellation in Stellarium is given. This website provides a way to generate a satellite orbit TLE file which can be loaded into Stellarium: http://howmanystarlinkswillfillyoursky.com/

I generated the TLE file with about 12,000 satellites (initially proposed configuration which has now been increased about 4 fold) and uploaded it to the GMN site: https://globalmeteornetwork.org/public/starlink_tle.txt

You can load it into Stellarium by following these steps:




Here is how the simulation looks like:

All in all, the situation doesn’t look too bad. The satellites are few and not entirely bright, but some might interfere with meteor observations. Note that the satellites may be 4 times as numerous in the final configuration.

Meteor detection algorithms

Meteor detection algorithms work by keeping a running mean image (usually an average of the last e.g. 256 video frames) which is subtracted from every video frame. The algorithm then detects straight lines propagating in time that are above some standard deviation above that mean (usually about 2.5). These algorithms do detect satellites even now, but they can be easily filtered out by using an angular velocity threshold (meteors have geocentric velocities between 11 and 71 km/s, which translates to an angular velocity range of about 2 – 52 deg/s). Issues might arise with processing times, as the streak will have to be detected and then rejected based on the angular velocity.

The impact is not entirely clear at this point, but if the satellite streaks intersect with meteors, there just isn’t a good way to do good astrometry and photometry measurements, which may force us to reject those observations.

Science loss

In an extremely conservative scenario assuming that there’s a 25% reduction in observation time (I’m assuming that 2 hours out of an average 8 hour night will be unusable) – how will that influence observations of meteor showers and the sporadic background?

Firstly, all optical observations won’t be able to measure meteor showers from the helion source anymore (such as the Daytime Arietids), which are exclusively seen just after sunset and are large contributors to the total yearly shower flux.

Next, we won’t be able to observe small meteoroids on low-eccentricity orbits, as their geocentric velocities are the highest in the morning (more kinetic energy equals more light production, which means a higher detection efficiency). In the last few years we’re just beginning to understand that these meteors seem to be larger, more numerous, and of entirely iron composition, which we still cannot explain. We need more data.

The good news is that observations of well-known annual meteor showers will not be affected much, as long as there’s a large longitudinal coverage, which the Global Meteor Network aims to achieve. But these showers are not very interesting as they are well observed. On the other hand, rare meteor shower outbursts which may last only for hours (or less) and may have a large activity might not be observed if they fall into a “Starlink gap”. These outbursts are the main source of uncertainty in spacecraft meteoroid hazard models, thus their observation is critical. I find it ironic that spacecraft meteoroid hazard models might be hindered by spacecraft.

In reality, the impact will probably be negligible, especially if SpaceX reduces the brightness 25 times. This translates to a ~3.5 magnitude decrease in brightness, which would bring these satellites below the sensitivity threshold of our cameras.

Orbital debris environment concerns

My concerns are mostly about the orbital debris environment. My single grave concern is that if one Starlink satellite is pulverized in a collision with another satellite, this might shred the whole constellation within hours (read more about the Kessler Syndrome), faster than anyone can react to bring them down. I might be wrong, but I still haven’t seen an analysis of what would happen to satellites that are packed so densely in one part of the LEO.

I’m going to finish this post with a quote from Don Kessler’s 2009 overview which was written before Starlink was proposed:
Aggressive space activities without adequate safeguards could significantly shorten the time between collisions and produce an intolerable hazard to future spacecraft. Some of the most environmentally dangerous activities in space include large constellations such as those initially proposed by the Strategic Defense Initiative in the mid-1980s, large structures such as those considered in the late-1970s for building solar power stations in Earth orbit, and anti-satellite warfare using systems tested by the USSR, the U.S., and China over the past 30 years. Such aggressive activities could set up a situation where a single satellite failure could lead to cascading failures of many satellites in a period much shorter than years.
Starlink satellite constellation – possible interference with meteor observations?

Starlink satellite constellation – possible interference with meteor observations?

Since the recent launches of Starlink satellites, Global Meteor Network cameras have recorded a significant uptick in the number of false meteor detections on satellites.

At the end of every night, just before dawn, about half of all 150+ GMN meteor cameras observe a train of parallel satellites. This is how they look like on GMN co-added images:

In this particular case, the camera on the La Palma island, next to the MAGIC telescope at the Roque de los Muchachos Observatory, was recording the outburst of the Alpha Monocerotid meteor shower which can be seen in the background. Here is the video of the outburst (starts at around 2:00) and the satellite passage (around 2:13 in the video):

Fortunately in this case these 60 satellites did not interfere with meteor observations, but one has to be concerned how will our skies look like when hearing that there are plans to launch a total of 42,000 satellites! This might completely deny us to do any optical meteor observations as soon as 2024.

Here is a video that shows several observations of the Starlink constellation with GMN cameras:

And here is how the Starlink constellation looks like from other GMN meteor cameras (click on image for video):

IT0001, Farra Observatory, Italy

HR000D, Ciovo, Croatia

HR0007, Buzet, Croatia

RU000C, Cherkessk, Russia

RU000F, Ka-Dar observatory, N. Arkhyz, Russia

First automated GMN trajectories

First automated GMN trajectories

More than 100 meteor stations all over the world send their data to our GMN server every day. Until now, this data was sitting idle on the server disk drives. The last couple of months I focused on writing code for automated multi-station meteor trajectory estimation, and now I’m happy to report the first results!

The GMN serverside scripts are using the open-source meteor trajectory code from the Western Meteor Python Library, an implementation of the novel Monte Carlo trajectory solver which produces trajectories of superior accuracy when compared to older methods of trajectory estimation. The paper about it has been submitted to MNRAS and will be published soon.

In this first preliminary data release, we show high quality meteor orbits recorded with GMN cameras from December 2018 up until now (late August 2019). We only select meteor trajectories with the minimum of 6 astrometry measurements per station, minimum convergence angle of 5 degrees, maximum eccentricity of 1.5, maximum radiant error of 2 degrees, and the maximum velocity error of 10%. Low quality trajectories usually have a low number of data point or unfavourable observation geometry, even though the astrometry calibration is good. RMS, the software that GMN stations run, recalibrates the astrometric plate on every image that has a meteor detection, ensuring the high quality of solutions.

Figure 1 shows a Sun-centered ecliptic plot of 14 006 orbits in this first data release. The meteor orbit density is colour coded and several major showers can be seen (Perseids, Southern Delta Aquarids, Geminids, Capricornids, etc.), as well as the sporadic sources. The dataset also contains trajectories of several minor showers, e.g. 3 Camelopardalid orbits. I still need to write a module for orbital shower association, until then the association needs to be done manually.

Figure 1. Density plot of the GMN orbits in this data release. The density scale is logarithmic.

 

Figure 2 shows a plot of individual orbits colour coded by the geocentric velocity in the same coordinate system. As expected, the velocities increase up to the maximum of ~71 km/s close to the Earth’s apex in the middle of the plot.

Figure 2. Sun-centered ecliptic plot of orbits, geocentric velocity is colour coded.

Figure 3 shows a map of 45 stations which were used for trajectory estimation. There are more stations that report meteor observations, but they are either single-station or their calibrations and geospatial coordinates need to be confirmed before they are used for trajectory estimation.

Figure 3. Global map of participating stations. Numbers next to country codes represent the number of stations in each country that were used for trajectory estimation.

 

Finally, we give a link to raw data so interested readers may take a look for themselves: trajectory_summary
This data set is preliminary, thus one should keep in mind that there might be erroneous entries in it. If the data is used, we ask that you reference GMN and this blog post.

 

Clear skies,
Denis Vida