Dear Tim, Tony, Martin- We have considered in detail your draft proposal and design and are very impressed with both. We do have quite a few comments, which I've divided below into three categories: 1) Major Overall Comments: These are important items which need to get addressed by the time of the PDR, and should be addressed in the PDR documents (proposal, mou, and preliminary design). 2) Minor Comments: These are mostly, we believe, simplifications, eg, indicating that we agree on an issue and thus dismissing it; or simply dismissing hypothetical alternate scenarios. They are meant to focus everyone's thinking, and most should be easy to redress in the proposal docs. 3) Detailed Comments: There are quite a few of these, particularly in connection with the electronics. We do not want to suggest that a complete redesign which implements them is in order on the timescale of the PDR (partly because mutual iteration will be necessary for this, and some key personnel on both ends are unavailable for much of the time remaining to us); nor do these issues need to be explicitly addressed in the PDR proposal documents. However we do hope you will have considered responses to these issues at the PDR, and we will aim to resolve as many of them as we can at that time. We can expect iteration on issues like this through the CDR, and we do not feel that they impact our assesment of the proposed design at the go/no-go level. Since some key NRAO personnel will not be in Green Bank on the day that Tim has proposed for the Preliminary Design Review (August 30) we would like to propose that this be held in early September, tentatively, Fri 06sep. The paperwork for the backend needs to have already been started through the system by that time; it is then fairly important that the budget be in good shape before then. We think that the only of our suggestions which could significantly impact the budget are: 1) the need for more consideration of RFI mitigation; 2) the desire for spares to be written into the MOU (both detailed below). These are then the priority items for further consideration. Let me know if you have any questions or concerns. cheers, Brian MAJOR OVERALL COMMENTS ================ * A detailed discussion of the strategy/requirements for RFI mitigation is missing from the current draft, and this is very important. It is likely that a custom enclosure will be necessary. John Ford and others here will be happy to give feedback and guidance on this score. For more details, see the first item below (beginning "The assembly/packaging issue") * The MOU should include the provision of sufficient spares to operate both systems for 10 years. This should include board level spares for all modules as well as spare ICs and certain mechanical parts that are likely to wear, like connectors and fans. However, note that Phil will redraft the MOU so that as closely as possible, it follows those that we use for other university projects. The details of this can be agreed upon at the PDR. In the final version we will also designate myself as official NRAO contact point for the project. * Better software boundaries are needed; in particular, the scheme of decoupling the backend control software from YGOR is not something that works well in our experience (we have other packages which have adopted this scheme). Green Bank personnell will commit to provide a skeleton for the backend control manager based on the YGOR libraries. Similarly, the proposed radiometer server command protocol looks like others we've not had good experiences with-- we need to be sure proper 2-way handshaking takes place, rather than 1 way commanding only. The proposed control manager skeleton will help ensure a good protocol. Since we would like to eliminate the GB-written interface to the radiometer server, we should add a statement to the 4.8.4/4.8.5-replacement section along the lines of "The backend control manager will write the data from the backend in a FITS format to be mutually detailed at a later point." MINOR COMMENTS ================= * The assembly/packaging issue: We think that the best solution, when weighing complexity, RFI, and cost is to duplicate the whole thing (A/D, FPGA, RTC) for each receiver. The RFI enclosure needed for the FPGA would then also shield the CPU board. Another route is the CIT base proposal of two A/D and digital assemblies (one for each Rx) and a single realtime CPU. This is not unreasonable, however, a separate RFI enclosre would be needed for the CPU, and we would have to ensure that the cable lengths etc. are acceptable. We suggest dismissing this scenario. The shielding effectiveness required of the RFI enclosure will depend on the radiation characteristics of the internal electronics, but our experience to date shows that typically 60-70 dB is required 30-2000MHz. All copper conductors in/out of the RFI box must be filtered. * We should continue to detect total power and difference in software: the hardware cost is minimal and there are many benefits. It is not clear that the proposed alternate scheme of cheap A/D's for total power detection would have any advantages--- it would probably complicate the design and downstream data handling, so let's stick with the current proposal. * The CIT CBE should not be involved in the receiver monitor & control functions which are administered via the MCB. Since GB is responsible for the receivers (1cm & 3mm) themselves, we will provide this all of this functionality, and it should not be coupled to any particular backend. Caltech is responsible only for control of the backend, not the receivers. * The arrangement of having the CIT CBE be master of the phase switches during operation (with no "slave" capability) departs from current practice, but given the constraints and benefits is a logical choice. We note that this precludes simultaneous use of the CIT CBE with another backend, but we cannot think of a compelling reason that would be bad; some thought should be given in the implementation to being able to switch between the CIT CBE and another backend on a reasonable timescale so that we can at least multitask in serial. (eg, using the sensitive continuum backend for pointing reference during a spectrometer observation) * Firing the noise diodes will need to be coordinated with the phase switch states, and this also needs to be controlled by the backend if it is master. There is one noise diode in the 3mm Rx, and there are two in the 1cm Rx. Interface TBD mutually. * The discussion of "strong source handling" is a bit off base and should probably be edited or expunged so as not to be confusing. It is a good point that when T_src >> T_rx gain fluctuations do contribute to the system noise, however any radiometer has a limit where this is the case, and a correlation radiometer is a factor of two *better* than a single total power radiometer in this limit. The statement that the gains are different on strong and weak sources is erroneous-- the gain is g_1 g_2 in both cases. * This said, if it would simplify the design and data handling, 16-bit data acquisition would be fine. This implies an antenna temperature limit of 485 K at 30 GHz and 1080 K at 90 GHz. * Even were we not to reduce the dynamic range of the A/D, it seems that the "user-selectable lower gain mode" is a good idea. This is particularly true since the 3mm Rx has no programmable attenuation, and some way to set the levels is desirable. The noise diodes will allow the calibration to be transferred between different gain states. It is presumed that the programmable gain will be after the detectors. * The proposed NTP + 1PPS timing scheme is a good one (see also "interfaces" below). Others need not be considered. * Section 8 of "Proposal Budget" 2001/2002 -vs- 2002/2003 in the budget Table: presumably 2002/2003 is correct. DETAILED COMMENTS ================== * System cooling requirements should be addressed in the design. * Data going from the ADC to the computer are not time-tagged, and we need to consider whether this is bad (eg, for on the fly mapping). Probably delays between the ADC and the RTC are ~ usec and thus not an issue. The minimum integration time of 1 ms is fine for on the fly mapping applications. * Interfaces: 1- Packaging-- see 1st comment above 2- Interfaces with front-end components: For the detectors, NRAO will provide the detectors and at least one level of video gain, with the interface voltages and impedences to be mutally detailed later. We suggest differential TTL for the phase switch control. 3- Timing: The GBT 1 PPS uses differential TTL, with pulse characteristics to be provided by NRAO. Additionally a 10 MHz sinusoid reference (0dBm, 50 ohms) derived from the site hydrogen maser is available in the receiver room if that is helpful. 4- Power Supplies: NRAO has +/- 15V and +5V supplies mounted on the turret that could provide power to the A/D and FPGA. This would avoid the size and weight of dedicated supplies, at the expense of slightly more power dissipation in the internal regulators (relative to the 12V supplies discussed in the technical proposal). 120V, 60Hz is available as well. Since it is shielded, a switching supply could be considered. Each electrical interface connector should be detailed between the technical teams later. 5- Control Interfaces & Software interfaces: to be determined mutually later. * We need self-test features. * There was some concern about the use of state-machine/one-shot approach for the phase switch demodulation. The main consequence of this seems to be to preclude slave mode which is ok, but we should be sure there aren't other, bad implications. * There are two or possibly three apparently unsynchronized clocks in the system. Unless great care is taken, there may be some race conditions. A system with one master clock that orchestrates events based on state machines running off that clock is a lot more deterministic and easier to debug. * Great care should be exercisied in properly isolating the analog electronics from the digital electronics. This includes such things power supplies, circuits design, board layout, grounding, etc. The proposal pays a bit of attention to this. The detailed design needs to address this very carefully. In addition, a lot of testing need to be done to verify that undesirable response are sufficiently small. * We do not normally turn off the receiver/backend control boards when they are not in use, and we should not plan on doing so in these cases. * The choice of a parallel interface for sending data to the RTC is sensible. However, we suggest you consider the possibility of buying a PC/104 interface card with the FPGA on it, and be done (eg http:www.associatedpro.com). The APS-240 Virtex is a PC/104 board with a xilinx FPGA built in for $600.00. The CPU board is a mere $600.00, and weighs only a pound or so. You could then use the PC/104 bus rather than the parallel port. The system would then have an analog section, with its A/D converters in a separate box. The analog section would be driven by an FPGA on a PC/104 card (either a custom card or an off-the-shelf one such as mentioned above), which would reside on the CPU module. The FPGA and CPU card would be housed in a shielded enclosure, and would have filtered connectors for the digital data streams, the control signals to the front end, and the power supply. Other data and control interactions with the RTC would be via a fiber optic Ethernet connection. * At Green Bank we have the software tools for development with Xilinx FPGA's, but not for Altera, so we suggest considering using this instead. The suggested PC/104 interface board would provide Xilinx. * We concur with the selection of PC104 or EBX form factor CPU's, depending on how big the digital logic board gets, and suggest Adstra. * We suggest a FLASH disk instead of a magnetic disk.