NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > ParControlSwDev > ParMgrV2 > MasterMustangManagerMr > ModificationRequest14C507

Changes | Index | Contents | Search | Statistics | Go

MUSTANG Manager - Tower Control

Modification Request 14 (C5 2007)

• 1. Introduction
• 2. Background
  • 2.1 DAC Cards
  • 2.2 Address Card
• 3. Requirements
  • 3.1 Requirements for DAC card (bias, feedback and preamp) control
  • 3.2 Requirements for address card control
• 4. Design
• 5. Deployment Checklist
• 6. Test Plan
  • 6.1 Internal Testing
    • 6.1.1 Unit Tests
    • 6.1.2 Simulator Tests
    • 6.1.3 Tests using Spider
  • 6.2 Sponsor Testing
  • 6.3 Integration/Regression Tests
• Signatures
• CCC Discussion Area

1. Introduction

MUSTANG has an 8 by 8 planar array of Transition Edge Sensor (TES) Bolometers for detectors. The array is used without feedhorns and it is read out with time based SQUID multiplexing electronics. High density polyethylene lenses and capacitive mesh filters are used to focus light onto the detectors, define our 86 to 94GHz bandpass, and control the illumination of the telescope.

MUSTANG is currently controlled and read out using NASA's freely available, Java-based Instrument Remote Control (IRC) system. This system has served admirably during early testing and commissioning of the instrument, but for long-term operations we would like to replace it with software written in-house. The primary reason for this is that, generally, IRC duplicates the functionality of the Ygor monitor and control system. The maintenance and upkeep of this separate monitor and control system entails significant work, which we can greatly reduce with an up-front effort to port the specific DAQ and control capabilities to our M&C system.

The goal of this MR is address all issues that deal solely with the cards found in the Tower. This mainly entails how the manager should be able to command the Tower cards. All higher level issues that entail the Tower cards interacting with the larger system (e.g., the DFBs) will covered elsewhere.

2. Background

Formerly known as the Penn array, MUSTANG is a focal plane array designed for the 100 m diameter Green Bank telescope.

This MR has been initialized based off discussion and requirements found at MasterMustangManagerMr.

The below discussion uses terminology in common with Brain Mason's introduction to MUSTANG.

The low-level interface to the tower cards is described in this document by Simon Dicker and Matt Cohen and this document by Melinda

The tower contains 4 different types of cards: three types of DAC cards {bias, feedback, and preamp}, and one address card.

2.1 DAC Cards

From the software point of view, the bias, feedback, and preamp cards have identical interfaces (in fact, the bias and feedback cards are identical hardware wise and differ only in how they are used; and the preamp card differs only in having an extra op-amp or something on the circuit board). Each DAC card contains 8 commandable digital-to-analog converters (DAC). The bias and feedback cards are used to set the bias and feedback values for the series array and second-stage squid (SQ2) for each column. (Sometimes the DAC cards per se are referred to as "Bias cards" but I think we should strive to avoid this ambiguous terminology). The preamp card sets the detector bias for each column. In all of this, each of the 8 commandable DAC channels of a given card acts on a single column. Thus, for the feedback card dedicated to providing SQ2 feedback, that card controls the SQ2 feedbacks for all 8 columns.

For all DAC cards, there is only one variable that can be commanded, the 'voltage' used in the above descriptions.

2.2 Address Card

The address card controls the row switching, which happens very rapidly and is identical for each column. The row switching is simply setting the biases for the first stage squids; this is done in synchrony with setting the first stage feedbacks, which is done by the Digital Feedback (DFB) cards, again, very rapidly. The value of this bias is controlled by the parameter "Vref". There is a lookup table which, together with LUT_start and LUT_delta, defines the order in which rows are turned on and off.

As noted above all of the following parameters are common to both the tower and the DFBs: LUSTART, LUTDELTA, NSTEP, and the actual LUT itself.

Comment on the LUT: the DFB only supports a 32-entry LUT. The user interface to the manager as such should also be a 32-entry LUT. The tower itself expects a 64-entry LUT; the contents of entries 32...63 of this table are irrelevant. In principle it doesn't matter what the top 32 entries of the address card LUT contain (a duplicate of the first 32, all zeros, or whatever) but it should be well-defined.

Unlike the DAC cards, there are several variables that can be commanded.

3. Requirements

This requirements cover only those issues that address solely the Tower cards. More complicated issues that involve interaction with other parts of the system (eg, the DFBs) are addressed elsewhere.

3.1 Requirements for DAC card (bias, feedback and preamp) control

