The behaviour of the individual stations is relevant for all baselines, not only international ones. Because long baselines require the maximum achievable S/N, it is of particular importance to optimise the stations' performance. This section of the wiki covers station issues, including single-station observations.

— Olaf Wucknitz 31-Aug-2012 11:19

It has been observed for quite a while that the Effelsberg station DE601 often has a rather low sensitivity, particularly in the HBA. Bad sensitivity in general can be explained by bad station calibration, so it was not clear if this is a particular problem of Effelsberg. However, theory predicts that the sensitivity in the nominal phase centre of the beam should not depend on the position on the sky, no matter how good or bad the calibration is. The only position-dependent effect in the beam centre should be due to the element beams, which are not only relatively well behaved but also have certain symmetry properties. In contrast to this expectation, several observations shows serious variations with sky position.

In long-baseline interferometric observations, we have noticed earlier that the sensitivity is not as symmetric around the zenith as expected. This can be seen in AIPS calibration solution plots of L45786, a rather short observation. Different colours are for different frequency bands within the HBA low range. Page 8 shows the amplitude solutions of DE601 in comparison with other stations. Remember that high values mean low sensitivity. The Effelsberg gains vary over short durations much more than expected.

Another and better example is L35012, a 12h long track observation. Page 9 shows how the sensitivity of DE601 drops to almost zero around 23h-00h in a frequency-dependent way. No other station shows a similar behaviour.

Masaya Kuniyoshi performed a number of tests observing the bright pulsar B0329+54 and comparing the sensitivity for different parts of its track around the sky. He found that the sensitivity shows strong variations (by more than an order of magnitude), and that these variations are not symmetric around zenith. Depending on the version of the calibration table, the sensitivity was best either east or west of the zenith.

I thought about several ways to map out the beam shape of the station in order obtain more information about its behaviour. Just the amplitude in the centre does not tell us much, not even if we should blame the analog tile beam or the digital station beam. In the end I decided to do single-station observations using CygA and CasA as bright test sources. I mapped the beam by forming >200 beamlets in a grid around either of these sources. At any given time, all beamlets used the same subband (to reduce the influence of RFI etc), but the subbands were switched between a selection of relatively clean frequencies. Only the beamlet statistics were recorded, but no voltages. As additional diagnostic, I also stored local station correlations and subband statistics. In the night 21-22 Aug 2012 I did this for Effelsberg using the subbands 75,310,420 (114.6,160.5,182.0 MHz).

Beam maps in different coordinate systems are collected here:

Each PDF file has one page per snapshot (30sec). Here 'radec' refers to relative equatorial coordinates. In this system the beam rotates and gets distorted due to projection effects. To get rid of these effects, I also present projections to the horizontal components of the local station system, labelled as 'lm'. The latter system has the advantage that the elements are horizontally aligned, which results in translation-independent beams and an automatic compensation for any projection effects. We thus expect that in this system the beams should be stationary.

However, this is not what we find. The beams moves around significantly, by about 1-2 degrees.

Because the resolution of the beamlet plots is limited, I also include (lower two panels) images derived from the local correlations after applying the calibration table. These maps are entirely consistent with the upper panels, which confirms my correct understanding of coordinates and phase sign conventions. Having this option available also allows us to redo the maps with different calibration parameters or element position files without actually repeating the observations. This diagnostic turned out to be very helpful.

As comparison I produced similar images for DE603 (Tautenburg) and DE605 (Jülich), derived from observations of 27-28 Aug 2012. Many thanks to science support at ASTRON and to Eva Juette (Jülich) and Matthias Hoeft (Tautenburg) for making this possible! This was a great help.

Here is the corresponding table for DE603:

… and for DE605:

Note that the observing times are not all the same.

At these stations, no funny effects are observed, besides the occasional RFI producing additional peaks. The beams look much nicer, and they are solid as a rock. This is how it should be!

What could cause the motion of the beam relative to its nominal position? A bug in the beam former is possible, but not very likely given the relatively small effect. Another option are incorrect element coordinates. However, they cannot be entirely wrong, because that would distort the beam much more. The gentle shift does instead point towards minor problems with the local coordinate system.

