Search NASA⌕ Search

SEARCH · Search NASA

Results for “Starlink”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS1992

Multifrequency data analysis software on STARLINK

Although the STARLINK project was set up to provide image processing facilities to UK astronomers, it has grown over the last 12 years to the extent that it now provides most of the data analysis facilities for UK astronomers. One aspect of the growth of the STARLINK network is that it now has to cater for astronomers working in a diverse range of wavelengths. Since a given individual may be working with data obtained in a variety of wavelengths, it is most convenient if the data can be stored in a common format and the programs that analyze the data have a similar 'look and feel'. What is known as 'STARLINK software' is obtained from many sources: STARLINK funded programmers; astronomers; foreign projects such as AIPS; generally available shareware; and commercial sources when this proves cost effective. This means that the ideal situation of a completely integrated system cannot be realized in practice. Nevertheless, many of the major packages written by STARLINK application programmers and by astronomers do use a common data format, based on the Hierarchical Data System, so that interchange of data between packages designed separately from each other is simply a matter of using the same file names. For example, as astronomer might use KAPPA to read some optical spectra off a FITS tape, then use CCDPACK to debias and flat field the data (it is easy to set up an overnight batch job to do this if there is a lot of data), then use KAPPA to have a quick look at the data and then use Figaro to reduce the spectra. It is useful to divide data analysis packages into wavelength specific packages, or even instrument specific packages, and general purpose ones. Once the instrumental signature has been removed from some data, any appropriate general purpose package can be used to analyze te data. For example, the ASTERIX package deals with x-ray data reduction, but after dealing with all of the x-ray specific processing, an astronomer may well want to find the brightness of objects in a given frame. Since ASTERIX uses the standard STARLINK data format, the astronomer can use PHOTOM or DAOPHOT 2 to measure the brightness of the objects. Although DAOPHOT was written with optical astronomy in mind, it is useful for analyzing data from several wavelengths. The ability of DAOPHOT 2 to handle non-standard point spread functions can be especially useful in many areas of astronomy.

Allan, P. M.↗
NASA NTRS1995

Satellite Telemetry and Return Link (STARLink)

The High Altitude Missions Branch of NASA's Ames Research Center has been pursuing methods and communication architectures to decrease processing time and shorten the dissemination paths of the data from scientific experiments on board the high altitude ER-2 aircraft. The Satellite Telemetry and Return Link (STARLink) is an innovative approach for providing real-time data from existing experiments and allows for highly interactive future experiment systems on the ER-2. The concept involves placing an advanced wideband data link system on the ER-2 (and future NASA aircraft) for communicating to the NASA Tracking Data and Relay Satellite System (TDRSS) and its designated ground station. The emphasis is on providing full duplex real-time data between the ground station hub (and its remote nodes) and the on board experiments, allowing real-time processing and alteration to the experiments. This paper defines the concept, goals, multiplexing and data transmission system architecture, current capabilities, and future plans of the STARLink and its ability to provide a distributed interactive gateway node between the aircraft and various scientific centers worldwide.

Andrew Roberts↗
NASA NTRS1992

The STARLINK software collection

The UK's STARLINK project based at the Rutherford Appleton Laboratory develops and distributes software applicable to a wide range of problems in Astronomy; it covers most wavebands, caters for a variety of instrumentation, and ranges from programming tools and libraries through to large package of applications. The facilities available and gives details of how they may be obtained are summarized. Recent developments and other features of particular interest are highlighted.

Warren-Smith, R. F.↗
NASA NTRS1992

Evaluation of RDBMS packages for use in astronomy

Tabular data sets arise in many areas of astronomical data analysis, from raw data (such as photon event lists) to final results (such as source catalogs). The Starlink catalog access and reporting package, SCAR, was originally developed to handle IRAS data and it has been the principal relational DBMS in the Starlink software collection for several years. But SCAR has many limitations and is VMS-specific, while Starlink is in transition from VMS to Unix. Rather than attempt a major re-write of SCAR for Unix, it seemed more sensible to see whether any existing database packages are suitable for general astronomical use. The authors first drew up a list of desirable properties for such a system and then used these criteria to evaluate a number of packages, both free ones and those commercially available. It is already clear that most commercial DBMS packages are not very well suited to the requirements; for example, most cannot carry out efficiently even fairly basic operations such as joining two catalogs on an approximate match of celestial positions. This paper reports the results of the evaluation exercise and notes the problems in using a standard DBMS package to process scientific data. In parallel with this the authors have started to develop a simple database engine that can handle tabular data in a range of common formats including simple direct-access files (such as SCAR and Exosat DBMS tables) and FITS tables (both ASCII and binary).

Page, C. G.↗
NASA NTRS1992

The evolution of the FIGARO data reduction system

The Figaro data reduction system originated at Caltech around 1983. It was based on concepts being developed in the U.K. by the Starlink organization, particularly the use of hierarchical self-defining data structures and the abstraction of most user-interaction into a set of 'parameter system' routines. Since 1984 it has continued to be developed at AAO, in collaboration with Starlink and Caltech. It was adopted as Starlink's main spectroscopic data reduction package, although it is by no means limited to spectra; it has operations for images and data cubes and even a few (very specialized) for four-dimensional data hypercubes. It continued to be used at Caltech and will be used at the Keck. It is also in use at a variety of other organizations around the world. Figaro was originally a system for VMS Vaxes. Recently it was ported (at Caltech) to run on SUN's, and work is underway at the University of New South Wales on a DecStation version. It is hoped to coordinate all this work into a unified release, but coordination of the development of a system by organizations covering three continents poses a number of interesting administrative problems. The hierarchical data structures used by Figaro allow it to handle a variety of types of data, and to add new items to data structures. Error and data quality information was added to the basic file format used, error information being particularly useful for infrared data. Cooperating sets of programs can add specific sub-structures to data files to carry information that they understand (polarimetry data containing multiple data arrays, for example), without this affecting the way other programs handle the files. Complex instrument-specific ancillary information can be added to data files written at a telescope and can be used by programs that understand the instrumental details in order to produce properly calibrated data files. Once this preliminary data processing was done the resulting files contain 'ordinary' spectra or images that can be processed by programs that are not instrument-specific. The structures holding the instrumental information can then be discarded from the files. Much effort has gone into trying to make it easy to write Figaro programs; data access subroutines are now available to handle access to all the conventional items found in Figaro files (main data arrays, error information, quality information etc), and programs that only need to access such items can be very simple indeed. A large number of Figaro users do indeed write their own Figaro applications using these routines. The fact that Figaro programs are written as callable subroutines getting information from the user through a small set of parameter routines means that they can be invoked in numerous ways; they are normally linked and run as individual programs (called by a small main routine that is generated automatically), but are also available linked to run under the ADAM data acquisition system and there is an interface that lets them be called as part of a user-written Fortran program. The long-term future of Figaro probably depends to a large extent on how successfully it manages the transition from being a VMS-only system to being a multi-platform system.

Shortridge, K.↗
NASA NTRS2022

Thermospheric Neutral Density Variation During the “SpaceX” Storm: Implications From Physics-Based Whole Geospace Modeling

The Starlink satellites launched on 3 February 2022 were lost before they fully arrived in their designated orbits. The loss was attributed to two moderate geomagnetic storms that occurred consecutively on February 3-4. We investigate the thermospheric neutral mass density variation during these storms with the Multiscale Atmosphere-Geospace Environment (MAGE) model, a first-principles, fully coupled geospace model. Simulated neutral density enhancements are validated by Swarm satellite measurements at the altitude of 400-500 km. Comparison with standalone TIEGCM and empirical NRLMSIS 2.0 and DTM-2012 models suggests better performance by MAGE in predicting the maximum density enhancement and resolving the gradual recovery process. Along the Starlink satellite orbit in the middle thermosphere (∼ 200 km altitude), MAGE predicts up to 150% density enhancement near the second storm peak while standalone TIEGCM, NRLMSIS 2.0 and DTM-2012 suggest only ∼ 50% increase. MAGE also suggests altitudinal, longitudinal, and latitudinal variability of storm-time percentage density enhancement due to height dependent Joule heating deposition per unit mass, thermospheric circulation changes, and travelling atmospheric disturbances. This study demonstrates that a moderate storm can cause substantial density enhancement in the middle thermosphere. Thermospheric mass density strongly depends on the strength, timing, and location of high-latitude energy input, which cannot be fully reproduced with empirical models. A physics-based, fully coupled geospace model that can accurately resolve the high-latitude energy input and its variability is critical to modeling the dynamic response of thermospheric neutral density during storm time.

Starlink↗
NASA NTRS1990

Review of Canadian mobile satellite systems institutional arrangements policy

