2017 May - Revision history

Dgary: /* May 30 */

2017-05-31T11:54:34Z

May 30

← Older revision		Revision as of 11:54, 31 May 2017
Line 42:		Line 42:
	= May 30 =		= May 30 =
	'''15:20 UT''' We are now running the 200 MHz correlator design. Jack is away for a week, so no further progress is expected on the 300 MHz design for awhile. We will continue with the 200 MHz design until some progress is made on finding the cause of loss of synchronization. The 27-m receiver is still in the lab--hopefully will be back this week! No calibrations possible until it is restored to service.		'''15:20 UT''' We are now running the 200 MHz correlator design. Jack is away for a week, so no further progress is expected on the 300 MHz design for awhile. We will continue with the 200 MHz design until some progress is made on finding the cause of loss of synchronization. The 27-m receiver is still in the lab--hopefully will be back this week! No calibrations possible until it is restored to service.

			= May 31 =
			'''12:50 UT''' We are struggling to get control of the receiver in the lab, using a different control computer. Some assumptions about hostnames has made for some problems, so I made some changes to the starburstControl system that appear to have helped. However, I still cannot bias the amplifiers in the receiver, and the ACC cannot communicate with the control system on feanta. We will work more on it today.

Dgary: /* May 28 */

2017-05-30T15:22:42Z

May 28

← Older revision		Revision as of 15:22, 30 May 2017
Line 39:		Line 39:
	= May 28 =		= May 28 =
	'''17:15 UT''' I got a late start today. I noticed that not all packets were coming out of the correlator, so I reloaded it and started observations just now.		'''17:15 UT''' I got a late start today. I noticed that not all packets were coming out of the correlator, so I reloaded it and started observations just now.

			= May 30 =
			'''15:20 UT''' We are now running the 200 MHz correlator design. Jack is away for a week, so no further progress is expected on the 300 MHz design for awhile. We will continue with the 200 MHz design until some progress is made on finding the cause of loss of synchronization. The 27-m receiver is still in the lab--hopefully will be back this week! No calibrations possible until it is restored to service.

Dgary: /* May 27 */

2017-05-28T17:16:57Z

May 27

← Older revision		Revision as of 17:16, 28 May 2017
Line 36:		Line 36:
	= May 27 =		= May 27 =
	'''23:48 UT''' I finally got around to adjusting the accumulation window. I reduced it by 512 samples, so it will be 2048 long. Hmm--looks like the design does not tolerate that, or else I made some other error. I am not getting all the packets out. I gave up and went back to the full 2560-length.		'''23:48 UT''' I finally got around to adjusting the accumulation window. I reduced it by 512 samples, so it will be 2048 long. Hmm--looks like the design does not tolerate that, or else I made some other error. I am not getting all the packets out. I gave up and went back to the full 2560-length.

			= May 28 =
			'''17:15 UT''' I got a late start today. I noticed that not all packets were coming out of the correlator, so I reloaded it and started observations just now.

Dgary: /* May 26 */

2017-05-28T00:21:36Z

May 26