If the coordinate system is rotated a bit relative to reality, we can describe the observed shift as follows: As a result of the rotation of the sky (or the Earth for the sceptics amoung you), the source moves around in the local (real) lmn coordinate system in a predictable way. The beamformer compensates for this, but it may use its own (incorrect) lmn system. Because the rotation of the sky is the same in both cases, the transformation from real to incorrect coordinates is simply the small rotation between the systems. What we observe is the apparent shift, which is the difference between the real and incorrect coordinates.

This means the shift is given by the rotation angle multiplied by the generating matrix of the rotation. It consists of three free parameters that can be fitted analytically in the first-order approximation of small angles. The procedure basically consists of fitting a linear (including constant offset) model for the shift as function of lmn coordinates. The best fit is consistent for both sources and all observed frequencies and corresponds to no rotation around the l and m axes but a rotation of 1.5 to 1.6 degrees around the (vertical) n axis. In other words the station coordinates are rotated by 1.55 degrees in the horizontal plane.

Instead of repeating the beamlet observations with modified element coordinates, I reused the local correlations but used the rotated coordinates for the imaging. Results in the lm system are given here:

Note that the upper two panels are not changed. They are just included as comparison.

We find that the rotated coordinates seem to solve the problem: The beams do not move around anymore but are stationary as they should. The beam shape is still bad and offset from the centre, because the station calibration has not been redone (yet).

I can also apply different (or no) calibration tables before imaging the correlations. Maps are available and can be added to the wiki on request.

Here are plots on the sensitivity at the beam peak and nominal beam centre for the original data:

'orig' is for the original version, 'rotated' has the coordinates rotated for the imaging results. Each file shows as function of time: min/max of all beamlets, value in the nominal centre, and the min/max(2) from the imaging data, and the centre(2) of the imaging. We generally see that the centre of the beam is much lower than the max and that the value at the centre shows the observed variations as function of time. The maximum itself, even though it may be lower than for perfect calibration, shows about the expected variation with elevation and azimuth. Elevation calculated for the local station coordinate system is shown for comparison.

For 'rotated', only the centre2 curves change, because only those beam images have been corrected. We see that the level as such does not always get better (because the station calibration is still bad), but the changes with time now follow the behaviour of the maximum that also resembles the expectations from the element response.

Curves for the other stations can be added on request.

The coordinates of the Effelsberg HBA tiles are incorrect. Rotating them by 1.5 to 1.6 degrees around the vertical axis seems to fix the problem. Some questions remain:

• how did this happen?
• when did it happen?
• should we also rotate the local coordinate system or only the element positions?
• what about the LBA positions?

We have 'new' measurements of the element positions available and should put them in the AntennaField.conf file as soon as possible. After that the station calibration should be repeated. For this we can even reuse the previous observations.

— Olaf Wucknitz 31-Aug-2012 12:54

The original determination of the rotation angle used the beginning of each 30 sec snapshot to calculate the appropriate delays, not the middle. Correcting for this increases the angle slightly, to about 1.6 deg.

Here are results from individual fits:

