2017 September: Difference between revisions

From EOVSA Wiki
Jump to navigation Jump to search
(Created page with "[http://www.ovsa.njit.edu/wiki/index.php/Expanded_Owens_Valley_Solar_Array#Observing_Log Back to Observing Log] = Sep 01 = '''13:10 UT''' Overnight I took another X-Y delay p...")
 
Line 2: Line 2:


= Sep 01 =
= Sep 01 =
'''13:10 UT''' Overnight I took another X-Y delay phase calibration on 2253+161.  Comparison with the one from Aug. 10 shows that it is identical, so I will not update the calibration--mainly because the results on Ant 11 and 13 are much better on Aug. 10.  Ant 11 was clearly not pointing well.  Ant 13 may have the same issue.  Additionally, using the low-frequency receiver showed that the X-Y delay for Ant 14, for that receiver, badly needed updating.  So I ran delay_widget.py on it and adjusted the LoRX delay by -6 ns.  This is the same amount needed for the HiRX, so probably I should simply adjust the LoRX and HiRX values at the same time, when analyzing the high-frequency receiver data.  I should also say that we were able to correct the data instability late yesterday by running the ACC LabVIEW code from memory rather than booting from the ACC.  This demonstrates that we know what the problem is, although we still do not have a permanent solution.  Gelu will investigate further today.
'''13:10 UT''' Overnight I took another X-Y delay phase calibration on 2253+161.  Comparison with the one from Aug. 10 shows that it is identical, so I will not update the calibration--mainly because the results on Ant 11 and 13 are much better on Aug. 10.  Ant 11 was clearly not pointing well last night.  Ant 13 may have the same issue.  Additionally, using the low-frequency receiver showed that the X-Y delay for Ant 14, for that receiver, badly needed updating.  So I ran delay_widget.py on it and adjusted the LoRX delay by -6 ns.  This is the same amount needed for the HiRX, so probably I should simply adjust the LoRX and HiRX values at the same time, when analyzing the high-frequency receiver data.  I should also say that we were able to correct the data instability late yesterday by running the ACC LabVIEW code from memory rather than booting from the ACC.  This demonstrates that we know what the problem is, although we still do not have a permanent solution.  Gelu will investigate further today.

Revision as of 13:17, 1 September 2017

Back to Observing Log

Sep 01

13:10 UT Overnight I took another X-Y delay phase calibration on 2253+161. Comparison with the one from Aug. 10 shows that it is identical, so I will not update the calibration--mainly because the results on Ant 11 and 13 are much better on Aug. 10. Ant 11 was clearly not pointing well last night. Ant 13 may have the same issue. Additionally, using the low-frequency receiver showed that the X-Y delay for Ant 14, for that receiver, badly needed updating. So I ran delay_widget.py on it and adjusted the LoRX delay by -6 ns. This is the same amount needed for the HiRX, so probably I should simply adjust the LoRX and HiRX values at the same time, when analyzing the high-frequency receiver data. I should also say that we were able to correct the data instability late yesterday by running the ACC LabVIEW code from memory rather than booting from the ACC. This demonstrates that we know what the problem is, although we still do not have a permanent solution. Gelu will investigate further today.