| No | Date | Time | Project Code | Observer | Support Scientist | Instrument | Bug, Etc. | Priority | Time Lost | Status | Description | Response | Scripts |
|---|
| 1 | 2005-0504 | 21:00 | AGBT05A_017 | Hainline | Ghigo | Rcvr26_40 | Problem | Urgent | | Closed | The auto LO power setting in the LO1 manager was a little too low. Often the LO power for the KA receiver was down to 4.90 to 4.95. The recommendation (I think) is to stay in the range 5.0-5.1. So the auto LO setting should be increased a little. | Testing shows about a 1 dB difference between LO1A and LO1B when both are set to 14666.7 MHz at +7.0 dBm. LO1A set to 7.0 dBm at 14666.7 MHz gives 5.0-5.05 volts on the LO level sampler, so the config file was not changed. -GW | |
| 2 | 2005-05-10 | 18:00 | AGBT02A_066_07 | Wagg | Balser | Rcvr18_26 | Problem | Important | | Assigned | Jeff Wagg has observed an intermittent 50 MHz ripple in his K-band data. His observing mode consists of total power NODs using both the upper and lower sections of K-band with the ACS at BW=800 MHz, two spectral windows, two polarizations. The ripple is observed in both the upper and lower K-band bands at different frequencies but thus far only with either feeds 2 and 4 for LCP (i.e., L2 and L4). Here are the signal paths:
L2 -> ODM 5 -> ACS Banks C,D
L4 -> ODM 5 -> ACS Banks A,B
The ripple does not appear to be a result of steps in the ACF. We see the ripple in different samplers and different feeds. The ODM appears to be the device in common. | The problem seems to be associated with the use of ODM5/OR5. Any observers who see a ~53MHz ripple in spectral baselines when using ODM5 should try ODM6 instead, until we can identify and correct the cause. -RDN 16May05
No real progress in isolating the cause. ODM5 was swapped with a spare, but that's basically a shot in the dark. Appreciate any user feedback. -RDN 26May05 | |
| 3 | 2005-05-14 | | | Baker | Minter | Other | Problem | Urgent | | Closed | This is passed on from the observer:
sdfits does not give a reasonable error message when a non-existant project id is given to it as an arguement in the online mode. | Added to SdfitsRequests. AmyShelton | |
| 4 | 2005-05-22 | 15:30 | AGBT05A_030_01 | Bania | Balser | Spectrometer | Problem | Important | | Closed | Spikes in the ACF of Spectrometer data that cause a strong ringing in the spectra. The spikes are not like the ACF steps, they are typically in a single lag, they are intermittent, the are both positive and negative, and they mostly appear in Banks C and D for our configuration (4 banks, 4 samplers per bank, 50 MHz BW).
Additional information was sent to the digital group. | This is a known problem, and we hoping it will be solved by new LTA cards. The last time it was reported, we swapped LTA's around and made it go away, at least for a bit. | |
| 5 | 2005-05-30 | 22:00 | AGBT05B_052 | Jacoby | Maddalena | IF Rack | Problem | Desired | 00:20 | Submitted | After the configuraton was done, we found about 20 minutes later that all four of the laser diodes the observers were trying to use had been turned off. It's clear that config-tool had turned them on (The IF Manager reported proper paths and center frequqncies) and that something else turned them off at some point. We first had to 'discover' the problem, fix it, and then redo all the spigot power level setups. | | |
| 6 | 2005-05-30 | 22:00 | AGBT05B_052 | Jacoby | Maddalena | Spigot | Problem | Important | 00:30 | Submitted | The obsrevers tried Scott's python scripts a few times but each time the scripts would hang. Observers went back to using the long-hand form of the commands. The lost time is my estimate of the time they spent trying the scripts and the time lost to using the old commands. | | |
| 7 | 2005-05-30 | 22:00 | AGBT05B_052 | Jacoby | Maddalena | Config_tool | Problem | Important | 00:10 | Submitted | Config-tool complained that it couldn't set up a proper path due to a bad device (in particular CM4 and 8). Yet, I couldn't find any entries for the devices in the dev-health files. Nor did the observer have a copy of a dev_health file in their account or directory. I had to fix up by hand the misset switches and synthesizers in the converter modules (CM3 and 7 were also bad) and their corresponding analog filters. Since the observers were running config-tool remotely, it was hard for me to tell exactly the problem and messages config-tool generated. | | |
| 8 | 2005-05-30 | 22:00 | AGBT05B_052 | Jacoby | Maddalena | Computer | Problem | Important | 00:15 | Closed | The observer's remote Linux machine wouldn't bring up either CLEO or GO, yet the machine could bring up remote xclocks, xemacs, etc. yet, when the went to another Linux machine, they were able to bring up CLEO and GO. It appears that our Linux machines will not accept some types of X-Window requests from remote machines that are running some versions of Linux but will accept the same requests from other versions. Lost time was from observers having to switch their remote machines. | This is likely due to a 'known' issue that I have seen on RHE4 and Fedora based systems. For reasons I can't recall, one must add a -Y to the ssh command when logging in. (e.g ssh -X -Y host)
| |
| 9 | 2005-05-30 | 22:00 | AGBT05B_052 | Jacoby | Maddalena | Computer | Problem | Important | 00:15 | Submitted | At one point, the remote obsrever's connection to Green Bank went down and all attempts to connect over the next five minutes failed. After that, the observers were able to log in but then had to restart all of their applications. The lost time was the time it took for the connection to be re-established and for the obsrevers to restart their applications.
The observers also weren't aware of VNC and the advantage they wouold have had if they were using it. We need to better advertize VNC to our remote users. Maybe embed a link to the instructions in the Astrid/GO/config-tool/Spigot instructions?
| | |
| 10 | 2005-05-31 | | many | many | Minter | IF Rack | Problem | Urgent | | On Hold | The IF Rack is always indicating that its state is "warning" but there is never an error message indicating what is wrong. Everything seems to be OK when looking at levels, signal paths and data. Several observers have commented on this being anoying. | It is very likely that the message associated with the "Warning" status is a false indication that the first "child" Manager (in this case OpticalDriver1) is failing to connect to the IFManager. We have often seen this message generated for the first child for a number of devices (ConverterRack, AnalogFilerRack, and IFRack) since they have been ported from VxWorks to Linux. See release notes. Why it occurs, why the message is false, and why the message clears but the status
remains is not understood. It may be an artifact of when all the devices are brought up together as after a version change, restarting just the single device via TaskMaster has cleared it in the past. This item requires a large effort and needs to be addressed during cycle planning.
MarkClark | |
| 11 | 2005-05-31 | 8:00 | GBT05A_042 | Andrew Baker | Minter | Converter Modules/Rack | Problem | Urgent | | Closed | The converter rack would change its attenuation during a scan without it being commanded to do so. This caused the collection of invalid data as things got out of balance for the spectrometer.
We noticed that the change in attenuation happened at even time intervals. This seemed to indicate that maybe one of the pulsar folks had left one of the spigot scripts running that automattically tries to balance the spigot. We did not find anything specific. The operator then killed all pulsar observer processes on titania and the problem went away. | The supposition is exactly correct, when running the spectrometer in spigot mode a Python script called holdInputLevel is often run which every 10 seconds adjusts the attenuators in the ConverterRack attempting to maintain a constant input level. Since this is an user-initiated program and part of the spigot battery of programs, it would seem to be out-of-scope for SDD.
MarkClark | |