2016 November
Nov 04
19:18 UT Reboot ROACHes to clear fault light and test whether large delays are still present. They were power-cycled and reloaded.
19:24 UT Started roachcal.scd to take packet capture data for checking delays. Still bad!
Nov 05
03:41 UT Found a potential problem in DELAYCAL_END.ctl, so took another two sets of roachcal.scd data. Still bad!
04:14 UT Started roachcal.scd for another set of data. After studying schedule.py, another problem was found. DELAYCAL_END command has to have CIEL-2 as second value on the line, otherwise source id is set to None! Yay! It finally worked!
Nov 09
01:08 UT Set up the schedule to do a long run on 3C84 with the low-frequency receiver, using pcal_lo.fsq (all bands 2.5-6 GHz). One major change is that the PA can be set, so I set it for -30. I would predict that the chi-dependence will shift by 30 degrees (the phase jump will occur at a different hour angle), but the non-intersecting axes issue will cause the same symmetric phase rotation (it depends on elevation only).
04:20 UT 3C84 schedule begins.
12:00 UT 3C84 schedule ends.
Nov 10
03:00 UT Note, the above observations showed no coherence, for reasons unknown. The receiver will be checked for pointing and focus using a total power source. I attempted to observe the Moon at the current time, but it happens to be at -6 Declination, so it is in the geosynchronous satellite belt and could not be peaked up in total power. I will observe Cyg A when it rises at ~ 21:20 UT today.
22:00 UT Began some Cyg A drift scans. Original Z offset was 200, and I could not see any increment on Cyg A, but changing to 50 gave a clear response.
22:20 UT Nominal peak of a drift scan (well seen on baseline 11-14) is 22:20 UT, but it actually occurred at 22:19:55 UT, so original RA offset is right: 0.15 degrees. Also did a Dec drift scan that peaks at 22:46:00 UT, which verifies the DEC offset is also right: 1.03 degrees.
22:49 UT Did a focus scan. This is the time when the focus was best, which corresponds to a focus (Z-axis) setting of 30 on the Lo receiver. Higher settings were significantly worse, so that by a Z-axis setting of 200 the amplitude is going to zero. This explains the lack of phase coherence on the 3C84 run of yesterday.
Nov 13
05:42 UT Attempting to see the Moon with 27-m Hi receiver. I could see nothing at nominal position, but then I got a whopping signal at about 2 degrees RA offset. This might reflect a very wrong X axis position.
05:54 UT Moved X axis setting to 500, and I do get a very high increment at nominal pointing. Best LO Receiver settings X-axis 100, Z-axis 30; Best HI Receiver settings X-axis 500 Y-axis 0.
06:25 UT Began 3C84 observations using HI receiver, with starburst_hi.fsq sequence. Given the much higher signal strength on the Moon, the sensitivity should be very good on 3C84.
06:35 UT Decided to switch to pcal.fsq sequence. This should provide better SNR. Yes! The data look very nice, see Fig. 1 at right.
14:25 UT Going to 3C273, for some PA tests. Oops--used the wrong frequency sequence--was pcal_lo.fsq
14:31 UT Now setting to pcal.fsq
14:37 UT Moved PA position to -35 degrees, which is the current parallactic angle (I will test this and +35 to check the sign).
14:42 UT Began move to PA +35 degrees. I should see a dramatic change in XX and YY amplitudes when feeds are parallel.
15:06 UT Went to PA +29 degrees. Looking at the data, it appears that we need to apply -chi to the PA axis to make the feeds parallel.
15:30 UT Went to PA +23 degrees (tracking chi variation). I did some analysis that verifies -chi is the correct term to apply. See Fig. 2.
15:48 UT Went to PA +15 degrees (a bit ahead of correct -chi, which is +18 at this moment).
16:10 UT Went to PA +10 degrees.
17:51 UT Went to PA -21 degrees. Obviously a lot of rotation between these two... I have continued to make a couple of adjustments at different times--can get this from the stateframe if I need the exact times...
Nov 15
21:51 UT Finished developing a $PA-TRACK command for the schedule, which resulting in many-many restarts of the schedule, so there will be a lot of short solar scans at times before 21:51 UT.
23:30 UT As usual, wind was manageable all day until I wanted to use the 27-m on a calibrator to test the PA rotation. Now the wind is up, and it will probably only get worse. I will stop the observations of 2253+161, which only just started, and go back to it if I can, later. If not, I'll do 3C84 overnight.
Nov 16
00:06 UT I did get back to the source at about 23:45 UT, and so far it is tracking and the wind may be declining. The frequency sequence is band14.fsq.
03:45 UT The data for source 2253+161 are done--very successful observation. There is some clear variation in amplitude that could easily be pointing issues, perhaps with Ant 14. At 03:45 UT I started a 3C84 observation, but then realized that I did not want pcal.fsq, but rather, want to use band14.fsq as I did for 2253+161.
03:55 UT Correct observations on 3C84 begin. These should be interesting due to the large parallactic angle changes, including going past 90 and -90. I am tracking the angle using $PA-TRACK ant1, so we will see how it goes.
12:41 UT The 3C84 observation is done, but there were some glitches. As far as I can tell, the observations went normally until around the time of the discontinuity at HA = 0, then either the PA_adjust() process died, or the Ant14 control program died. In any case, the PA was stuck at -32 degrees after that point. There were other glitches, from time to time, where the Chi value was set to 0, and no doubt this was exacerbated by the schedule lagging badly. I need to find the cause of that.
14:28 UT I was observing 3C273 from about 13:00 UT, but tracking PA for ant14. I realized that the calculation of Chi was wrong for the equatorially mounted dishes, so that whole time the data are taken with the wrong PA. I have updated the stateframe.py code to correct it, and have started a new observation tracking Ant14's Chi value. This one should be okay.
18:51 UT The wind suddenly came up, so the 3C273 observations have ended. The PA rotation seems to have gone without a glitch since 14:28 UT!
22:49 UT I just started a series of observations on sources 2136+006 and 2253+161, alternating between the two, which should continue for about 4 hours. This is to test Jim's change to dppxmp, which is supposed to automatically correct the offset-axes issue. I'll be checking if it has the wrong sign, and update it if so. Argh. WINDSCRAM. --Anyway, Jim's code has a bug--
Nov 17
13:03 UT I started a schedule to test Jim's latest dppxmp. It is cycling among sources 1229+020 (3C273), 1256-057 (3C279), and 1331+305 (3C286), tracking PA, using band14.fsq.
17:18 UT Observations continuing. We are now past the meridian, and the results look good. I think we have the right sign of the correction, but I will want to get some observations on 3C84 before I am entirely convinced.
20:48 UT The observations are coming to an end at 21:55 UT. They went very well, although I notice that the scan starting 20:35 UT ran into a limit on Ant14 as the source set. The last few minutes of that scan will be bad data.
Nov 18
04:00 UT Updated some of the baselines for today's measurements, and now starting an observation on 3C84. This is also using band14.fsq, and rotating the PA on ant14.
12:28 UT Looks like the Ant14 control system stopped sometime shortly after 06:38 UT, which froze the FRM at PA -62. The dish was also pointing in a strange place, so it may also have stopped, but if so it was some time later. The data-taking continued to 11:45 UT, as planned.
14:01 UT Started another run on multiple sources (1229+020, 1256-057, and 1331+305), but with the same baseline setting as for 3C84. I am analyzing the 3C84 scans to update ants 9, 10, 11 and 13.
16:05 UT I updated the baselines on ants 9, 10, 11 and 13, which were way off due to my changes to Ant 14, but also had their own adjustments needed. Hopefully they are better, if I got all the signs right. I have restarted the schedule to implement the changes, and also changed the schedule to eliminate the measurements on 1256-057. The results were precisely the same as for 1229+020, and it was in the GEOSAT belt, so had other problems. Now I am doing 20-min scans alternating between 1229+020 and 1331+305, using pcal.fsq.
16:46 UT After looking at the previous data, I decided the SNR is not high enough, so I restarted using band14.fsq instead. Still tracking PA.
17:05 UT Doh! After seeing no phase coherence with band14.fsq, I noticed that Ant14's radecoff was zero. This happened when I rebooted the Ant14 controller this morning to clear a "permit" alarm. I have reset the offsets to radecoff 0.15 1.03, where they are supposed to be. This should make a bit of a difference! (understatement) --Whew, a check of the data now shows good phase coherence.
18:39 UT Windscram occurred, and the wind is likely to remain high, so observations have ended and I started solar observing.
Nov 19
03:45 UT New observation of 3C84 begins. For this, I am switching from tracking PA to not tracking PA every 10 minutes. Using band14.fsq.
13:50 UT Updated baseline corrections based on latest 3C84 observations (which indicated that I had the wrong sign for my previous update!), so now I am doing a check of these corrections. Starting observations of 1229+020 and 1331+305, with band14.fsq, alternating every 20 minutes. Assuming the Bx and By corrections are okay, these observations should be suitable to some sort of estimate of Bz.
18:35 UT Observations have ended due to windscram.
23:35 UT Started a new observation of 2136+006 and 2253+161 (two_src.scd) using a new frequency sequence called 3bands.fsq (does bands 12, 14 and 16). The data look great, so this is certainly a viable observing mode for a wider frequency range, but due to a transcribing error in the schedule, the observations failed to change sources correctly. This is now corrected, but of course the wind is back and none of the subsequent scans are good. Also, ant11 is acting up, and so is not tracking.
Nov 20
00:40 UT Yesterday's data on 1229+020 and 1331+305 are good. I spent the afternoon looking at the results, but they are rather ambiguous, because their variations do not really match any expected variation. What is interesting is that they all match each other, which suggests that the variations are due to Ant14, either due to a residual baseline error or some other cause. I am giving up on the two_src.scd.