(Working Draft)
Note: I will attempt to use the 'new' definitions in this discussion, (i.e an observation is a 'scan', and what we normally refer to as a scan is a 'subscan'.)
During the execution of a scan, often a large inter-subscan latency exists with the antenna. This latency is mainly due to the antenna's action in the stopping phase. Currently it attempts to track a stationary point in the selected coordinate system. But this action is extraneous. If the details of the next subscan were known, the stopping phase could introduce a trajectory which brings the telescope into position for the next scan.
The idea would be to present the antenna with information for (at a minimum) the current and next sub-scan during configuration. The antenna would use the information during the stopping phase to compute a trajectory which would send it on its way toward the start of the next sub-scan.
When operating in this mode, the antenna would quickly transition from Stopping to Ready. The observing engine (Turtle, or GO) would note the system has returned to ready, and would begin reconfiguring the system for the next sub-scan, and then trigger the next sub-scan with a 'start' command. At this point the antenna is already moving toward the anticipated target. The 'start' command at this point would cause a recomputation of the trajectory based on its current state.
Timing is obviously critical. If the system takes too long to start the next scan, the antenna may need to 'back-off', from the assumptions it has made about the next sub-scan (likely a costly operation with respect to time). I beleive testing can provide fairly reliable estimates of the time required from the end of a scan to the 'start' (activation) of the next scan.
In order for the system to know what the current sub-scan index is, a new base-class' parameter would be required in the Control library. A new control parameter called 'subscan_index', which is a structure that contains two integer fields: current and final. (The new parameter can be safely ignored by most devices.)
class Subscan_index {
public:
int current; // index of the current subscan (e.g. 1, 2, 3, 4 ... N)
int final; // index of the last subscan in the scan (e.g. N)
};
The antenna uses a construct called a '[sub]scan-segment list' to define the desired trajectory of antenna elements during the life of a subscan. The elements are processed in order to define a piecewise parabolic trajectory. In order for the antenna to operate on multiple subscans, each scan segment type parameter would have a 'subscan_index' field.
This new field would be treated as an identifier to sort segments between subscans, using the 'current' field of the new subscan_index parameter to select out the pertinent segments for a given subscan.
Consider a pointing cross-scan:
| subscan_index | majorAxis (PVA) | minorAxis (PVA) | segment duration |
|---|
| 1 | pos=19.5, vel=120, acl=0 | pos=35.0, vel=0, acl=0 | 0 |
| 2 | pos=20.5, vel=-120, acl=0 | pos=35.0, vel=0, acl=0 | 0 |
| 3 | pos=20, vel=0, acl=0 | pos=34.5, vel=120, acl=0 | 0 |
| 4 | pos=20, vel=0, acl=0 | pos=35.5, vel=-120, acl=0 | 0 |
When the scan is started, the scan_index.current field is set to '1'. The Antenna considers all segments which match the subscan_index for the subscan and processes them normally. During the stopping phase the antenna checks to see if this is the scan_index.current is less scan_index.final, if not, it attempts to setup for the next subscan by selecting the segments with the value subscan_index.current+1, and proceeds to slew into position.
Meanwhile, the rest of the system completes subscan 1, and waits for the observing engine to activate the next scan. The activation of the next scan causes the antenna to recalculate an update to the slew trajectory, which is harmless.
This takes care of the most dynamic antenna controls, but does not address cases where the coordinate modes are changing between sub-scans. This limitation is understood, but at this time I can't think of any cases where a single scan (observation) would require it. If it is needed for a special case, the inter-subscan latency will just be higher.
The tricky part is: What happens if the antenna does not receive the activate by the time it is in position?
I (RMP) would suggest adding two additional quantities, a "default" segment (perhaps indicated by -1 in the subscan_index?) and a timeout value. The calling observing procedure, knowing what it was intending to do, it should know what to set the timeout to. If the antenna receives the activate command before the timeout, it proceeds with the next subscan as expected. If it does not receive the activate command before the timeout, it proceeds to execute the default segment, and tracks this indefinitely. The current behavior of the antenna could be replicated by providing a default timeout value of 0, and a default "default" scan segment to track the tracking center (or whatever the antenna currently does.
-- JoeBrandt - 10 Jun 2004
Revision r1.5 - 11 Jun 2004 - 18:03 GMT - RichardPrestage
Parents: TWikiUsers > JoeBrandt
|
Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.
|
| |