Uploaded image for project: 'SAFe Program'
  1. SAFe Program
  2. SP-1553

Exploration of SDP RCAL for AA0.5

Change Owns to Parent OfsSet start and due date...
    XporterXMLWordPrintable

Details

    • Spike
    • Not Assigned
    • None
    • COM SDP SW
    • None
    • Data Processing
    • Hide

      The capability for SDP to perform simple, pseudo-realtime calibration (RCAL) for MID pointing and MID/LOW tired array beamforming is anticipated to be required for the commissioning of early array release and establishing these pipelines early greatly reduces the risk of their development. 

      At the moment there is likely considerable risk being carried in missing solution architecture (detailed design) of cross-element system interfaces needed to support this functionality and therefore starting this work in PI10 gives us sufficient lead time to develop these and still have a working initial solution for AA0.5 (~PI16/17).

      Show
      The capability for SDP to perform simple, pseudo-realtime calibration (RCAL) for MID pointing and MID/LOW tired array beamforming is anticipated to be required for the commissioning of early array release and establishing these pipelines early greatly reduces the risk of their development.  At the moment there is likely considerable risk being carried in missing solution architecture (detailed design) of cross-element system interfaces needed to support this functionality and therefore starting this work in PI10 gives us sufficient lead time to develop these and still have a working initial solution for AA0.5 (~PI16/17).
    • Hide

      TBD limit scope to the formation of tied-array beamforming weights?

      • Review completeness of current solution architecture and develop a proposed solution for the implementation of SDP RCAL workflow(s) for AA0.5, paying particular attention to:
        • Existing implementations from other telescopes (MWA, LOFAR, MeerKAT, ...)
        • (IMPORTANT) Interface requirements with other SKA software elements
        • What will be needed for testing the solution when developed (input data, simulators/emulators etc)
      • The output of the review and the proposed solution should be captured in Confluence (preferably in the Solution Intent space). 
      • (Stretch) Develop a minimal PoC for a selected RCAL workflow, possibly based on existing codes. While there is no expectation for this to be a solution that is integrated into the SDP system, at least until after PI12, the route to this eventual integration should be considered from the start.

       

       

      Show
      TBD limit scope to the formation of tied-array beamforming weights? Review completeness of current solution architecture and develop a proposed solution for the implementation of SDP RCAL workflow(s) for AA0.5, paying particular attention to: Existing implementations from other telescopes (MWA, LOFAR, MeerKAT, ...) (IMPORTANT) Interface requirements with other SKA software elements What will be needed for testing the solution when developed (input data, simulators/emulators etc) The output of the review and the proposed solution should be captured in Confluence (preferably in the Solution Intent space).  (Stretch) Develop a  minimal PoC for a selected RCAL workflow, possibly based on existing codes. While there is no expectation for this to be a solution that is integrated into the SDP system, at least until after PI12, the route to this eventual integration should be considered from the start.    
    • 3
    • 11
    • 11.2

    Description

      A number of simple, SDP pseudo-realtime calibration (RCAL) workflows are expected to be needed for the SDP system deployed at Array Assemblies, possibly as early as AA0.5:

      1. MID all-sky reference pointing which has the capability of ingesting data from pointing scans (cross-scan or raster), applying appropriate delay/bandpass calibration and RFI masks (see SP-1554), fitting for offsets and returning them with diagnostic (QA) information. 
      2. Calculation of coefficients for tied-array beamforming to be used by CBF. For AA0.5 this requirement will depend on the availability of beam-forming hardware and is essentially a (DI) complex-gain solution with bandpass and RFI masking applied (see SP-1554). While the expected plan for beam-forming hardware for AA0.5 is still being developed and will be very simple - ie a single on-axis tied array beam - we believe that having an initial baseline workflow started that we can integrate on in future PIs is going to be extremely valuable. 

       

      Attachments

        Issue Links

          Structure

            Activity

              People

                b.mort Mort, Ben
                r.brederode Brederode, Ray
                Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (0%)

                  Feature Estimate: 3.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete00.0
                  Total00.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel