CALTECH CONTINUUM BACKEND PRELIMINARY DESIGN REVIEW =================================================== [minutes from the Fri 06sep02 meeting in Green Bank] Attendence: Brian Mason (chair), Martin Shepherd (CIT), Tim Pearson (CIT), John Ford, Phil Jewell, Galen Watts, Mike Stennes, Roger Norrod, Nicole Radziwill, Rich Lacasse, Mark Clark Fundamentally it was agreed that the Caltech proposal was viable, and we will fund development at the requested level. What follows is an issue-by-issue summary of the conclusions we reached *, as well as some of the comments that were offered (*). In order to circumvent confusion, we'd also like to have a definite name for the project; we suggest Caltech Continuum Backend (CCB). The individual devices will be named CCB1 (1cm) and CCB3 (3mm). Some things which were sorted out since the PDR are indicated in square brackets. I. RFI/Enclosure * We agreed that building one backend (with all components: CPU, etc) for each Rx was a good idea. * The receiver frontend has no box enclosure; therefore all components of the CIT backend should sit in one enclosure, rather than being separated into digital and analog sections. This enclosure will bolt on to the back of the receiver, allowing a maximum size of about 15 inches square; a depth < 10'' is probably adequate. Internal shielding between digital and analog parts will be included. * For RFI screening, component specifications up to 10 GHz will suffice (*) Ease of access should be considered when designing the enclosure & its internal layout II. Spares * A complete 3rd system is not necessary. In particular, no spare enclosure is needed. * Spares should be provided at the board level and at the component level. * We should receive min(10% x N,1) spares, where N is the number of such boards or components that a *both* backends require. III. Dynamic Range * At the PDR we suggested that 14 bits of effective resolution would be sufficient, but this needed some more careful thought (completed action on BSM). The line of reasoning and conclusion is: Assume we want to observe sources up to 100 Jy, in conditions up to tau=0.1 (30 GHz) or tau=0.2 (90 GHz), and down to 15 degrees elevation. We also want to make hot load measurements, and fully sample the noise in the minimum noise configuration (for both receivers, this is a blank, transparent sky observation). Assume Rx temperatures of 35 K (1cm) and 80 K (3mm), and include 3 K (CMB) and 5 K (ground) DC terms; further assume 4 GHz and 8 GHz per channel bandpasses, respectively. For the 1cm Rx the hot load gives the contraint, resulting in 11.2 bits required dynamic range. The 100 Jy source at 15 degrees elevation gives the constraint at 3mm, of 11.1 bits. These calculations assume 25 usec integrations; the requirements would be more strict for longer integrations. Allowing ~2 bit sampling of the (1 sigma) noise, which is somewhat conservative, 13 bits of effective resolution will satisfy the observing reqmts. * The issue of multiple gains was left open at the end of the PDR. BSM, GW, and MS have looked at this since and determined that multiple gains in the backend are not needed: NRAO will tune the receivers to produce measureable voltages over the desired range of antenna temperatures. The range of temperatures corresponding to the above calculations are 43 - 330 K (1cm) and 88 - 445 K (3mm; which for other reasons may be hard to acheive) IV. Delivered Data, Noisecal coordination, and Scan definitions * The backend will deliver 1ms averages of each phase state from each detector separately, unless this proves to be technically unfeasible in which case we will specify another combination of data products to be delivered (eg, total power averaged over the nominally equivalent [0,0] and [pi,pi] states, and the [0,pi],[pi,0] states) Note: 1ms of 25us phases divided into 4 bins (phases) yields only 10 samples per detector per integration. The rms of the means of the 10 samples is a (5%) biased estimator of the underlying variance. The mean of the means is an unbiased estimator of the mean. This is not problematic but we should be aware of sampling/data combination issues. (*) The backend is free to support longer integrations for develoment, testing, and commissioning purposes, but this is not required. * Each ms integration will also be delivered with flags indicating which if either of the noise diodes was on. * The noise diodes will be controlled by the backend (as will the phase switches); turning the diode on and off will be synchronized with the phase switch state cycle. Downstream analysis software will be independently told how many integrations to ignore, if any, on either side of a cal state transition. (*) The precise definition of a scan is TBD, but conceptually it is at this stage: (N_0, N_1, N_2, N_12) x N_C Where N_0 is the number of integrations (each nominally 1 ms) with both cal's off-- the astronomy data; N_1 is the number of integrations with cal 1 on; N_2 is the number of integrations with cal 2 on; N_12 is the number of integrations with both cal's on; and N_C is the number of times to repeat the entire cycle (in practice, N_C is likely to be inferred from the specified scan length in seconds). An implementation which fixes the order of the various phases is fine (eg, scan = N_0 astronomy integrations, followed by N_1 cal 1 on integrations, ... etc-- repeated N_C times), and we should agree on this ordering/definition up front. V. Software * We agree that a separation into radiometer server/ygor control manager will facilitate development, and are working on defining a concrete interaction protocol for these two programs. * Caltech will be responsible for delivering a radiometer server which follows the agreed upon protocol, and consistent with the guidelines established by the NRAO software group in "Software Development Partnering Process" memo. Caltech will also develop a simple GUI for the backend, for purposes of lab testing and possibly some commissioning. * Provided the timelines layed out in the "Software Development Partnering Process" memo are met by Caltech, NRAO commits to delivering a functional manager for the backend by Sep 1 2003. NRAO is also responsible for developing the data analysis software, with assistance as possible from Caltech. This will start with Astronomical Use Cases, to be written by BSM in consultation with TJP. (*) It was noted that due to a) the presence of 1 (not 2) noise diodes and b) the presence of 2 (not 4) phase switches, the 3mm and 1cm backend software will be different. (in addition to the difference in the number of continuum channels) (*) further detailed progress on software protocols was made offline, to be documented elsewhere in the future. VI. Project Timeline & Targets * NRAO suggests a Sep 1 target for commissioning the backend on the telescope. This generously allows for unforseen slippage of hardware and software timelines on both sides, and will coincide with better weather. TJP will check that this schedule works for CIT; if not we will revisit the timeline laid out below. * A separate item for in-lab integration tests, to be conducted at Green Bank, will be added to the schedule, again pending CIT's agreement to this. * The 3 month detailed design phase suggested by CIT is thought to be reasonable. * The Nominal Schedule is then: - Sep-Dec 2002: Detailed design - Dec 2002: CDR - Jan 2003 - May 2003: construction & lab testing - June 2003: pre-delivery review - July 2003: Lab integration test at GB - early Sep 2003: On telescope integration & commissioning - late Sep 2003: Acceptance review * As rapidly as feasible, NRAO & CIT will identify and specify all interfaces (i.e., well before the CDR). RN suggests a single spreadsheet summary of these; BSM has volunteered to draft & maintain this document. * Our goals for the CDR in December are: - Present & review the design & documentation, which should be thought of as in principle being sufficient to construct the device - Finalize & review all interfaces - Specify tests to be conducted at the delivery review - Have a data simulator in hand for the NRAO M&C group (this will act like the RADIOMETER described in GBT software project note 23.0). - We also indicated as desirable having a quick-look program at this point, although that may depend upon having a FITS specification for the backend well before Dec, which may or may not be feasible; or it may use the samplers or an alternate path. Unless clarified and agreed to be important, we do not regard this as required. * The budget is fine (but TJP needs to double check the spares calculation and verify no extra salary is needed for the Sep 2003 commissioning). PRJ, TJP, & ACR will will take care that the MOU get through the administrations by the end of the fiscal year (Sep 30). TJP & MCS will provide BSM with a final copy of the proposal and preliminary design "for the record". No changes are required.