| No | Date | Time | Project Code | Observer | Support Scientist | Instrument | Bug, Etc. | Priority | Time Lost | Status | Description | Response | Scripts |
| 1 | 2005-04-02 | | AGBT05A_038_01 | Minter | Minter | LO1 | Problem | Urgent | | Closed | At the start of scans 12, 13, 14, and 16 there was an RPC connection error from the scan coordinator to the LO1. This caused the LO1 not to go into running. Furthermore, the LO1 wrote a FITS file that was a copy of the last valid LO1 FITS file. This is very dangerous since it makes this problem hard to notice. Also, frequency etc. information for these scans is lost since the wrong FITS file is being written. | LO1 is in the process of being ported to linux. Once this happens, we will watch out for RPC errors and deal with them as necessary. RichardPrestage | |
| 2 | 2005-04-02 | | AGBT05A_038_02 | Minter | Minter | Spectral Processor | Problem | Urgent | | Closed | The spectral processor fits file contains the wrong sky frequency for scans 13, 14, 15, and 16. The parameters used to derive this value for the fits file was not changed from scan 12 through scan 16. I don't know how this value was updated/changed in the spectral processor (and subsequently changed in its fits file)- it certainly wasn't requested. | A new keyword (MULTMODE) was added to the spectral processor fits file this past cycle to support Robishaw's work, but nothing was changed. The new keyword has nothing to do with determination of sky frequency. Other than this addition, there has been no work on the SP fits file for the past couple of years - so we really don't have anything to go on to pursue the solution. NMR I don't understand how this has anything to do with the problem? TM The value for the sky frequency in the SP fits files for these scans agrees with the equivalent value in the IF fits files. So, I think these values are correct and so this really boils down to why did the center frequency change during those scans. The change happens in scan 15. Previously (scan 12-14) the center sky value is 8.25*10^8 and after (scans 15,16) its 1.4655*10^9, so its a pretty substantial change. Was this pulsar data? There aren't any GO FITS files for the entire project directory (the GO directory is completely missing) which makes me curious. Also, it doesn't appear that there is a MULTMODE keyword in these fits files (perhaps these predate the release, these files actually date from March 8), so that has nothing to do with this. -Bob G | |
| 3 | 2005-04-02 | | GBT5A-032 | Greve | Minter | GFM | Problem | Important | | Closed | When using the query on accepting bad fits feature you have to answer whether or not you want to accept the fit or not before you are presented with the information on why the fit did not pass. This is just like me asking you to fix the bug with gfm and then I'll tell you what the bug is. | I am unable to reproduce this behavior for any of the scans in AGBT05A_032_05 offline. It shows the fit before presenting the dialog for me. However, I did find one minor thing that may have contributed what you saw although I'm not totally convinced that it should; in any case, this will be patched in as soon as I find a window in observing. AmyShelton | |
| 4 | 2005-04-02 | | GBT05A-032 | Greve | Minter | GFM | Enhancement | Important | | Closed | The observer wanted a paper copy of the plot within the gfm plotting scrren. There is no way to do this from within gfm. | You can do this via File->Export. Save the image and then print it via lpr. A request to have a print option is already on the GFM request page. AmyShelton | |
| 5 | 2005-04-04 | 19:45 | GBT05A_007_02 | Widicus | O'Neil | Other | Problem | Important | 00:10 | Closed | The Focus rates on the PTCS page seem to be about 2x too fast for Ka-band. Running with the published rates the data was very poor. I then slowed things down by a factor of two and got a perfect curve. | My previous response was incorrect. I now think this was a problem with the subreflector after the power outage (April 3rd to 7th). see FocusProblemApril2005 for details. RichardPrestage | |
| 6 | 2005-04-06 | | GBT04C_021_02 | Wang | Langston | GO_LITE | Problem | Desired | | Closed | Setup was smooth, except that at some point during the setup, it appeared that another observer ran GO_LITE. The symptoms were that the setup reverted to the previous observers setup. After we re-configured all appeared to be OK. | | |
| 7 | 2005--04-16 | 08:30 | AGBT05A_032_08 | O'Neil | O'Neil | Converter Modules/Rack | Problem | Urgent | 00:05 | Submitted | The power from the optical driver 2 was extremely low. We had to switch to using optical driver 1. Note that this was done at K-band. the configuration script is attached. | I set up for the 3 GHz noise source and noticed the ODM of channel #2 has about 6 dB less gain than the ODM of channel #1. This just happens to be an ODM with two milliwave amplifiers that have less gain. The K band receiver probably had lower gain in this channel coupled with the lower gain of the ODM resulting in marginal power for a balance. Main.StevenWhite | GBT5A32_config_J16359.py |
| 8 | 2005-04-19 | | AGBT03C_033 | Maddalena | Maddalena | Antenna/Antenna Manager | Problem | Important | | CCC Approved | I'm seeing a constant 4 arcsec difference between the command and indicated RA, Az, etc. The commanded is also off by this amount from what is in the primary segments while indicated, except for servo jitter, is exactly what is being put into the primary segments. Explanation? | This is a bug which does not effect proper operation. The commanded field is generated asynchronously from the indicated fields, yet sampled synchronously. This ocassionaly causes the commanded field to be incorrectly displayed. This does not effect proper operation, because the displayed value is not part of the actual command path. | |
| 9 | 2004-04-23 | | TAP_RCO_L_01 | Minter | Minter | Config_tool | Human Error | Other | | Closed | I tried to use the following configuration (within astrid) to setup four inputs into the DCR for a continuum observation. I got errors of: Configuring telescope. Error: length of if3freq must be same length as nwin(= 2 ) Please fix configuration, then try again This should have been legal as far as I can tell. Configure(""" receiver = 'Rcvr1_2' obstype = 'Continuum' backend = 'DCR' nwin = 1 restfreq = 1375,1375 deltafreq = 0,0 bandwidth = 80 swmode = 'tp' swtype = 'none' swper = 0.2 swfreq = 0.0 tint = 0.2 vlow = 0.0 vhigh = 0.0 vframe = 'topo' vdef ='Radio' noisecal = 'lo' pol = 'Linear' """) | This configuration is illegal because you have 2 rest frequencies (1375 and 1375) but are only using 1 window. Either change the number of windows to 2, or remove one of the entries for restfreq and also 1 for delta freq. MelindaMello | |
| 10 | 2004-04-24 | | BK114C | Kandracto | Minter | Antenna/Antenna Manager | Problem | Urgent | 00:12 | Closed | The Antenna stayed in running at the end of a scan (as if it did not get the signal to end the scan). We had to make several attempts to stop/abort (in the scan coordinator) before the antenna then stopped the scan. This caused 13 scans of this VLBI run to be missed!!!!! | According to the antenna logs, the antenna system indeed did stop at the correct time, but the event apparently did not get propagated to the rest of the system. The cause of this is currently unknown. | |
| 11 | 2004-04-26 | | TAPI_RCO_L_02 | Minter | Minter | Other | Enhancement | Important | | Closed | IR Rack channel 5's V/F was found to be bad. There is no place in the software to declare a component of a device bad so that setups from the config tool can avoid the bad component. | Moved request to ObservingToolsRequests. AmyShelton | |
| 12 | 2005-05-01 | | ABN031_01 | Nakashima | Minter | Astrid | Problem | Important | | Rejected | The operators "hung up" astrid twice. This happened when they minimized the "open" window while trying to import a scheduling block. The minimized "open" window does not show up on the task bar in another level and would make astrid appear to be hung up. To recover you have to use the middle mouse button on the backgroud to get a list of all windows - from which you can get back the open window. The open window in astrid needs to show up on the task bar when minized. | See response to #28 at AstridReports. Moved to there. (RichardPrestage) | |