Development of institutional arrangements policy for maritime, land, and aeronautical mobile satellite systems (MSS) is an integral part of the Canadian telecommunications policy process. An ongoing activity in that process is fitting of MSS institutional arrangements policy within the confines of the 1987 Canadian Telecom Policy Framework. Making sure the fit is correct is a major task at present because technology seems to be driving service demand at rapid growth rates, particularly in the case of land MSS. This growth is stimulating policy and regulatory development efforts to keep pace. In Canada, this is happening in four planned MSS applications areas: Canada-US transborder (immediate), aeronautical MSS (1990/94), Telesat Mobile Inc. EMDS via INMARSAT (1990), and MSAT (1993/94). The need for an up-to-date MSS policy in these areas is emphasized by related developments in the US and elsewhere. It arises because of the growing number of market initiatives proposing North American rather than Canada-only or US-only coverage, such as INMARSAT, Geostar, OmniTRACS, and Starlink.

Gilvary, David↗
NASA NTRS1992

An object-oriented data reduction system in Fortran

A data reduction system for the AAO two-degree field project is being developed using an object-oriented approach. Rather than use an object-oriented language (such as C++) the system is written in Fortran and makes extensive use of existing subroutine libraries provided by the UK Starlink project. Objects are created using the extensible N-dimensional Data Format (NDF) which itself is based on the Hierarchical Data System (HDS). The software consists of a class library, with each class corresponding to a Fortran subroutine with a standard calling sequence. The methods of the classes provide operations on NDF objects at a similar level of functionality to the applications of conventional data reduction systems. However, because they are provided as callable subroutines, they can be used as building blocks for more specialist applications. The class library is not dependent on a particular software environment thought it can be used effectively in ADAM applications. It can also be used from standalone Fortran programs. It is intended to develop a graphical user interface for use with the class library to form the 2dF data reduction system.

Bailey, J.↗
NASA NTRS1992

A self-defining hierarchical data system

The Self-Defining Data System (SDS) is a system which allows the creation of self-defining hierarchical data structures in a form which allows the data to be moved between different machine architectures. Because the structures are self-defining they can be used for communication between independent modules in a distributed system. Unlike disk-based hierarchical data systems such as Starlink's HDS, SDS works entirely in memory and is very fast. Data structures are created and manipulated as internal dynamic structures in memory managed by SDS itself. A structure may then be exported into a caller supplied memory buffer in a defined external format. This structure can be written as a file or sent as a message to another machine. It remains static in structure until it is reimported into SDS. SDS is written in portable C and has been run on a number of different machine architectures. Structures are portable between machines with SDS looking after conversion of byte order, floating point format, and alignment. A Fortran callable version is also available for some machines.

Bailey, J.↗
NASA NTRS1992

The ADAM environment and transputers

The ADAM environment is both used for data analysis by Starlink and for data acquisition by the UK-involved observatories in Australia, Hawaii, and the Canary Islands. ADAM was originally hosted under VAX/VMS but is now at an advanced stage of a Unix port. ADAM comprises a parameter system, hierarchical data system, noticeboard system, error handling system, and other components. Originally a multi-tasking single processor environment, it has been enhanced to a multiprocessor environment using local or wide area networking. The Royal Observatory Edinburgh is producing a transputer version of the ADAM kernel to allow instruments which make use of transputers for data acquisition/control to integrate more closely with the ADAM software running at the telescopes. Communication into the transputer system is based on Ethernet carrying TCP/IP, which eases development toward a network of mixed VMS/Unix/transputer Telescope systems. The transputer system is being applied to instruments under development for the UKIRT and JCMT telescopes.

Kelly, B. D.↗
NASA NTRS1995

Satellite communications provisions on NASA Ames instrumented aircraft platforms for Earth science research/applications

Earth science activities at NASA Ames are research in atmospheric and ecosystem science, development of remote sensing and in situ sampling instruments, and their integration into scientific research platform aircraft. The use of satellite communications can greatly extend the capability of these agency research platform aircraft. Current projects and plans involve satellite links on the Perseus UAV and the ER-2 via TDRSS and a proposed experiment on the NASA Advanced Communications Technology Satellite. Provisions for data links on the Perseus research platform, via TDRSS S-band multiple access service, have been developed and are being tested. Test flights at Dryden are planned to demonstrate successful end-to-end data transfer. A Unisys Corp. airborne satcom STARLink system is being integrated into an Ames ER-2 aircraft. This equipment will support multiple data rates up to 43 Mb/s each via the TDRS S Ku-band single access service. The first flight mission for this high-rate link is planned for August 1995. Ames and JPL have proposed an ACTS experiment to use real-time satellite communications to improve wildfire research campaigns. Researchers and fire management teams making use of instrumented aircraft platforms at a prescribed burn site will be able to communicate with experts at Ames, the U.S. Forest Service, and emergency response agencies.

Shameson, L.↗
NASA NTRSDate not supplied

Conjunction Assessment and Deconfliction Paradigm for Co-Located Satellite Constellations With on-Spacecraft “Autonomous” Flight Dynamics Control

Satellite constellations that employ on-spacecraft flight dynamics and conjunction assessment (CA) approaches face particular challenges. First, they must arrange to obtain and upload to the constellation satellite close approach information, such as Conjunction Data Messages, so that their on-board systems will have the data they need to make informed CA decisions. Second, given current latencies in obtaining CA screening information, such systems often cannot obtain dedicated screenings of their proposed maneuvers before they are executed. Third, they usually cannot engage in real time with owner/operators (O/Os) with whom they may come into conjunction, relying instead on pre-arranged courses of action that may or may not fit a given situation well. Despite these difficulties, it is nonetheless possible, as operators such as SpaceX have demonstrated, to operate safely using on-board CA calculations, in the presence of a largely collaborative operating environment. The situation breaks down, however, when two constellations that operate with such a paradigm are placed in the same orbital region and will experience conjunctions with each other. Each may have a vague idea of where the other’s satellites are, or perhaps even a somewhat precise idea if they exchange O/O ephemerides, but neither will know the other’s more immediate maneuver intentions, especially for situations in which they are in a high-risk conjunction with each other and a mitigation maneuver is required. As there is no formalized way for these automated systems to ascertain each other’s intentions for this type of conjunction, it is quite possible that each spacecraft may choose a maneuver that results in the two objects’ colliding. An opportunity to develop a solution to this problem was presented by the NASA “Starling” project, a small experimental constellation developed to demonstrate autonomous satellite control and constellation reconfiguration and for which a launch was obtained that, serendipitously, will place this constellation close to the SpaceX Starlink constellation. Because the NASA constellation is experimental, an extended mission part of the mission has been negotiated to implement and test mechanisms for resolving the problem of co-located constellations with on-board flight dynamics control. For the last eighteen months, a consortium among NASA Ames (the Starling satellite providers), NASA CARA (the Agency organization responsible for conjunction assessment), Space X, and the Department of Commerce (in observer status) has met regularly to assemble a concept of operations for a robust solution to this problem and has developed a prototype ground node that will serve as a needed CA screening and information dispensary. The approach and methods, as well as the active employment of the developed ground node, will be tested both in simulation before actual use and then in actual spacecraft operations, which are anticipated to begin in January 2024. This paper will describe the co-located autonomously-controlled constellation problem and the developed solution in detail, outlining what ground node (i.e., government) infrastructure and features are required, what particular capabilities are needed by the constellations themselves in order to make use of this deconfliction paradigm, and the migration path forward to allow such a capability set to be incorporated by the Department of Commerce’s space traffic coordination system.

Conjunction Assessment↗
NASA NTRSDate not supplied

Conjunction Assessment and Deconfliction Paradigm for Co-located Satellite Constellations with On-Spacecraft “Autonomous” Flight Dynamics Control

Constellations that employ highly-automated satellite flight dynamics can operate safely from a collision avoidance (CA) perspective using current CA screening technology and communication paradigms—except when in proximity to other highly-automated constellations: there is no existing arrangement and concept of operations to allow the low-latency CA screenings, exchange of information, and assignment/acceptance of mitigation responsibility that co-location of highly-automated constellations requires. However, the serendipitous co-location of the NASA Starling mission—an autonomously-controlled technology demonstration constellation—and the SpaceX Starlink constellation has presented an opportunity (indeed, a requirement) to develop and build out a solution for safe operations of two (or more) co-located, highly-automated satellite constellations. Such a solution has been designed and constructed, including the required ground node; and it will be exercised as a dedicated, in-flight safety experiment between the two constellations from January to September 2024. Lessons learned from this experiment are expected to feed the design of the US Department of Commerce’s Tracking Control System for Space (TraCSS) space traffic coordination solution.

conjunction assessment↗
NASA NTRSDate not supplied

Automating Maneuvers: Considerations for Collision Avoidance