PLOTS_temp/DE601HBA_casa_sb075_peak.txt
ipol 0  peak2  read 31 good   rotations: -0.155159 +0.016478 +1.567199  [deg]    mean err 0.054048   no fit: 2.347833   max 0.163467 4.107604  [deg]
ipol 1  peak2  read 31 good   rotations: -0.144448 +0.114021 +1.566374  [deg]    mean err 0.051291   no fit: 2.591965   max 0.141686 4.469822  [deg]
PLOTS_temp/DE601HBA_casa_sb310_peak.txt
ipol 0  peak2  read 31 good   rotations: -0.068465 -0.054442 +1.652892  [deg]    mean err 0.035403   no fit: 1.047701   max 0.086019 2.235176  [deg]
ipol 1  peak2  read 31 good   rotations: -0.146425 -0.121926 +1.678144  [deg]    mean err 0.045300   no fit: 0.954634   max 0.128048 2.106454  [deg]
PLOTS_temp/DE601HBA_casa_sb420_peak.txt
ipol 0  peak2  read 31 good   rotations: -0.019954 -0.012736 +1.663448  [deg]    mean err 0.038866   no fit: 0.872822   max 0.110787 1.956218  [deg]
ipol 1  peak2  read 31 good   rotations: -0.037443 -0.086530 +1.681440  [deg]    mean err 0.040619   no fit: 0.817438   max 0.100355 1.768338  [deg]
PLOTS_temp/DE601HBA_cyga_sb075_peak.txt
ipol 0  peak2  read 24 good   rotations: -9.768076 +5.951909 -1.678177  [deg]    mean err 3.580895   no fit: 4.181896   max 8.600379 9.021761  [deg]
ipol 1  peak2  read 24 good   rotations: -1.136360 -0.468115 +1.510575  [deg]    mean err 0.058256   no fit: 3.033756   max 0.255960 5.529044  [deg]
PLOTS_temp/DE601HBA_cyga_sb310_peak.txt
ipol 0  peak2  read 24 good   rotations: -0.286233 -0.544840 +1.638029  [deg]    mean err 0.039315   no fit: 1.454305   max 0.203168 2.803888  [deg]
ipol 1  peak2  read 24 good   rotations: -0.072902 -0.481818 +1.679534  [deg]    mean err 0.037520   no fit: 1.267094   max 0.159909 2.484623  [deg]
PLOTS_temp/DE601HBA_cyga_sb420_peak.txt
ipol 0  peak2  read 23 good   rotations: -0.118661 -0.380058 +1.645125  [deg]    mean err 0.016417   no fit: 1.227655   max 0.048035 2.375695  [deg]
ipol 1  peak2  read 23 good   rotations: -0.236542 -0.465762 +1.651933  [deg]    mean err 0.017252   no fit: 0.964057   max 0.059468 2.115911  [deg]

The results are the rotations values. We see that most of them agree quite well, with the exception of CygA SB075 for ipol=0. But here the residuals after the fit (mean position error of the beam 3.58 deg) is also much larger than for all other fits. Looking at the movies of the beam shapes shows that some frames are affected by RFI or sidelobes. We can conclude that all other fits show a rotation around the vertical axis of 1.5 to 1.7 deg. 1.6 seems to be a good average. Rotations around the other axes are negligible.

I also ran similar fits for a 24h LBA observations. The measurement is much less clean, also due to strong intermittent RFI, but the results seems to be consistent with no rotation at all.

— Olaf Wucknitz 03-Sep-2012 15:21

Today James Anderson took recent (May 2012) measurements of the element positions and produced a table that can be compare with AntennaField.conf. It turns out that the new coordinates are indeed rotated relative to the old ones by 1.6 degrees. The deviations from this rotation matrix are less than 0.05 deg.

The LBA positions are rotated by max. 0.1 deg.

— Olaf Wucknitz 03-Sep-2012 21:42

In station calibration tests with local correlations (CasA, HBA low, but other data also available) taken 5/6 Sep 2012, I noticed that some HBA tiles have delays that are very different from the majority. Most are very close to zero with a scatter of ca. 2-3 nsec, but there are delays up to +-125 nsec, corresponding to almost 40 m in vacuum.

Here are numbers from some fits. They do not have the highest possible accuracy, but are good enough for this purpose:

el  3  ipol 0  phase   19.868 deg  delay   64.150 nsec
el  4  ipol 0  phase    7.273 deg  delay   63.666 nsec
el  5  ipol 0  phase   70.305 deg  delay  124.354 nsec
el 11  ipol 0  phase   22.098 deg  delay   63.429 nsec
el 20  ipol 0  phase   30.057 deg  delay   64.047 nsec
el 37  ipol 0  phase -109.703 deg  delay  -51.903 nsec
el 38  ipol 0  phase  -90.417 deg  delay  -51.864 nsec
el 46  ipol 0  phase -100.576 deg  delay  -52.030 nsec
el 47  ipol 0  phase  -82.251 deg  delay  -51.493 nsec
el 82  ipol 0  phase   53.040 deg  delay -126.612 nsec

el  3  ipol 1  phase    6.786 deg  delay   63.891 nsec
el  4  ipol 1  phase    7.176 deg  delay   64.081 nsec
el  5  ipol 1  phase   75.115 deg  delay  122.093 nsec
el 11  ipol 1  phase    7.172 deg  delay   63.773 nsec
el 20  ipol 1  phase   21.977 deg  delay   64.309 nsec
el 37  ipol 1  phase -111.961 deg  delay  -51.549 nsec
el 38  ipol 1  phase -112.679 deg  delay  -52.373 nsec
el 46  ipol 1  phase -102.704 deg  delay  -52.253 nsec
el 47  ipol 1  phase -105.893 deg  delay  -50.844 nsec
el 82  ipol 1  phase   69.122 deg  delay -125.398 nsec

Both polarisation are affected in the same way. All others are well below 10 nsec. Because these offsets are so close to the cable length differences, and because there are equal numbers of positive and negative offsets for 50-64 nsec and 120-126 nsec, a plausible cause could be swapped cable lengths in the CableDelays.conf file. Note that the RCU numbers in that file are 2*(element-number)+ipol.

The current calibration table corrects for some of these delays, but not for all. This is not too surprising, because offsets off this magnitude are not really expected, and the calibration software may not be suited for them.

This is from the CableDelays.conf file:

# Lenghts are in meters, delays are in ns.
#
# Note: The first order values are:
#	50m		199.2573
#	80m		326.9640
#	85m		342.5133
#	115m	465.5254
#	130m	530.6981

Estimated from these numbers, my 50-64 and 120-126 nsec offsets correspond to 15 m and 30 m cable length, respectively. The only way to match the corrected cable lengths with the available lengths of 50/80/85/115/130m is to apply the corrections to these numbers with negative sign.

Here are the values from the file for the affected elements together with the corrected cable lengths:

                     HBA
#RCUnr	        len	delay           corrected
#----------------------------------------------------
6		130     530.6981           115
7		130     530.6981           115
8		130     530.6981           115
9		130     530.6981           115
10		115     465.4000            85
11		115     465.6000            85
22		130     530.6981           115
23		130     530.6981           115
40		130     530.6981           115
41		130     530.6981           115
74		115     465.5254           130
75		115     465.5254           130
76		115     465.5254           130
77		115     465.5254           130
92		115     465.5000           130
93		115     465.5000           130
94		115     465.5000           130
95		115     465.5000           130
164		 85     342.5133           115
165		 85     342.5133           115

Or in summary:

115m instead of 130m: RCUs   6,  7,  8,  9, 22, 23, 40, 41  antennas  3, 4,11,20
130m instead of 115m: RCUs  74, 75, 76, 77, 92, 93, 94, 95  antennas 37,38,46,47
 85m instead of 115m: RCUs  10, 11                          antennas  5
115m instead of  85m: RCUs 164,165                          antennas 82

This does indeed look as if four antennas were swapped between 115 and 130m and one antenna between 85 and 115m.

Note that this still has to be confirmed.

— Olaf Wucknitz 13-Sep-2012 14:22

An old version of the cable length file de601-cabledelays.conf-rev14249.svn000.tmp.conf actually seems to be more accurate than the current version. It is unclear why the files has been changed.

This old version and the differences have been found by Menno Norden. Thanks for that!

Here is a diff output of the two files:

diff DE601-CableDelays.conf-rev14249.svn000.tmp.conf DE601-CableDelays.conf
1a2,4
> # CableDelays.conf for DE601
> #
> #
33,38c36,41
< 6             130     530.6981        130     530.6981        115     465.5000
< 7             130     530.6981        130     530.6981        115     465.5000
< 8             130     530.6981        130     530.6981        115     465.5000
< 9             130     530.6981        130     530.6981        115     465.4000
< 10            130     530.6981        130     530.6981         85     342.4000
< 11            130     530.6981        130     530.6981         85     342.6000
---
> 6             130     530.6981        130     530.6981        130     530.6981
> 7             130     530.6981        130     530.6981        130     530.6981
> 8             130     530.6981        130     530.6981        130     530.6981
> 9             130     530.6981        130     530.6981        130     530.6981
> 10            130     530.6981        130     530.6981        115     465.4000
> 11            130     530.6981        130     530.6981        115     465.6000
49,50c52,53
< 22            130     530.6981        130     530.6981        115     465.6000
< 23            130     530.6981        130     530.6981        115     465.4000
---
> 22            130     530.6981        130     530.6981        130     530.6981
> 23            130     530.6981        130     530.6981        130     530.6981
67,68c70,71
< 40            130     530.6981        130     530.6981        115     465.5000
< 41            130     530.6981        130     530.6981        115     465.5000
---
> 40            130     530.6981        130     530.6981        130     530.6981
> 41            130     530.6981        130     530.6981        130     530.6981
85,86c88,89
< 58            130     530.6981        130     530.6981        130     519.7000
< 59            130     530.6981        130     530.6981        130     519.7000
---
> 58            130     530.6981        130     530.6981        115     465.5254
> 59            130     530.6981        130     530.6981        115     465.5254
101,104c104,107
< 74            130     530.6981        130     530.6981        130     519.8000
< 75            130     530.6981        130     530.6981        130     519.7000
< 76            130     530.6981        130     530.6981        130     519.6000
< 77            130     530.6981        130     530.6981        130     519.8000
---
> 74            130     530.6981        130     530.6981        115     465.5254
> 75            130     530.6981        130     530.6981        115     465.5254
> 76            130     530.6981        130     530.6981        115     465.5254
> 77            130     530.6981        130     530.6981        115     465.5254
113,114c116,117
< 86            130     530.6981        130     530.6981         85     342.5000
< 87            130     530.6981        130     530.6981         85     342.5000
---
> 86            130     530.6981        130     530.6981        115     465.5254
> 87            130     530.6981        130     530.6981        115     465.5254
191,192c194,195
< 164           130     530.6981        130     530.6981        115     465.5000
< 165           130     530.6981        130     530.6981        115     465.4000
---
> 164           130     530.6981        130     530.6981         85     342.5133
> 165           130     530.6981        130     530.6981         85     342.5133

It is easy to confuse things now, but I think this is the correct summary:

6-11,22-23,40-41,74-77,164-165 have been correct in rev14249 and are wrong now
58-59,86-87 have been wrong in rev14249 and are correct now
92-95 have been wrong and are still wrong

This seems to be consistent with Menno's analysis. In other words neither of the files is correct and we should create a new version, but maybe only after confirming the conclusions at the station.

— Olaf Wucknitz 14-Sep-2012 09:47

It cannot be completely ruled out that some of the tiles are connected incorrectly, which would also produce incorrect cable lengths per rcu number. I only had a quick look at this possibility. In such a case we would expect the delays to change with sky position, because the geometric delays would not be taken care of entirely. For the following plot I first produced a calibration table for a certain time (integration 16 in this case), then calibrated with this table and determines residual delays relative to it as function of time and rcu number:

This is only for polarisation Y (X has more RFI). The elevation varies between about 80 deg and something like 50 deg or so. If there are any systematic delay changes, they should not be more than ca. 4 nsec, corresponding to 1.2 m. Even with the projection effects, no tile seems to be off by more than 2.5 m. Swapped neighbouring tiles are still a (unlikely) possibility, but swaps of more separated tiles don't seem to exist.

— Olaf Wucknitz 14-Sep-2012 12:16

Maybe not. James mentions that he did not find any large delays in HBA observations he took with the old version of the table. This would be evidence against incorrect cable lengths for 58-59,86-87,92-95 in rev14249.

Menno Norden provided a new file with corrections applied. There are also comments in the file explaining what has been changed:

de601-cabledelays.conf-modified-20120914-norden.conf

— Olaf Wucknitz 14-Sep-2012 17:46

On 16th October Menno Norden, Henri Meulman, Ian Stewart, Masaya Kuniyoshi, Andreas Horneffer and Olaf Wucknitz were at the station and (amongst other things) check the cable lengths in question. Reading the cable labels in the container is virtually impossible, so we did that at the tiles:

This confirms the analysis but is not consistent with no large delays in James' earlier experiments. A new version of the table has been installed now: de601-cabledelays.conf-modified-20121016-norden.conf

