Details
-
Feature
-
Must have
-
LOW ART
-
-
-
2.5
-
1
-
3
-
1.2
-
Team_MCCS
-
Sprint 3
-
-
-
-
-
Team_MCCS mccs_software
Description
Work on configuring / controlling TPMs for beam formation / pointing / tracking continues.
In this feature clone we will:
- Close any remaining gaps in the configuration steps
- Realign the commands in Station towards the architecture for station beam pointing described under MCCS-1701 + MCCS-1702
- Implement a mechanism for updating pointing as required to track at sidereal rate
We will take this opportunity for knowledge transfer in respect of the beam-forming architecture.
Note that this is required both for AAVS3 (beam-formed observations) and AA0.5 onwards.
As this feature is a Clone, Some of these aspects may have been completed already. The comments on the Outcome of SP-1970 which this Clones should be considered for the part still remaining to be completed.
-----------------------------------------------------------------------------------------------------------
Whilst SP-1718 extended TPM configuration capabilities, further to form and control beams on AAVS (and beyond) we need to finish implementing the linkages between the beam devices and the tiles. We must fill any remaining gaps in resource management (de-allocation?). To implement the Scan command we need to start a PointingJob and connect this to the TPM delay control.
The initial version of the beams will be pointing to the Zenith for drift scan observations (0 geometric delay, but cable delays obtained through offline calibration are corrected for)
After the drift scan is established, to facilitate pointing for AAVS operation (i.e. in the absence of a TM system) we might consider implementing appropriate 'back-door' functionality. For instance, a driving notebook could set beam pointing for a strong source such as the Sun or galactic centre and demo a real observation. This would use the methods in station/point_station.py. The more advanced case would run regular updates to achieve scanning / tracking.
In PI18 it was expedient to sidestep some of the SubarrayBeam allocation/configuration work, leaving some of this functionality in Subarray rather than fulfilling the planned architecture. We will implement SubarrayBeam as intended, so as to abstract beam functionality, removing station-level beam responsibilities from the Subarray device.
