Carma Real Time Software Task list
Steve Scott/Marc Pound
March 27, 2006
Version 1.13

# of Priority 1  - 49  (49 assigned)
# of Priority 2  - 42  (42 assigned)  
# of Priority 3  - 36  (18 assigned; not on 6 month horizon)


Does not include:
 Correlator software
 Calibration & Imaging 
 New requests for functionality

CONTROL
o Change interfaces to use CARMA antennas numbers (1-Tom/Steve) DONE
o Calibrator control and wait for position(*1-Steve) DONE
o Get all control parameters into monitor system (1-Marc)
o Monitor point reorg, command segregation (1-Marc)
o Channel average definition (*1-Andy)
o Control integration of correlator spectral modes (1-Steve)
o Optical pointing - writing of coeffs in C++ (1-Peter)
o Weather station time interval (1-Peter)
o DPS integration (1-Peter)
o PAM levels for load/calibration (2-Andy/Colby)
o Maintenance and bug fixes (1-Everybody)
o Change correlator config states & wait to complete (2-Tom)
o Tuning synchronization(*2-Colby)
o Saving/restoring subarray controller state(*2-Tom)
o Add downconverter amplifier control to noise command (2-Marc)
o Phaseswitching (2-Colby) Flexible assignment of phaseswitching patterns
o Signal mapping (2-Tom) Full support of arbitrary hw setup
o Deal with wrap differences and antenna types (*2-Colby)
o Observing blocks (*2-Marc)
o Wait on logical combinations of criteria (2-Tom)
o Radio pointing peakup (2-Steve)
o Optical pointing using centroiding results (2-Peter)
o Tsys measurement (**2-Peter)
o Sideband ratio measurement (2-Colby)
o Ephemeris handling of terrestrial (fixed) sources (2-Peter)
o fixed (terrestrial) source command (2-Marc)
o UVW interpolation (2-Marc)
o IVcurve (*3-)
o Recognize if correlator does not have power-up config (3-)
o Delay peakup (3-)
o Focus (z only) peakup (3-)
o Low level system state (*3-)
o Integration cmd as described in control design and requirements (3-Steve)
  Includes wait for N ants acq, %ants acq, %collecting area acq, 
  max integ time determined by uv cell crossing (@see Miriad's dwell.for), 
  elevation criteria, Tsys cal interval...
o UserID's (3-)  Do we really even care about these?
o Single dish position switching (3-)
o Sky dip (3-)
o OVRO z-focus tracking (3-Andy)
o z-focus delay correction in correlator pipeline (3-Andy)


MONITOR
o Sync IPQ reads to VM pages(1-Tom)
  Very large decrease in cpu for RTD.
o Dropped frames
  Analyze synchronization logs to see how many are dropped  (1-Steve) DONE
o Take appropriate action to correct dropped frames (priority TBD).
o New correlator subsystem, rename and resize existing one (**1-Rick)


UI
o RTD of subarray ant assignment (1-Tom)
  Single page with all subarrays and assigned antennas.
o RTD Multi-cell multi-trace plotter(1-Steve)
o RTD two cell scatter plot(2-Steve)
o Sexagesimal for RA/dec(1-Marc)
o Composite window with subarray tabs, proj baselines (1-Marc)
o Automatic build of Windows exectuable (1-Marc) DONE
o SAC startup sym links(**1-Dave)
o RTD Phase Monitor  (2-Colby) 
o RTD Antenna/Pad offset (maybe put in composite) (2-Marc)
o RTD OVRO Gunn  (2-Andy)
o Bima rx table (2-Colby)
  Like ovro ones, complementing existing bima rx pages.
o RTD BIMA Telemetry (2-Colby) Is a separate RTD window really 
  needed for the telemetry monitor container?  It has only one 
  MP--will it have more in the future?
o logBrowser (2-Marc)
o Observers can enter comments directly into log (2-Marc)
o Python wrappers (2-Peter)
  Write wrappers for all of the subarray interface, thus allowing
  default values, antenna lists, etc.
o Observing blocks (*3-)
o Get CDV to work outside the firewall (3-Rick)
o Flux history (3-)
o CMV Java interface (3-Colby)
o User customization/Desktop paradign (3-)
o Tear-off AzelPlot(3-Marc)
o Tear-off UV coverage plot(3-Marc)

OBSERVER SUPPORT
o Interactive support (ongoing-All)
o MIRIAD support (2-Peter)
o Obs planning tools 
  - JRMS calculator upgrade (3-Marc)
  - CalFind upgrade (requires flux history)  (3-Marc)
  - Xcorf replacement or MIRIAD corset upgrade (3?-)
  - Observing simulator (3-)
 
OVRO ANT
o 1mm rx - integration of HW and checkout (1-Andy)
o Modify stow position to avoid Cloudsat (1-Steve)
o Optics (2-Andy)
o Drive upgrade (2-Andy)

BIMA ANT
o Drive stalls - algorithm optimization (1-Colby)  DONE
o Integration of telemetry status bits (1-Colby)  
o Modify stow position to avoid Cloudsat (1-Colby)
o Sequence numbers (1-Colby)  DONE
o Dewar temperature regulation (2-Colby)

COMMON ANT
o Reorganize antennaCommon monitor system(1-Colby)  DONE
o Relayout common RTD with tabbed folders (1-Colby)
o Optical centroiding(2-Andy)

FAULT SYSTEM
o Fault system - basic, simple DAG (1-Tom)
o Fault system - bigger DAG (1-Tom)
o Display of root faults (1-Tom)
o Fault system control (cmds to ignore components, wildcards, etc) (2-Tom)
o Alarm control (2-Tom)

PIPELINE/CORRELATOR
o Pipeline Tsys (1-Andy)
o Pipeline Flux (1-Andy)
o Pipeline Band phase offsets (1-Andy)
o Pipeline ChannelAverage (1-Andy)
  into monitor stream
  feedback into monitor stream.
o Antenna based visibilities (**1-Peter)
o Visbricks named by starting frame count (1-Rick)
o Visbricks renamed to '.done' after they are complete (1-Rick)  DONE
o Integration of correlator spectral modes (1-Rick)
o Integration of downconverter spectral modes (1-Andy)
o 2nd LO counter (1-Andy)
o Pipeline Linelength correction (3-Andy)
o Pipeline realtime focus Z correction (3-Andy)
o Pipeline Bandpass correction (3-Andy) - maybe drop?

SYSTEM/NETWORK
o Internet link to CIT (1-Rick)
o Local disks on database computer (1-Rick)
o Move pipeline tasks to its own computer with local disks (1-Rick)
o Backup internet link from Cedar Flat (2-Rick)
o Integration of remote power cycling for antennas (2-Rick)
o Google search device, or public domain sw alternative (3-Rick)

OTHER
o Miriad realtime filler (1-Athol)
o Bima focus tables (1-Peter)
o Mir converter (1-Athol)
o Phase monitor, hat creek mode (1-Colby)
o Lobe rotator API update (1-Steve)
o CANBUS API update (1-Andy)
o Phase monitor, integrated with carma (2-Colby)
o Linelength subsystem (2-Dave)
o Anti-collision (2-Dave)
o Master Clock reorganization (2-Andy)
o Software Release R5.5 (2-All)
o Opacity monitor (3-Andy)
o Independent restart of subarrays (**3-Dave) 
o Decrease shortest integ time to 0.5secs (3-)
  Must reduce MAW cpu usage, or redesign to not create astro headers when
  records are shorter than X.
o Tilts (*3-)
o Central IF [digital GOOD/BAD for each antenna] (2-Dave)
o Support for tracking Solar surface coordinates (3-)
o Support for galactic coordinates (3-)
o Vax support (?-)
  Perhaps not necessary if partial drive upgrade is done soon. Otherwise
  design is needed to fix bugs and smooth out usage - pretty big task.
o Sky dips (3-)

SW ENG
o Libtool for carma build system (2-Dave)
o Distributed make for carma build system (3-Andy)
o Python plotting library (3-Peter)
o Replace Orbacus C++ with Tao (3-Andy)
o Replace Orbacus Java (3-)
 
 
*DESIGN - TODO
o Control synchronization(1)
  Identify all types of synchronization. Monitor system seq# for each
  one or share some of them? Cal wheel, tuning, correlator config change,
  optical centroiding, antenna motion, IVcurve, correlator power-up config,
  tilt?, skydip?
o Optical pointing with internal antenna centroiding.
o How to access antenna based visibilities()
o Control antenna interface specification
  Subarray slot or physical names, or both?
o Saving/restoring state
  We have the monitor system portion of this in place to expose the
  variables but there is more to it.
o Low level system state
  What do we do about the state stored in different DO's and in different
  CANbus nodes? These can get restarted and rejoin the system - what
  about their internal state?
o Wrap handling for different antenna types
o Observing blocks
  Pretty big job to design this, both control and UI.
o Channel averages
  Details on exactly what we can do, e.g. vector of bands/sidebands,
  each with channel range. Any shortcuts for all channels in a band? All
  bands? Both sidebands?
o Tilts
  Need to determine system requirements for tilts (time interval, accuracy,
  hysteresis, etc)
o IVcurve
  What do we do with the results (and who wants them)?
 
 
**DESIGN DECISIONS
o Control client (sac) startup
  There is ambiguity between the subarrayControl process and the sac
  client interface. The sac will be started up with logical links to
  sac representing the different subarrays, invoked with: sci1, sci2,
  eng, maint, offline. Makefile targets must create these links, and sac
  scripts must interpret arg0 to know which subarray to launch.
o Antenna based visibilities
  All antenna visibilities are calculated on chanAve data. Add monitor
  points for both frame and integration average (SL & WB) chanAve
  antVis. Pipeline will calculate frame chanAve antVis and stuff into
  MPs. The pipeline will create an integration average for the chanAve and
  then solve for the antVis and put them into the integration average MP's,
  which will make them available for the control system. *But we haven't
  decided how to make the integration average MPs correct in the database
  (probably need to change some logic for these monitor points in the MAW).
o Correlator monitor system
  First 3 bands will be SlLowresBand[1-3] next five will be
  SlHighresBand[1-5]. Each band type will have a common container that
  will be used by common code to access in a Band independent fashion. Can
  use templates or conditional clauses.
o Independent restart of subarrays
  Leave all IMR's up, and start/stop processes that belong to specific
  subarrays and then restore their state. Need to know which antenna
  belongs to which subarray, but that is in the monitor system.
o Tsys measurement
  Returns vector of tsys structures, Tssb, ant#, band, sideband, bw. Python
  can display, maybe graph results.
o Pipeline Channel averaging
  There is a single channel average visibility and weight for each baseline.
  These will be stored as monitor points and will be filled every frame by the
  pipeline. Channel averages will be specified by a sequence of channel
  ranges. A single channel range sequence will apply to all baselines. A range
  consists of a start channel, end channel, band#, and sideband. Sensitivity
  (1/(tsys*root(chanBW))) and integration time (this probably translates to
  just blanking acceptance or rejection, but if not binary it will multiply
  the weight by 1/root(integTime)) will be used in computing the average and
  weight. The control system has not yet implemented the interface for
  controlling the channel ranges.