A diff of old versus new (without the comment lines) produces the following:

7,12c7,12
< 6		130	530.6981	130	530.6981	130     530.6981
< 7		130	530.6981	130	530.6981	130     530.6981
< 8		130	530.6981	130	530.6981	130     530.6981
< 9		130	530.6981	130	530.6981	130     530.6981
< 10		130	530.6981	130	530.6981	115     465.4000
< 11		130	530.6981	130	530.6981	115     465.6000
---
> 6		130	530.6981	130	530.6981	115     465.5000
> 7		130	530.6981	130	530.6981	115     465.5000
> 8		130	530.6981	130	530.6981	115     465.5000
> 9		130	530.6981	130	530.6981	115     465.4000
> 10		130	530.6981	130	530.6981	 85     342.4000
> 11		130	530.6981	130	530.6981	 85     342.6000
23,24c23,24
< 22		130	530.6981	130	530.6981	130     530.6981
< 23		130	530.6981	130	530.6981	130     530.6981
---
> 22		130	530.6981	130	530.6981	115     465.6000
> 23		130	530.6981	130	530.6981	115     465.4000
41,42c41,42
< 40		130	530.6981	130	530.6981	130     530.6981
< 41		130	530.6981	130	530.6981	130     530.6981
---
> 40		130	530.6981	130	530.6981	115     465.5000
> 41		130	530.6981	130	530.6981	115     465.5000
75,78c75,78
< 74		130	530.6981	130	530.6981	115     465.5254
< 75		130	530.6981	130	530.6981	115     465.5254
< 76		130	530.6981	130	530.6981	115     465.5254
< 77		130	530.6981	130	530.6981	115     465.5254
---
> 74		130	530.6981	130	530.6981	130     519.8000
> 75		130	530.6981	130	530.6981	130     519.7000
> 76		130	530.6981	130	530.6981	130     519.6000
> 77		130	530.6981	130	530.6981	130     519.8000
93,96c93,96
< 92		130	530.6981	130	530.6981	115     465.5000
< 93		130	530.6981	130	530.6981	115     465.5000
< 94		130	530.6981	130	530.6981	115     465.5000
< 95		130	530.6981	130	530.6981	115     465.5000
---
> 92		130	530.6981	130	530.6981	130     519.6000
> 93		130	530.6981	130	530.6981	130     519.6000
> 94		130	530.6981	130	530.6981	130     519.6000
> 95		130	530.6981	130	530.6981	130     519.6000
165,166c165,166
< 164		130	530.6981	130	530.6981	 85     342.5133
< 165		130	530.6981	130	530.6981	 85     342.5133
---
> 164		130	530.6981	130	530.6981	115     465.5000
> 165		130	530.6981	130	530.6981	115     465.4000

This is entirely consistent with the differences found in my analysis earlier. The CableDelays.conf file should be correct now.

— Olaf Wucknitz 16-Oct-2012 15:32

One week after the maintenance visit by Menno Norden and Henri Meulman (plus locals), I ran some test observations to check the cable length files and other aspects.

I ran an additional test to check for any X/Y swaps of HBA elements, using astronomical data.

I first found a relatively clean subband (205 in this case). Then I modified the BeamServer.conf to update the analog beamformer only once an hour (and thus not at all in this short test), to allow to first form a beam and then switch off some elements.

I then set the analog beamformer to a bright source (CasA in this case). I select a number of reference tiles (0,1,2 in one case and 80,81,82 in the second). For these reference tiles I keep all elements (to have a better S/N). For the other tiles I switch off all but one element (looping through all 16). Then I record cross-correlations (rspctl –xcstatistics) for 1min each with 1sec integrations. After the observation I check for each element number if the parallel-hand correlations to the reference tiles are stronger or weaker than the cross-hands. For each tile/element to test I print the fraction of integrations/reference tiles (out of 60×3) for which the parallel-hand is stronger than the cross-hand. This fraction should be almost 1 if everything is okay, and this is indeed the case for all tiles and all elements. The fractions are all > > 0.9, which means that no X/Y dipoles are swapped.

