This disclosure relates generally to locating a satellite and, more particularly, to operating a feeder link terminal or Earth terminal to locate a satellite in low-Earth orbit.
According to one implementation of the disclosure, a computer-implemented method of operating a feeder link terminal to locate a satellite in low Earth orbit includes accessing predicted location information for a satellite in low-Earth orbit and determining an initial position at which to start a scan for the satellite. In addition, the method includes defining a substantially ellipsoidal region to scan for the satellite that includes the initial position, that has a long axis that corresponds to a predicted track of the satellite relative to the feeder link terminal, and that has a shorter axis that corresponds to potential cross-track error of the predicted track of the satellite. The method further includes causing the feeder link terminal to scan the ellipsoidal region for the satellite starting from the initial position.
Other features and advantages will be apparent to persons of ordinary skill in the art from the following detailed description and the accompanying drawings. Implementations described herein, including the above-described implementation, may include a method or process, a system, or computer-readable program code embodied on computer-readable media.
Shortly after new satellite vehicles (“satellites” or “SVs”) are deployed from a rocket, the locations of the freshly deployed satellites may not be known precisely, especially when the satellites are deployed into low-Earth orbit (“LEO”). For any of a number of different reasons (e.g., launch errors, missed burns, missed attitude recovery thrusting, etc.), there may be rather significant error between the expected position of a satellite and the actual position of the satellite. Feeder link terminals (“FLTs”) or other Earth terminals looking to synchronize with a satellite shortly after launch, therefore, need to be able to effectively and efficiently scan a region of the sky to locate and then synchronize with and track the satellite. FLTs commonly may use a so-called spiral scan function to attempt to locate and synchronize with a satellite. However, a spiral scan function may not be terribly effective for locating LEO satellites, particularly shortly after deployment, and/or compensating for potential errors associated with certain launch scenarios.
Accordingly, new scan techniques are disclosed herein that may be better suited for locating LEO satellites, particularly shortly after deployment, and/or compensating for potential errors associated with certain launch scenarios. Among other features, these scan techniques may employ an approach that recognizes that the unknown location of a LEO satellite shortly after deployment may be most likely to fall within a long ellipsoidal region. Consequently, the scan techniques disclosed herein may use timing, azimuth, and/or elevation offsets to scan for a satellite in a long ellipsoidal pattern. Additionally or alternatively, the scan techniques disclosed herein may adjust the passbands of one or more FLT modems according to the area currently being scanned and/or the scan techniques disclosed herein may employ other optimizations at the modem/receiver level intended to facilitate quick acquisition of a satellite. As a result, the scan techniques disclosed herein may be able to accommodate Doppler error and other issues without having to employ an extra-wide passband, which could result in greater noise in the system and interfere with the desire to achieve a quick acquisition.
As further illustrated in
According to techniques disclosed herein, the objective of a scan for a satellite may be to focus on scanning for the satellite within the ellipsoidal region 100 while avoiding or spending little time/effort scanning outside of ellipsoidal region 100. In some implementations, timing, azimuth, and elevation offsets may be applied to the expected position of a satellite to scan for the satellite in an ellipsoidal pattern as illustrated in
As illustrated in
In some implementations, the FLT may stop and dwell in each individual area while it scans for a satellite. In other implementations, the FLT may dwell only in a subset of less than all of the areas. For example, in some particular implementations, the FLT may dwell only in areas that are along horizontal axis 200 and/or at the boundary of the ellipsoidal region.
As illustrated in
At block 302, predicted location information for the satellite is accessed. For example, in some implementations, predicted location information may be available, for example, from the launch provider, based on the planned or actual deployment of the satellite, the planned orbit of the satellite following deployment, and/or the amount of time since deployment.
Based on the predicted location information for the satellite, at block 304, an initial position at which to start the scan is determined and, at block 306, an ellipsoidal region to scan is defined. In some implementations, the initial position at which to start the scan may be determined to be the (or near the) predicted position of the satellite at the time at which the scan is to start and/or the initial position at which to start the scan may be defined as the center of the ellipsoidal region to scan. Additionally or alternatively, in some implementations, the ellipsoidal region may have a relatively long axis representing the predicted path of the satellite and a shorter axis representing so-called cross-track error.
At block 308, the ellipsoidal region is scanned for the satellite. In some implementations, the scan may start at the determined initial position and proceed in a positive direction along the predicted path of the satellite to scan the front half of the ellipsoidal region and, if the satellite is not located, return to (or near) the determined initial position and then scan in a negative direction along the predicted path of the satellite to scan the back half of the ellipsoidal region. In some implementations, the scan may be stopped without scanning the entire ellipsoidal region if the satellite is located before the entire ellipsoidal region has been scanned. For example, if a signal is received by the feeder link terminal that is within a range of frequencies around the expected frequency of the satellite's downlink signal and the received signal exceeds a predefined power threshold, it may be determined that the satellite has been located, and the feeder link terminal may attempt to synchronize with the satellite and start autotracking the satellite. In some implementations, if the entire ellipsoidal region is scanned and the satellite is not located, the process illustrated in the flowchart 300 of
In some implementations, the passband of a filter used to filter signals received by the feeder link terminal may be modified dynamically based on the particular area within the ellipsoidal region being scanned at any given point in time to accommodate potential Doppler error in the satellite's downlink signal based on the position of the satellite (e.g., the area being scanned).
At block 402, predicted satellite position information is accessed and, at block 404, a determination is made as to whether the satellite is within sight of the feeder link terminal (e.g., a line of sight exists between the satellite and the feeder link terminal such that the satellite and feeder link terminal can exchange wireless signals) based on the predicted satellite position information. If it is determined that the satellite is not within sight of the feeder link terminal, the process returns to block 402.
Alternatively, if it is determined that the satellite is within sight of the feeder link terminal, a time offset is determined at block 406 and an azimuth and/or elevation offset is determined at block 408. (One example of a process for determining a time offset is described below in connection with
At block 416, a determination is made as to whether the applied combination of time, azimuth, and/or elevation offsets for the scan corresponds to a dwell region for the scan. If it is determined that the applied combination of time, azimuth, and/or elevation offsets do not correspond to a dwell region for the scan, at block 418, a dwell may be skipped, and, in some implementations, the feeder link terminal may scan continuously through the applied combination of time, azimuth, and/or elevation offsets. Alternatively, if it is determined that the applied combination of time, azimuth, and/or elevation offsets do correspond to a dwell region for the scan, at block 420, the scan may dwell at the applied combination of time, azimuth, and/or elevation offsets. For example, in some implementations, the scan may dwell at the applied combination of time, azimuth, and/or elevation offsets for approximately 0.1 seconds.
At block 422, a determination is made as to whether a signal received by the feeder link terminal during the scan is within a defined range of expected frequencies for the downlink signal from the satellite and, if so, whether such signal exceeds a predefined power threshold referred to in
Alternatively, if it is determined that no signal received by the feeder link terminal during the scan is within the defined range of expected frequencies and exceeded the predefined autotrack power threshold, the process continues to block 426, where a determination is made as to whether a downlink synchronization or spatial lock on the satellite has been achieved. If it is determined that either downlink synchronization or spatial lock has been achieved, the process proceeds to block 427. At block 427, the position at which downlink synchronization or spatial lock was achieved is set as the position for which to perform a small slow scan, and the process proceeds to block 436, which is described further below. Alternatively, if it is determined at block 426 that neither downlink synchronization nor spatial lock has been achieved, the process continues to block 428.
At block 428, a determination is made as to whether a signal received by the feeder link terminal during the scan is within a defined range of expected frequencies for the downlink signal from the satellite and, if so, whether such signal exceeds a predefined power threshold that is less than the autotrack power threshold and that is referred to in
At block 430, determinations are made as to whether (i) a signal has been received during the scan that was within the defined range of expected frequencies and exceeded the predefined sniff test power threshold, and (ii) a predefined amount of time (e.g., the time allocated to scan the ellipsoidal region) has elapsed. If either determination is negative, the process returns to block 404 and repeats. Alternatively, if both determinations are positive, the process proceeds to block 434 where the position at which the signal that exceeded the predefined sniff test power threshold is set as the position for which to perform a small, slow scan, and the process then proceeds to block 436.
At block 436, the feeder link terminal initiates a small, slow scan for the satellite based on the position set at block 427 or block 434. At block 438, a determination is made as to whether a signal received by the feeder link terminal during the small, slow scan is within a defined range of expected frequencies for the downlink signal from the satellite and, if so, whether such signal exceeds the predefined autotrack power threshold. If so, it may be determined that the satellite has been located and, at block 424, the feeder link terminal may attempt to synchronize with (or acquire) the satellite and begin to autotrack the satellite.
Alternatively, if it is determined that the feeder link terminal has not received a signal during the small, slow scan that is within the range of expected frequencies for the downlink signal and that exceeds the predefined power autotrack power threshold, the process proceeds to block 440. At block 440, the position during the small, slow scan at which the highest-power signal within the range of expected frequencies for the downlink signal from the satellite was received is determined, and the process proceeds to block 442, where a determination is made as to whether the power of that signal exceeds the predefined sniff test power threshold. If so, it may be determined that there is a possibility that the satellite may be located at that position and the process proceeds to block 424, where the feeder link terminal attempts to synchronize with (or acquire) the satellite and begin to autotrack the satellite. Alternatively, if the power of the highest power signal within the range of expected frequencies for the downlink signal from the satellite received during the small, slow scan does not exceed the predefined sniff test power threshold, the process returns to block 404 and repeats.
At block 452, a time offset counter is initialized by setting the time offset counter equal to zero. Thereafter, at block 454, a determination is made as to whether the time offset counter is less than one half of the sum of (i) the max time offset counter parameter (i.e., the predefined number of time offsets) and (ii) one. If so, the process proceeds to block 456, where the time offset is set to the value of the time offset counter multiplied by the predefined time offset step size for the scan. Thereafter, the process proceeds to block 458, where the time offset counter is incremented, followed by block 450, where the process repeats.
Alternatively, if at block 454, a determination is made that the time offset counter is greater than or equal to one half of the sum of (i) the max time offset counter parameter (i.e., the predefined number of time offsets) and (ii) one, the process proceeds to block 460. At block 460, a determination is made as to whether the time offset counter is less than or equal to the max time offset counter parameter (i.e., the predefined number of time offsets). If so, the process proceeds to block 462, where the time offset is set the negative of the difference of (i) the time offset counter and (ii) one half of the max time offset counter parameter plus one. Thereafter, the process proceeds to block 458, where the time offset counter is incremented, followed by block 450, where the process repeats.
At block 471, the azimuth/elevation offset counter is initialized by setting the azimuth/elevation offset counter equal to zero. Then, at block 472, the azimuth and/or elevation offsets corresponding to the value of the azimuth/elevation offset counter are selected from the predefined set. Thereafter, the azimuth/elevation offset counter is incremented at block 474. At block 476, a determination is made as to whether the azimuth/elevation offset counter is less then or equal to the maximum azimuth/elevation offset counter parameter (i.e., the number of azimuth and/or elevation offsets in the set). If so, the process returns to block 472 and repeats. If not, the process returns to block 471 and starts over.
While the techniques disclosed herein frequently are described in the context of locating LEO satellites shortly after deployment, the techniques disclosed herein also may be applied to searching for LEO satellites at any time and/or searching for satellites in non-LEO orbits, including, for example, geosynchronous and other orbits whether or not shortly after deployment of such satellites.
In particular implementations, the processes described herein may be implemented by a computer process loaded in memory and executed using one or more computer processors, for example, to control a feeder link terminal or Earth station to scan for a satellite. The computer-hardware implementing these processes may be located at or be part of such a feeder link terminal or Earth station.
Aspects of the present disclosure may be implemented entirely in hardware, entirely in software (including firmware, resident software, micro-code, etc.) or in combinations of software and hardware that may all generally be referred to herein as a “circuit,” “module,” “component,” or “system.” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more machine-readable media having machine-readable program code embodied thereon.
Any combination of one or more machine-readable media may be utilized. The machine-readable media may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of such a machine-readable storage medium include the following: a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an appropriate optical fiber with a repeater, an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a machine-readable storage medium may be any tangible medium that can contain, or store, a program for use by or in connection with an instruction execution system, apparatus, or device, such as, for example, a microprocessor.
A machine-readable signal medium may include a propagated data signal with machine-readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A machine-readable signal medium may be any machine-readable medium that is not a machine-readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a machine-readable signal medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF signals, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including object oriented programming languages, dynamic programming languages, and/or procedural programming languages.
The flowcharts and block diagrams in the figures illustrate examples of the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various aspects of the present disclosure. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order illustrated in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and machine-readable instructions.
The terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of any means or step plus function elements in the claims below are intended to include any disclosed structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present disclosure has been presented for purposes of illustration and description but is not intended to be exhaustive or limited to the disclosure in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the disclosure. The aspects of the disclosure herein were chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure with various modifications as are suited to the particular use contemplated.
As will be appreciated by one skilled in the art, aspects of the present disclosure may be illustrated and described herein in any of a number of patentable classes or contexts including any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof. Accordingly, aspects of the present disclosure may be implemented entirely in hardware, entirely in software (including firmware, resident software, micro-code, etc.) or combining software and hardware implementation that may all generally be referred to herein as a “circuit,” “module,” “component,” or “system.” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable media having computer readable program code embodied thereon.
This application is a continuation of U.S. patent application Ser. No. 16/247,388 filed on Jan. 14, 2019, which claims the benefit of U.S. Provisional Patent Application No. 62/617,287 filed on Jan. 14, 2018. The entire disclosures of each of which are incorporated herein by reference in their entirety.
Number | Date | Country | |
---|---|---|---|
62617287 | Jan 2018 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 16247388 | Jan 2019 | US |
Child | 17532760 | US |