• The names of the 5 cards must be: SABias, SAFeedBack, SQ2Bias, SQ2FeedBack, DetBias. The last is the preamp card, the others are bias and feedback cards.
• The association between card name and address (eg, which card is the SQ2Bias card) must be specified in a configuration file (these will rarely change).
• The user must be able to specify the units of the DAC voltage in counts with a range of 0 to 2^16-1 integer.
• The user must be able to change these DAC voltage for a single channel of a single card (Note: higher level functionality will be needed to support the types of activities described here in the Meta-MR))
• The association of a given cards' channels with columns must be specified in a configuration file (will very rarely change, if ever).
• The names and structure of the manager parameters must reflect their use and column numbers (eg, SABiasCol1..8 or SABiasCol[1..8])

• All of the bias, feedback, and preamp cards' individual channels must have individually settable, easily changeable (e.g. in the config file) default values. Thus Sq2bias channel 1 and Sq2bias channel 3 should be able to have different default values, which in turn are different from the default values for SABias ch2 etc.
• It must be possible to revert to the default values easily on the telescope

3.2 Requirements for address card control

• The address card has an address which will be specified in a config file
• There must be a single integer manager parameter (0...16383, 0...2^16-1), named Vref.
• There must be two integer manager parameters (0..31) named lutStart and lutDelta. (Note: that there are identical parameters for the DFB cards, and these should not be completely independent, but higher level parameters may also be needed for users to set both Address and DFB card params at the same time (see the Meta MR. This should be addressed in a separate MR)).
• There must be a single manager parameter enableAddressDriver, that is a boolean for enabling and disabling the address driver.
• There must be an integer parameter nstep with legal values 0-63
• There must be a 32-entry look-up table (named lut). Each entry of the LUT has legal values of 0-31, so this should be a simple 32-element array. However, the address card has 64 entries: the first 32 must be populated with the parameter's values, and the second half must be set to zero.
• There must be an enable switching parameter, startEnable, which is a boolean for on and off.
• The following default parameter values must be used:
  • lutStart = 0
  • lutDelta = 1
  • nstep = 8

4. Design

See the master MUSTANG design page.

5. Deployment Checklist

What has to get done to integrate this completely into the system. This checklist must be completed before Cycle Integration Testing begins.

• Communication with Computing group needed?
• What documentation needs to be updated?
• Training Needed? Is this being released to staff astronomers or everyone right now?
• Notification Needed?

6. Test Plan

Critical!! ChangeControlCommittee will be reviewing these. Please send a link to this MR to RonMaddalena along with a suggestion for two reviewers when it is ready for CCC review.

Don't forget to include/acquire any additional GBT test time needed outside integration/regression testing! Get your requests in early!

Important! If possible, you should conduct as many of your tests as possible in offline modes and/or with a simulator. We should constantly endeavor to minimize our use of telescope time for testing!

6.1 Internal Testing

This section covers things like unit testing, simulator testing, and any other tests required to make sure this MR is ready for sponsor/integration/regression testing.

6.1.1 Unit Tests

• Unit Tests added for Ygor serial port library
• Unit Tests for Tower added:
  • test commands for proper bit twiddling
  • test serial port usage via '/dev/tty'
• Unit Tests for Manager parameters

6.1.2 Simulator Tests

• Tests with the Ygor Manager running in the simulation environment should be done; This way we will be able to verify again the code from the Manager parameters down to the bytes being written to the serial port. What bytes are being written to the serial port can be tested simply by viewing the manager's output when in 'debug' mode.
• We have agreed not to bother with a tower simulator.

6.1.3 Tests using Spider

The current plan is to run the manager either through a VNC session or actually go to UPenn to perform Ygor manager testing on spider. Since there is no tower hardware available here at Green Bank, it is critical that we coordinate with UPenn for test time using their complete system to test the functionality of this MR. Actual tests to be performed are TBD.

6.2 Sponsor Testing

Test 1: bring up IRC strip charts. For each SQUID bias in each column (SA, SQ2 FB and bias), change its value. The strip chart for the given column should change.

Test 2: re-enter a full tuning previously determined with IRC. Check the stripcharts.

Test 3: program a permuted LUT (7,8,6,5,4,3,2,1,0) and normal LUTSTART, LUTSTOP. fully tune and configure with cal on, collect data, verify that physical rows are in the expected places. Repeat with LUTSTEP=2

Test 4: start and stop muxing with the manager (address card, enable switching). the strip charts should split up and merge as you do.

6.3 Integration/Regression Tests

What do the integration/regression testers need to do in order to test this MR.

Signatures

APPROVED: I acknowledge that my request is fully contained in this MR, and if the SDD delivers exactly what I specified, I will be happy.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.

Written	- PaulMarganian - 08 Aug 2007
Checked	- MelindaMello - 30 Aug 2007
Approved by Sponsor	Brian Mason, 12aug07
Approved by CCC	- AmyShelton - 31 Oct 2007
Accepted/Delivered by Sponsor	BrianMason 02apr08

Symbols:

• Use %X% if MR is not complete (will display )
• Use %Y% if MR is complete (will display )

CCC Discussion Area