Difference between revisions of "2017 March"

From EOVSA Wiki
Jump to: navigation, search
(Mar 07)
(Mar 07)
Line 11: Line 11:
 
'''13:30 UT''' Huge news! The 300 MHz correlator is working.  The only known glitch is an off-by-one-slot error for the correlated data, which Jack is working on.  Meanwhile, I took data all night on 3C273 and 3C286 using the new/complete science-channel definitions.  The data recorded okay, and the science channels are good.  However, we had no phase coherence. I discovered that the clock rate was set to 0.8 (GHz) in DPPparameters.f90.  I have changed to 1.2, and am taking new data on 3C286 (the stronger 3C273 has set...).
 
'''13:30 UT''' Huge news! The 300 MHz correlator is working.  The only known glitch is an off-by-one-slot error for the correlated data, which Jack is working on.  Meanwhile, I took data all night on 3C273 and 3C286 using the new/complete science-channel definitions.  The data recorded okay, and the science channels are good.  However, we had no phase coherence. I discovered that the clock rate was set to 0.8 (GHz) in DPPparameters.f90.  I have changed to 1.2, and am taking new data on 3C286 (the stronger 3C273 has set...).
  
= Mar 07 =
+
= Mar 06 =
 
'''15:00 UT''' I am back to the 200 MHz correlator, and will take some calibration (two-src) observations on 2136+006 and 2253+161, using 3bands.fsq.  The scan started at 15:00 UT, but in fact with the new HA limits the source is not reachable yet.  Should be reachable by the next file, at 15:10 UT.
 
'''15:00 UT''' I am back to the 200 MHz correlator, and will take some calibration (two-src) observations on 2136+006 and 2253+161, using 3bands.fsq.  The scan started at 15:00 UT, but in fact with the new HA limits the source is not reachable yet.  Should be reachable by the next file, at 15:10 UT.
  
Line 19: Line 19:
  
 
'''19:07 UT''' I verified that delay_widget used the wrong sign of Y-X delays, so I fixed that and did one more test.  The results are great!  Just because I am paranoid, I am doing one last test after a very minor update in the delays.  Then I will move on to test Jack's latest compile of the 300 MHz correlator.
 
'''19:07 UT''' I verified that delay_widget used the wrong sign of Y-X delays, so I fixed that and did one more test.  The results are great!  Just because I am paranoid, I am doing one last test after a very minor update in the delays.  Then I will move on to test Jack's latest compile of the 300 MHz correlator.
 +
 +
= Mar 07 =
 +
'''01:32 UT''' '''The 300 MHz correlator appears to be fully working!'''  I have been working with dppxmp all afternoon to solve the phase wind issues, and I believe I have finally solved it.  With an 800 MHz clock, our 600-1200 MHz IF was in the third nyquist zone, so the order of channels was forward (low subchannels -> low frequency, etc.).  Now with our 1200 MHz clock, the IF is in the second nyquist zone, so the order is reversed.  I understood that, and adjusted chan_util_bc.py to write the channel assignments in the inverted order.  However, that still did not solve the phase wind.  Thinking further, I finally realized that the sign of the phase correction should also reverse.  I applied that sign reversal, and now some 3C84 data I just took may be right.  Oddly, though, it is only good on baseline 8-14, which is a problem I noted last month, which was only corrected by rebooting the ROACHes.  I will do that now...

Revision as of 01:38, 7 March 2017

Mar 02

03:05 UT The 27-m is back in service, so I am grabbing a quick 3C84 observation to check, and possibly adjust, the delays. I will plan to do a two-source observation (3C273 and 3C286) overnight, using 3bands.fsq.

03:50 UT I got good delays and set them, so now I will take a few minutes of 3C84 data as a further test with them applied. The HA on the big dish is now 49.5 degrees, and the HA limit is set to 50 degrees so that the cable alarm does not get set again by going too far. So I should see the dish hit the soft limit in a few minutes. Yep, right on schedule.

04:06 UT I have verified the delays are good (except ant 4 is still showing a lot of noise, so no delay solution). I have now set up my two-source observation to start at 07:00 UT.

10:22 UT So far, the observations have gone flawlessly, so this should be good data to get a baseline update for Bx, By and Bz. I will also be able to check pointing and feed unrotating.

Mar 05

13:30 UT Huge news! The 300 MHz correlator is working. The only known glitch is an off-by-one-slot error for the correlated data, which Jack is working on. Meanwhile, I took data all night on 3C273 and 3C286 using the new/complete science-channel definitions. The data recorded okay, and the science channels are good. However, we had no phase coherence. I discovered that the clock rate was set to 0.8 (GHz) in DPPparameters.f90. I have changed to 1.2, and am taking new data on 3C286 (the stronger 3C273 has set...).

Mar 06

15:00 UT I am back to the 200 MHz correlator, and will take some calibration (two-src) observations on 2136+006 and 2253+161, using 3bands.fsq. The scan started at 15:00 UT, but in fact with the new HA limits the source is not reachable yet. Should be reachable by the next file, at 15:10 UT.

15:30 UT Some sort of strange glitch occurred on Ant 14, and it stopped tracking without a visible error indication. I had to reboot it to recover. It is tracking again now.

18:25 UT I got a nice delay solution on source 2136+006, using delay_widget.py, and updated it. I am now taking some additional data on that source to check the delays. I am reasonably confident of the main (X) delays, but the Y-X delays may have the wrong sign.

19:07 UT I verified that delay_widget used the wrong sign of Y-X delays, so I fixed that and did one more test. The results are great! Just because I am paranoid, I am doing one last test after a very minor update in the delays. Then I will move on to test Jack's latest compile of the 300 MHz correlator.

Mar 07

01:32 UT The 300 MHz correlator appears to be fully working! I have been working with dppxmp all afternoon to solve the phase wind issues, and I believe I have finally solved it. With an 800 MHz clock, our 600-1200 MHz IF was in the third nyquist zone, so the order of channels was forward (low subchannels -> low frequency, etc.). Now with our 1200 MHz clock, the IF is in the second nyquist zone, so the order is reversed. I understood that, and adjusted chan_util_bc.py to write the channel assignments in the inverted order. However, that still did not solve the phase wind. Thinking further, I finally realized that the sign of the phase correction should also reverse. I applied that sign reversal, and now some 3C84 data I just took may be right. Oddly, though, it is only good on baseline 8-14, which is a problem I noted last month, which was only corrected by rebooting the ROACHes. I will do that now...