← Older revision		Revision as of 00:21, 28 May 2017
Line 33:		Line 33:
	'''11:15 UT''' It looks like Jack's change, and a setting of 15000 for inter-packet delay, has completely solved the missing packets problem! Jack loaded a new design in the wee hours of May 25, and now about 30 h later it is still putting out the full number of packets. However, his change did not affect the oscillations we see in the data. I spent quite a bit of time yesterday looking into it, and I reported to Jack that I strongly suspect that the problem is incorrect timing of the accumulation window. An accumulation has mostly the target frequency, but with a non-trivial admixture of the following frequency in the sequence. The result is a contamination by data oscillating at a 500 MHz fringe rate (the difference frequency between two tunings). I verified this by looking at band 10 data, which is followed by band 25, and hence has a much larger frequency difference. Indeed, the contamination oscillated at a far higher fringe rate, as expected.		'''11:15 UT''' It looks like Jack's change, and a setting of 15000 for inter-packet delay, has completely solved the missing packets problem! Jack loaded a new design in the wee hours of May 25, and now about 30 h later it is still putting out the full number of packets. However, his change did not affect the oscillations we see in the data. I spent quite a bit of time yesterday looking into it, and I reported to Jack that I strongly suspect that the problem is incorrect timing of the accumulation window. An accumulation has mostly the target frequency, but with a non-trivial admixture of the following frequency in the sequence. The result is a contamination by data oscillating at a 500 MHz fringe rate (the difference frequency between two tunings). I verified this by looking at band 10 data, which is followed by band 25, and hence has a much larger frequency difference. Indeed, the contamination oscillated at a far higher fringe rate, as expected.
	Today I will do a test, by capturing packet data during tuning in the pcal.fsq sequence, and then do some other tests where I adjust the accumulation window to be shorter in an attempt to reduce the contamination. For this, I need the Sun, so I'll have to wait for a few hours.		Today I will do a test, by capturing packet data during tuning in the pcal.fsq sequence, and then do some other tests where I adjust the accumulation window to be shorter in an attempt to reduce the contamination. For this, I need the Sun, so I'll have to wait for a few hours.

			= May 27 =
			'''23:48 UT''' I finally got around to adjusting the accumulation window. I reduced it by 512 samples, so it will be 2048 long. Hmm--looks like the design does not tolerate that, or else I made some other error. I am not getting all the packets out. I gave up and went back to the full 2560-length.

Dgary: /* May 26 */

2017-05-26T11:28:05Z

May 26

← Older revision		Revision as of 11:28, 26 May 2017
Line 32:		Line 32:
	= May 26 =		= May 26 =
	'''11:15 UT''' It looks like Jack's change, and a setting of 15000 for inter-packet delay, has completely solved the missing packets problem! Jack loaded a new design in the wee hours of May 25, and now about 30 h later it is still putting out the full number of packets. However, his change did not affect the oscillations we see in the data. I spent quite a bit of time yesterday looking into it, and I reported to Jack that I strongly suspect that the problem is incorrect timing of the accumulation window. An accumulation has mostly the target frequency, but with a non-trivial admixture of the following frequency in the sequence. The result is a contamination by data oscillating at a 500 MHz fringe rate (the difference frequency between two tunings). I verified this by looking at band 10 data, which is followed by band 25, and hence has a much larger frequency difference. Indeed, the contamination oscillated at a far higher fringe rate, as expected.		'''11:15 UT''' It looks like Jack's change, and a setting of 15000 for inter-packet delay, has completely solved the missing packets problem! Jack loaded a new design in the wee hours of May 25, and now about 30 h later it is still putting out the full number of packets. However, his change did not affect the oscillations we see in the data. I spent quite a bit of time yesterday looking into it, and I reported to Jack that I strongly suspect that the problem is incorrect timing of the accumulation window. An accumulation has mostly the target frequency, but with a non-trivial admixture of the following frequency in the sequence. The result is a contamination by data oscillating at a 500 MHz fringe rate (the difference frequency between two tunings). I verified this by looking at band 10 data, which is followed by band 25, and hence has a much larger frequency difference. Indeed, the contamination oscillated at a far higher fringe rate, as expected.
	Today I will do a test, by capturing packet data during tuning in the pcal.fsq sequence, and then do some other tests where I adjust the accumulation window to be shorter in an attempt to reduce the contamination. For this, I need the Sun, so I'll have to wait for a few hours.		Today I will do a test, by capturing packet data during tuning in the pcal.fsq sequence, and then do some other tests where I adjust the accumulation window to be shorter in an attempt to reduce the contamination. For this, I need the Sun, so I'll have to wait for a few hours.

Dgary: /* May 24 */

2017-05-26T11:27:33Z

May 24

← Older revision		Revision as of 11:27, 26 May 2017
Line 29:		Line 29:
	= May 24 =		= May 24 =
	'''16:41 UT''' The 27-m receiver has been removed from the dish (as of yesterday), and the receiver will be opened and the problems hopefully identified and fixed. I cannot guess how long we will be down. Meanwhile, Jack has verified that the 300 MHz correlator is not producing all of its packets, but has a potential solution for which he is working on a new compile. I have high hopes that it may solve the lost-packets problem. There is also the synchronization problem that may or may not be due to the same lost-packet issue. We are taking normal solar data today, but of course without calibration...		'''16:41 UT''' The 27-m receiver has been removed from the dish (as of yesterday), and the receiver will be opened and the problems hopefully identified and fixed. I cannot guess how long we will be down. Meanwhile, Jack has verified that the 300 MHz correlator is not producing all of its packets, but has a potential solution for which he is working on a new compile. I have high hopes that it may solve the lost-packets problem. There is also the synchronization problem that may or may not be due to the same lost-packet issue. We are taking normal solar data today, but of course without calibration...

			= May 26 =
			'''11:15 UT''' It looks like Jack's change, and a setting of 15000 for inter-packet delay, has completely solved the missing packets problem! Jack loaded a new design in the wee hours of May 25, and now about 30 h later it is still putting out the full number of packets. However, his change did not affect the oscillations we see in the data. I spent quite a bit of time yesterday looking into it, and I reported to Jack that I strongly suspect that the problem is incorrect timing of the accumulation window. An accumulation has mostly the target frequency, but with a non-trivial admixture of the following frequency in the sequence. The result is a contamination by data oscillating at a 500 MHz fringe rate (the difference frequency between two tunings). I verified this by looking at band 10 data, which is followed by band 25, and hence has a much larger frequency difference. Indeed, the contamination oscillated at a far higher fringe rate, as expected.
			Today I will do a test, by capturing packet data during tuning in the pcal.fsq sequence, and then do some other tests where I adjust the accumulation window to be shorter in an attempt to reduce the contamination. For this, I need the Sun, so I'll have to wait for a few hours.

Dgary: /* May 24 */

2017-05-24T16:51:39Z

May 24

← Older revision		Revision as of 16:51, 24 May 2017
Line 28:		Line 28:

	= May 24 =		= May 24 =
	'''16:41 UT''' The 27-m receiver has been removed from the dish (as of yesterday), and the receiver will be opened and the problems hopefully identified and fixed. I cannot guess how long we will be down. Meanwhile, Jack has verified that the 300 MHz correlator is not producing all of its packets, but has a potential solution for which he is working on a new compile. I have high hopes that it may solve the lost-packets problem. There is also the synchronization problem that may or may not be due to the same lost-packet issue.		'''16:41 UT''' The 27-m receiver has been removed from the dish (as of yesterday), and the receiver will be opened and the problems hopefully identified and fixed. I cannot guess how long we will be down. Meanwhile, Jack has verified that the 300 MHz correlator is not producing all of its packets, but has a potential solution for which he is working on a new compile. I have high hopes that it may solve the lost-packets problem. There is also the synchronization problem that may or may not be due to the same lost-packet issue. We are taking normal solar data today, but of course without calibration...

Dgary: /* May 23 */

2017-05-24T16:51:12Z

May 23

← Older revision		Revision as of 16:51, 24 May 2017
Line 26:		Line 26:
	= May 23 =		= May 23 =
	'''03:59 UT''' Because the 27-m focus rotation mechanism was out due to a power-supply failure, there have been no calibration observations for the past week. I took advantage of that to run the 300 MHz correlator, which has been running since Friday. However, it continues to have its loss of packets, and I also verified that it gets progressively work over time, as if it were losing synchronization more and more badly over time. I was about to do some calibrations with the fast correlator, but find that the antenna (14) is in LOCAL mode. I am not sure why--perhaps it was never set back to REMOTE after the repair was completed last Friday.		'''03:59 UT''' Because the 27-m focus rotation mechanism was out due to a power-supply failure, there have been no calibration observations for the past week. I took advantage of that to run the 300 MHz correlator, which has been running since Friday. However, it continues to have its loss of packets, and I also verified that it gets progressively work over time, as if it were losing synchronization more and more badly over time. I was about to do some calibrations with the fast correlator, but find that the antenna (14) is in LOCAL mode. I am not sure why--perhaps it was never set back to REMOTE after the repair was completed last Friday.

			= May 24 =
			'''16:41 UT''' The 27-m receiver has been removed from the dish (as of yesterday), and the receiver will be opened and the problems hopefully identified and fixed. I cannot guess how long we will be down. Meanwhile, Jack has verified that the 300 MHz correlator is not producing all of its packets, but has a potential solution for which he is working on a new compile. I have high hopes that it may solve the lost-packets problem. There is also the synchronization problem that may or may not be due to the same lost-packet issue.

Dgary: /* May 14 */

2017-05-23T04:05:31Z

May 14

← Older revision		Revision as of 04:05, 23 May 2017
Line 23:		Line 23:
	= May 14 =		= May 14 =
	'''02:05 UT''' We are observing two_src.scd (3C273 and 3C286) with pcal_lo-all.fsq, which uses the Low-frequency receiver and includes band 1. The main purpose is to find the Ant 12 baseline solution, but we can also evaluate the Ant 5 band-1 data.		'''02:05 UT''' We are observing two_src.scd (3C273 and 3C286) with pcal_lo-all.fsq, which uses the Low-frequency receiver and includes band 1. The main purpose is to find the Ant 12 baseline solution, but we can also evaluate the Ant 5 band-1 data.

			= May 23 =
			'''03:59 UT''' Because the 27-m focus rotation mechanism was out due to a power-supply failure, there have been no calibration observations for the past week. I took advantage of that to run the 300 MHz correlator, which has been running since Friday. However, it continues to have its loss of packets, and I also verified that it gets progressively work over time, as if it were losing synchronization more and more badly over time. I was about to do some calibrations with the fast correlator, but find that the antenna (14) is in LOCAL mode. I am not sure why--perhaps it was never set back to REMOTE after the repair was completed last Friday.

Dgary: /* May 13 */

2017-05-14T02:07:15Z

May 13

← Older revision		Revision as of 02:07, 14 May 2017
Line 20:		Line 20:
	= May 13 =		= May 13 =
	'''02:05 UT''' I found Ant 12 was in Maintenance mode, and switching it to Operate brought it to life. It seems to be running fine now. Unfortunately, Ant 14 focus is stuck, and it is nowhere near the focus for the high-frequency receiver, so we will not get good data on that until it is repaired on Monday. We can observe with the low-frequency receiver.		'''02:05 UT''' I found Ant 12 was in Maintenance mode, and switching it to Operate brought it to life. It seems to be running fine now. Unfortunately, Ant 14 focus is stuck, and it is nowhere near the focus for the high-frequency receiver, so we will not get good data on that until it is repaired on Monday. We can observe with the low-frequency receiver.

			= May 14 =
			'''02:05 UT''' We are observing two_src.scd (3C273 and 3C286) with pcal_lo-all.fsq, which uses the Low-frequency receiver and includes band 1. The main purpose is to find the Ant 12 baseline solution, but we can also evaluate the Ant 5 band-1 data.