2017 September - Revision history

Dgary: /* Sep 14 */

2017-09-28T11:29:29Z

Sep 14

← Older revision		Revision as of 11:29, 28 September 2017
Line 8:		Line 8:

	'''12:52 UT''' The scans overnight went okay, but we lacked coherence on 6 of the antennas. This corresponds to three of the ROACHes, so it may be a non-issue in the sense that it could be related to dodgy timing (Jack said the timing score was quite bad for the design). I captured some packets and wrote up an analysis for Jack. I did note a few anomalies, including a pattern of missing and/or zeroed content packets. I have gone back to the old correlator, and am now attempting to grab some 3C84 data for determining the delays, prior to starting observations for the day.		'''12:52 UT''' The scans overnight went okay, but we lacked coherence on 6 of the antennas. This corresponds to three of the ROACHes, so it may be a non-issue in the sense that it could be related to dodgy timing (Jack said the timing score was quite bad for the design). I captured some packets and wrote up an analysis for Jack. I did note a few anomalies, including a pattern of missing and/or zeroed content packets. I have gone back to the old correlator, and am now attempting to grab some 3C84 data for determining the delays, prior to starting observations for the day.

			= Sep 25 =
			'''04:40 UT''' I tried a new 300 MHz correlator design of Jack's, but it had serious problems--namely, the M count was all over the place, with huge numbers, and the correlated data packets were not coming out. So I went immediately back to the 200 MHz design, and took data for updating the delays. One iteration is all it took, and the delays seem fine now.

Dgary: /* Sep 14 */

2017-09-15T12:57:39Z

Sep 14

← Older revision		Revision as of 12:57, 15 September 2017
Line 6:		Line 6:
	= Sep 14 =		= Sep 14 =
	'''03:41 UT''' We did some testing of the fast correlator (running at 300 MHz), and Jack says the earlier problem is gone! So I have set up the system to run in 300 MHz mode pretty-much all night on 2253+161, although the wind is up and many scans will be no good. It will try new scans every 20 min. I hope to get one or more good scans, with which to set the delays, and possibly run on the Sun in this mode tomorrow. Looks the like the first scan, at 03:45 UT, will be missed due to wind...		'''03:41 UT''' We did some testing of the fast correlator (running at 300 MHz), and Jack says the earlier problem is gone! So I have set up the system to run in 300 MHz mode pretty-much all night on 2253+161, although the wind is up and many scans will be no good. It will try new scans every 20 min. I hope to get one or more good scans, with which to set the delays, and possibly run on the Sun in this mode tomorrow. Looks the like the first scan, at 03:45 UT, will be missed due to wind...

			'''12:52 UT''' The scans overnight went okay, but we lacked coherence on 6 of the antennas. This corresponds to three of the ROACHes, so it may be a non-issue in the sense that it could be related to dodgy timing (Jack said the timing score was quite bad for the design). I captured some packets and wrote up an analysis for Jack. I did note a few anomalies, including a pattern of missing and/or zeroed content packets. I have gone back to the old correlator, and am now attempting to grab some 3C84 data for determining the delays, prior to starting observations for the day.

Dgary: /* Sep 01 */

2017-09-15T03:44:25Z

Sep 01

← Older revision		Revision as of 03:44, 15 September 2017
Line 3:		Line 3:
	= 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 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.		'''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.

			= Sep 14 =
			'''03:41 UT''' We did some testing of the fast correlator (running at 300 MHz), and Jack says the earlier problem is gone! So I have set up the system to run in 300 MHz mode pretty-much all night on 2253+161, although the wind is up and many scans will be no good. It will try new scans every 20 min. I hope to get one or more good scans, with which to set the delays, and possibly run on the Sun in this mode tomorrow. Looks the like the first scan, at 03:45 UT, will be missed due to wind...

Dgary: /* Sep 01 */

2017-09-01T13:17:26Z

Sep 01

← Older revision		Revision as of 13:17, 1 September 2017
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.

Dgary: 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..."

2017-09-01T13:16:59Z

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..."

New page

[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 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.