As more space operators implement large constellations of spacecraft, automating orbit maintenance maneuvers becomes a key feature of their operations concept to ensure that the workload is manageable. However the practice of performing a maneuver without sharing the plan with other nearby spacecraft causes a risk that two spacecraft will collide, not only destroying the spacecraft involved, but creating debris that will affect all other spacecraft using that orbit regime. In order to share the maneuver plan, a predicted ephemeris file containing the maneuver must be sent to a central authority to screen against predicted trajectories of all other on-orbit objects to determine where and when close approaches may occur that need to be mitigated. Currently the screening authority used by US operators is the 19th Space Defense Squadron. However the conjunction screening process in use by the 19th was developed over 30 years ago and was not designed with automation in mind, so screenings are performed once every 8 hours, meaning that spacecraft using automated maneuvering need to allow 16 hours to share their maneuver plan via the screening process. Many operators assume that automated maneuver planning must be real-time; however this time between planning and execution to allow for screening is possible if planned for during system design. In an effort to speed up the screening process, NASA has developed a prototype system for performing near-real-time screenings. This prototype system was necessitated to support the NASA Starling mission, a constellation of 4 cubesats that planned to fly at the same altitude as the SpaceX Starlink constellation, both performing automated maneuvering. Without screening of the planned maneuvers, the two constellations risked a collision. Once converted from a prototype to an operational system, this capability will greatly help smallsats, for example those that are planning to test propulsive capabilities, by allowing fast turnaround feedback to ensure safety form collision with other objects. This paper describes the existing CA process, the prototype real-time capability, and results from the experiment that tested the prototype.

Matthew Hejduk↗
NASA NTRSDate not supplied

Lunar Optical Communications

Numerous studies have shown that NASA’s Deep Space Network (DSN) is woefully inadequate to support the current pace of space exploration. Proposals are on the table for extensive infrastructure build-out using RF communications, which is ultimately bandwidth constrained. Optical communication offers unregulated, near-infinite bandwidth that can easily support the needs of humans at the Moon and beyond. Although not part of the proposed lunar network architecture, optical communication systems should be considered; these systems are operational now, quickly proliferating near Earth space (e.g. StarLink), and offer very high bandwidths.

lunar↗
NASA NTRSDate not supplied

Automating Maneuvers: Considerations for Collision Avoidance

As more space operators implement large constellations of spacecraft, automating orbit maintenance maneuvers becomes a key feature of their operations concept to ensure that the workload is manageable. However, the practice of performing a maneuver without sharing the plan with other nearby spacecraft causes a risk that two spacecraft will collide, not only destroying the spacecraft involved, but creating debris that will affect all other spacecraft using that orbit regime. In order to share the maneuver plan, a predicted ephemeris file containing the maneuver must be sent to a central authority to screen against predicted trajectories of all other on-orbit objects to determine where and when close approaches will occur that may need to be mitigated. Currently the screening authority used by US operators is the 19th Space Defense Squadron; screenings are performed once every 8 hours, meaning that spacecraft using automated maneuvering need to allow 16 hours to share their maneuver plan via the screening process in advance of maneuver execution in case one screening is missed and the next needs to be used. In an effort to speed up the screening process to benefit spacecraft using automated maneuvering, a prototype system for performing near-real-time screenings has been developed in support of the NASA Starling mission, a constellation of four cubesats that fly at the same altitude as the SpaceX Starlink constellation. Both of these constellations perform automated maneuvering, so without screening the planned maneuvers before execution, the two constellations would risk a collision. This paper describes the traditional conjunction assessment (CA) process, the prototype real-time CA screening capability, plans for the experiment to test the prototype, and next steps.

conjunction assessment↗
NASA NTRSDate not supplied

Automating Maneuvers: Considerations for Collision Avoidance

As more space operators implement large constellations of spacecraft, automating orbit maintenance maneuvers becomes a key feature of their operations concept to ensure that the workload is manageable. However, the practice of performing a maneuver without sharing the plan with other nearby spacecraft causes a risk that two spacecraft will collide, not only destroying the spacecraft involved, but creating debris that will affect all other spacecraft using that orbit regime. In order to share the maneuver plan, a predicted ephemeris file containing the maneuver must be sent to a central authority to screen against predicted trajectories of all other on-orbit objects to determine where and when close approaches will occur that may need to be mitigated. Currently the screening authority used by US operators is the 19th Space Defense Squadron; screenings are performed once every 8 hours, meaning that spacecraft using automated maneuvering need to allow 16 hours to share their maneuver plan via the screening process in advance of maneuver execution in case one screening is missed and the next needs to be used. In an effort to speed up the screening process to benefit spacecraft using automated maneuvering, a prototype system for performing near-real-time screenings has been developed in support of the NASA Starling mission, a constellation of four cubesats that fly at the same altitude as the SpaceX Starlink constellation. Both of these constellations perform automated maneuvering, so without screening the planned maneuvers before execution, the two constellations would risk a collision. This paper describes the traditional conjunction assessment (CA) process, the prototype real-time CA screening capability, plans for the experiment to test the prototype, and next steps.

conjunction assessment↗