NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > PlanOfRecordC82003 > ModificationRequest9C803

Changes | Index | Contents | Search | Statistics | Go

Data Quality Tests/Dashboard (Part 1: System Quality)

Modification Request #9 (C8 2003)

1. Introduction

Prior to the start of a live astronomical observation, it is important to ensure that the hardware and software systems are in good shape, and that the output data is of sufficient quality, to prevent losses of observation time. As of September 2003, this is a high overhead activity that we estimate would take up to an hour. The intent of development based on this MR is to automate simple hardware and software checks to at least accommodate the "short test" described below.

The vision is to eventually present to the observer a graphical display of how healthy the hardware and software is at the time of an observation, which will then be used by software programs like the configuration tool, along with an assessment of the quality of the output data. This will help to minimize the amount of observing time which is not optimally productive due to subtle system and data problems.

2. Background

(Background provided by KarenONeil on 9/29/03)

Proposed hardware for post maintenance

These could be combined with the software tests being designed to run at any one of three levels:

1. Full test: Run the full software test in addition to the hardware test described below. This would require approximately 60 minutes and requires antenna control for part of the test.
2. Mid-range test: Run all parts of the software tests except the parts that require telescope control, and run the hardware test. This would require approximately 45 minutes and no antenna control.
3. Short test: Run the hardware test and one or two software probes, as described below. This will be designed to require about 5 minutes of telescope time and would not require antenna control.

Short test description:

The goal of this would be to test the entire IF/LO chain & all standard GBT backends (spectrometer, spectral processor, and DCR). Additionally, two software probes would be done. In this way we should be able to guarantee that at least all cabling is in place, all backends are accessible, the correct M&C version is being run, and the antenna is no longer in simulator mode.

All results for the test should be both printed on a screen and sent to a file. The file and printout should also include information such as the IF/LO path used during the testing. Any cases where the measured values fall outside their exceeded range and/or an IF path cannot be followed that is determined to be legitimate according to the cabling file should send a big message to the operator, as well as record that message in a file.

The test would following along the following lines:

1. Set the IF/LO path to use the spectrometer. Run through each available receiver and take a 5s on + off observation of the cal

1. Set up the IF/LO and spectrometer to use all banks and all possible IF paths. Then again set the center frequency to the center of the receiver band and fire the cal. All results should be compared against each other and should agree to within some pre-determined percentage or a message will be sent to the operator.
2. Using the same receiver as above, send the signal down to the other GBT backends, testing all banks (when applicable). Compare the results to those of the last test. Again they should agree to within some pre-determined percentages or a message will be sent to the operator.
3. Finally, run a quick test in (1) insure that the antenna is no longer in simulation mode and (2) to record the M&C system in use.

Potential gotchas:

1. If the test is unable to send a signal down a path, because a receiver or cable is missing, it needs to be smart enough to simply send a message stating what it cannot do, and then continue. This would allow the operator to determine whether it is that one receiver is missing, one cable, or if the whole system has gone kablooey.
2. The operator (or whomever runs this program) should be able to tell the program to use the spectral processor, or even the DCR, as the primary backend in the case where the spectrometer is out for service.
3. The multi-bank, all IF test would most easily be done with the K-band or Q-band receivers. However, it may be more useful to run this using whichever receiver is actually pointed at the sky, since that will likely give more honest Tsys measurements. (Of course, it very possible that the system temperature measurements when pointing at the inside of the receiver room more stable than when pointed at sky. This would be looked into.)

Total time needed:

• Test of all receivers: 80s
• Test of all 16 IF paths: 10s
• Test of all backends: 20s
• This should be able to be reduced within essentially real-time so total time for data reduction, printing messages, etc. should be under 5 minutes

3. Design Approach

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.

Status

-- NicoleRadziwill - 02 Oct 2003