2021 July - Revision history

Dgary: /* July 21 */

2021-07-30T12:46:27Z

July 21

← Older revision		Revision as of 12:46, 30 July 2021
Line 13:		Line 13:
	== July 21 ==		== July 21 ==
	'''14:04 UT''' There were many broken routines when they could not find FDB files, but I realized that almost all of the information needed was also in the IFDB files on pipeline, so I rewrote the code to first look for the IFDB files and only if not found, to look for the FDB files. That seems to have allowed the code to work again, so the observations are now going normally. We also found a backup of FDB files through 2020 Oct 30, so those were restored.		'''14:04 UT''' There were many broken routines when they could not find FDB files, but I realized that almost all of the information needed was also in the IFDB files on pipeline, so I rewrote the code to first look for the IFDB files and only if not found, to look for the FDB files. That seems to have allowed the code to work again, so the observations are now going normally. We also found a backup of FDB files through 2020 Oct 30, so those were restored.

			== July 30 ==
			'''12:43 UT''' For the past several days we brought in some of the frontends to check their power levels and look at some gain variations. These were Ants 6, 8, and 12. Ant 12 VPol had a serious problem that seemed to have been fixed just by tightening everything up. All of the power levels look good, so after checking all of the connections they have been put back on the dishes. One issue I discovered is that the FEMbenchtest routine leaves the front end attenuations at 0 16, so Ants 6 and 8 have been run at those settings for the past day or so. Those were too high of attenuation so this morning I adjusted them (to 0 6 and 0 8) to return the ADC levels to where they should be. After today's data, I will be able to tell better whether the gain variations are any better after this procedure.

Dgary: /* July 20 */

2021-07-21T14:08:42Z

July 20

← Older revision		Revision as of 14:08, 21 July 2021
Line 10:		Line 10:
	== July 20 ==		== July 20 ==
	'''13:03 UT''' The DPP crashed yesterday, apparently the result of a failed /data1 disk. This has all of the FDB logs, so it may be a serious problem. Meanwhile, I set up another disk (former /ldata1) as the /data1 disk and the system is again running and taking data. I have to check that the pipeline is not experiencing problems due to the missing FDB logs.		'''13:03 UT''' The DPP crashed yesterday, apparently the result of a failed /data1 disk. This has all of the FDB logs, so it may be a serious problem. Meanwhile, I set up another disk (former /ldata1) as the /data1 disk and the system is again running and taking data. I have to check that the pipeline is not experiencing problems due to the missing FDB logs.

			== July 21 ==
			'''14:04 UT''' There were many broken routines when they could not find FDB files, but I realized that almost all of the information needed was also in the IFDB files on pipeline, so I rewrote the code to first look for the IFDB files and only if not found, to look for the FDB files. That seems to have allowed the code to work again, so the observations are now going normally. We also found a backup of FDB files through 2020 Oct 30, so those were restored.

Dgary: /* July 02 */

2021-07-20T13:07:02Z

July 02

← Older revision		Revision as of 13:07, 20 July 2021
Line 7:		Line 7:

	'''23:56 UT''' Oops, I just realized that my change from eq_coeff = 8 to eq_coeff = 2 was not made to the eovsa_corr.ini file, so it reverted back to 8. That means all of today's data will have been measured with far too much gain and no doubt has bad saturation. I just now edited eovsa_corr.ini to set it to 2, so hopefully we are back to correct data, but today's calibration will be no good.		'''23:56 UT''' Oops, I just realized that my change from eq_coeff = 8 to eq_coeff = 2 was not made to the eovsa_corr.ini file, so it reverted back to 8. That means all of today's data will have been measured with far too much gain and no doubt has bad saturation. I just now edited eovsa_corr.ini to set it to 2, so hopefully we are back to correct data, but today's calibration will be no good.

			== July 20 ==
			'''13:03 UT''' The DPP crashed yesterday, apparently the result of a failed /data1 disk. This has all of the FDB logs, so it may be a serious problem. Meanwhile, I set up another disk (former /ldata1) as the /data1 disk and the system is again running and taking data. I have to check that the pipeline is not experiencing problems due to the missing FDB logs.

Dgary: /* July 02 */

2021-07-02T23:59:26Z

July 02