Of course one could use a better statistics than just counting “good” ratios of parallal/cross, but for this case the simple approach seems to be sufficient.

I still find some problems with a couple of LBA:

rcu 39 sometimes high
rcu 68 low (but stable)
rcu 74 low (but stable)
rcu 119 often high

The following figure shows images and phases in the direction of CasA using 1 sec of data per subband. I initially included subbands 50-462 but then (automatically) flagged those with strong RFI. For the calibration I fitted phases and delays for all HBA tiles. The plotted images and phases are averaged over the good subbands. The angular scale is in units of rad for lambda=2m. Subbands are averaged rescaling the angular scale to have the same resolution. In this way all subbands should have the same station beam. The coordinates are relative 2d station coordinates (called lm before). The numbers above the images are diagnostics to judge the calibration quality. centre/peak/coher stand for the value in the centre, the value at the peak, and the value in the centre divided by the sum of visibility amplitudes. The latter would be unity for perfect calibration and a signal dominated by a point-source in the centre. Applying the calibration increases this from about 0.1 to almost 1.

Note that the colour scale is different for the calibrated phases. Calibration errors would show up as horizontal and vertical bars with systematic deviations, where horizontal and vertical have different signs. We see on the right that these errors disappear after calibration.

I also produced a movie (also available as PDF) that spans 10 h and applies an independent calibration for each of the 68 snapshots. Particularly interesting is the uncalibrated left-hand side. Even though the beam does not look great, it now stays constant and does not move around with time. This tells us that the problem with the rotated element positions is ironed out eventually.

The resulting calibration tables are pretty constant so that (as expected) one calibration should be good for the entire observation. I applied the calibration from the snapshot shown above over the full run, which results in a calibrated movie (also as PDF). Not surprisingly the calibration gets worse near the horizon.

I applied the same calibration also to observations of CygA, resulting in a movie and a corresponding PDF file. The coherence is only slightly worse than for the CasA data themselves.

The delays from the fits are mostly very small, around 1-2 nsec. The largest one is 3.4 nsec, corresponding to less than 1m of cable delay. This means that all entries in CableDelays.conf are now correct, which indirectly implies that both of the previously installed versions were incorrect. I cannot tell why the large delays have not shown up much earlier. Recall that we had cable length errors of up to 40m before!

Carmen Toribio produced a calibration table from observations taken a few days earlier. I went through the same exercise as above but initially applied that calibration table (which is now installed on the LCU).

Here is the snapshot:

We see that most antennas already have the correct phases. The additional delays needed now are all very small (< 1 nsec) with the exception of the following:

 7  ipol 0  phase  -85.120 deg  delay    4.742 nsec
19  ipol 0  phase  -82.224 deg  delay    4.659 nsec
23  ipol 0  phase  -87.879 deg  delay    4.680 nsec
26  ipol 0  phase  -85.406 deg  delay    4.620 nsec
27  ipol 0  phase  -83.324 deg  delay    4.664 nsec
31  ipol 0  phase  -86.116 deg  delay    4.648 nsec
 7  ipol 1  phase  -84.459 deg  delay    4.559 nsec
19  ipol 1  phase  -83.685 deg  delay    4.800 nsec
23  ipol 1  phase  -87.458 deg  delay    4.651 nsec
26  ipol 1  phase  -84.579 deg  delay    4.704 nsec
27  ipol 1  phase  -83.671 deg  delay    4.799 nsec
31  ipol 1  phase  -86.001 deg  delay    4.685 nsec

All other delays shifted to about -0.3 nsec, because the mean is fixed to 0. This means the additional delays are almost exactly 5.0 nsec. It is thus plausible that they are resulting from the infamous 5 nsec problem that will be fixed with a hardware upgrade. In this particular occasion we are losing about 15% sensitivity. Note perfect, but much better than what we had before!

— Olaf Wucknitz 29-Oct-2012 18:48

On 15th November 2012, Andreas Horneffer (with help from Masaya Kuniyoshi and Olaf Wucknitz watching) installed the new SyncOptics boards that hopefully improve the relative timing and solve the 5 nsec problem.

Click here for details of performance tests done later.