Chain Definition
This window enables you assign objects to the chain and define the order in which the objects are accessed. Use the following buttons to define the chain:
You can also double-click an object to move it between the Available and Assigned lists. Use the Selection Filter to move one or more groups of objects by category.
Another way to limit the number of paths is through routing rules, which you can apply to both constellations and satellite collection subsets. In their Properties > Basic list, select Routing. Then select the Use routing file check box and browse to your file containing rules that determine which links between objects are valid. Chain computations will bypass all paths with invalid links. For more information on how to create these rules, see Routing File Format.
A child (subobject) of an object is not automatically moved when its parent is moved. For example, if you want to assign a sensor that is attached to a satellite to the chain, you must move the sensor to the Assigned Objects list; it is not sufficient to move just the parent satellite.
The order of objects in the chain can be especially important if the chain includes planets. Access calculations in a chain take light time delays into consideration. This can lead to unexpected results if you place a planet in the chain incorrectly.
Constellation constraints can affect access calculations in a chain.
The following figure illustrates the impact of light time delay on the first access calculation in a Sun-satellite-facility chain:
Impact of reversing constellation order on constraints
Reversing the order of two constellations in a chain changes the way in which some constellation constraints are applied. For example, calculating access between a chain with a constellation containing two facility sensors and a constellation containing GPS satellites will differ depending on which constellation is first in the chain.
In both cases (sensor constellation to GPS satellite constellation and GPS satellite constellation to sensor constellation), STK first determines individual accesses (i.e., all pairs of GPS satellites and sensors). STK then applies the constellation constraints. In this example, the constraints are AnyOf for the GPS satellites and AllOf for the sensors.
In the case of GPS satellites to two sensors, STK computes the time intervals for each sensor when it has access to any GPS satellite. STK generates an interval list for each sensor. STK then applies the AllOf constraint by intersecting both interval lists. This results in the valid intervals satisfying the constraints. For each access pair, STK then intersects the pair's access times with the valid intervals. Thus, at every valid time, both sensors must be able to see at least one (i.e., AnyOf) Satellite in the GPS constellation. However, any GPS Satellite that can be seen by either sensor at such a time is considered to be included in the Chain's complete Access intervals.
In the case of two sensors to GPS satellites, STK computes the time intervals for each sensor when it has access to any GPS satellite. STK generates an interval list for each sensor. STK then applies the AllOf constraint to each GPS satellite individually. STK computes the intersection of each sensor's access to each GPS Satellite (i.e., AllOf) producing valid intervals for each GPS satellite. STK then compares the intersection of each Sensor's access time with these valid intervals. Since each GPS satellite is considered by itself, the complete Chain access includes times in which both sensors can see the same GPS satellite (i.e., All Of). Times at which one sensor can see a GPS satellite and the other sensor cannot are not taken into account.
Thus, when the GPS satellites constellation appears first, with the AnyOf constraint, the GPS satellites are considered as one entity; when the constellation appears second, it is treated as a collection of individual GPS satellites.