← Older revision		Revision as of 23:59, 2 July 2021
Line 5:		Line 5:

	'''18:15 UT''' I was distracted by a meeting, but have now updated Ant 12 delay successfully. It was 10 ns off, previously, but looks good now. I may make one more tweak of all of the delays this evening, to correct a few 0.1 ns or so remaining delays.		'''18:15 UT''' I was distracted by a meeting, but have now updated Ant 12 delay successfully. It was 10 ns off, previously, but looks good now. I may make one more tweak of all of the delays this evening, to correct a few 0.1 ns or so remaining delays.

			'''23:56 UT''' Oops, I just realized that my change from eq_coeff = 8 to eq_coeff = 2 was not made to the eovsa_corr.ini file, so it reverted back to 8. That means all of today's data will have been measured with far too much gain and no doubt has bad saturation. I just now edited eovsa_corr.ini to set it to 2, so hopefully we are back to correct data, but today's calibration will be no good.

Dgary: /* July 02 */

2021-07-02T18:18:05Z

July 02

← Older revision		Revision as of 18:18, 2 July 2021
Line 4:		Line 4:
	'''15:55 UT''' Last night we rebooted a number of computers and the correlator in an effort to clean up some persistent glitches I was seeing in the data. That means we have to reset the delays, which I did this morning. The reference calibrator and solar scans are no good due to incorrect delays. As of now I have them all reset properly except for Ant 12, which for some reason did not provide a good delay measurement. I will try again now, based on a 3C84 calibration from a few minutes ago.		'''15:55 UT''' Last night we rebooted a number of computers and the correlator in an effort to clean up some persistent glitches I was seeing in the data. That means we have to reset the delays, which I did this morning. The reference calibrator and solar scans are no good due to incorrect delays. As of now I have them all reset properly except for Ant 12, which for some reason did not provide a good delay measurement. I will try again now, based on a 3C84 calibration from a few minutes ago.

	~~```~~18:15 UT''' I was distracted by a meeting, but have now updated Ant 12 delay successfully. It was 10 ns off, previously, but looks good now. I may make one more tweak of all of the delays this evening, to correct a few 0.1 ns or so remaining delays.		'''18:15 UT''' I was distracted by a meeting, but have now updated Ant 12 delay successfully. It was 10 ns off, previously, but looks good now. I may make one more tweak of all of the delays this evening, to correct a few 0.1 ns or so remaining delays.

Dgary: /* July 02 */

2021-07-02T18:17:49Z

July 02

← Older revision		Revision as of 18:17, 2 July 2021
Line 3:		Line 3:
	== July 02 ==		== July 02 ==
	'''15:55 UT''' Last night we rebooted a number of computers and the correlator in an effort to clean up some persistent glitches I was seeing in the data. That means we have to reset the delays, which I did this morning. The reference calibrator and solar scans are no good due to incorrect delays. As of now I have them all reset properly except for Ant 12, which for some reason did not provide a good delay measurement. I will try again now, based on a 3C84 calibration from a few minutes ago.		'''15:55 UT''' Last night we rebooted a number of computers and the correlator in an effort to clean up some persistent glitches I was seeing in the data. That means we have to reset the delays, which I did this morning. The reference calibrator and solar scans are no good due to incorrect delays. As of now I have them all reset properly except for Ant 12, which for some reason did not provide a good delay measurement. I will try again now, based on a 3C84 calibration from a few minutes ago.

			```18:15 UT''' I was distracted by a meeting, but have now updated Ant 12 delay successfully. It was 10 ns off, previously, but looks good now. I may make one more tweak of all of the delays this evening, to correct a few 0.1 ns or so remaining delays.

Dgary: Created page with "[http://www.ovsa.njit.edu/wiki/index.php/Expanded_Owens_Valley_Solar_Array#Observing_Log Back to Observing Log] == July 02 == '''15:55 UT''' Last night we rebooted a number o..."

2021-07-02T15:58:03Z

Created page with "[http://www.ovsa.njit.edu/wiki/index.php/Expanded_Owens_Valley_Solar_Array#Observing_Log Back to Observing Log] == July 02 == '''15:55 UT''' Last night we rebooted a number o..."

New page

[http://www.ovsa.njit.edu/wiki/index.php/Expanded_Owens_Valley_Solar_Array#Observing_Log Back to Observing Log]

== July 02 ==
'''15:55 UT''' Last night we rebooted a number of computers and the correlator in an effort to clean up some persistent glitches I was seeing in the data. That means we have to reset the delays, which I did this morning. The reference calibrator and solar scans are no good due to incorrect delays. As of now I have them all reset properly except for Ant 12, which for some reason did not provide a good delay measurement. I will try again now, based on a 3C84 calibration from a few minutes ago.