|
Size: 2493
Comment:
|
Size: 2493
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 26: | Line 26: |
| the tracking has to be verified during the coming NIKA run !''' | the tracking has to be verified during the coming NIKA run ! |
| Line 28: | Line 28: |
| Update August 9: Contrary to informations from Granada the tracking problem is still present. The figure below shows the telescope tracking in azimuth (in black) and elevation (in blue) during a map observed on August 4th. The max. wind velocity was below 10m/s. | Update August 9: Contrary to informations from Granada the tracking problem is still present. The figure below shows the telescope tracking in azimuth (in black) and elevation (in blue) during a map observed on August 4th. The max. wind velocity was below 10m/s.''' |
The figures Mars_azTrack and Mars_Jupiter_azTrack show the tracking values in azimuth (i.e. errors of the azimuth) as function of time for the first 4 subscans (rows) of the maps 20120601s140, 20120604s168 (in blue) and 20120601s149, 20120604s218 (in black). All other subscans show the same behaviour. The vertical red lines show the subscan start, the vertical green lines the subscan end. Between the subscans the tracking values are meaningless as are calculated to some "transition trajectories" (see description of the NCS).
Within the subscans the tracking values (coordinate errors) reach very large numbers, even above 3arcsec 
in "no wind" conditions. They are different for the subscans with increasing and decreasing azimuth, i.e. with and against the Earth rotation. This introduces an apparent and variable zig-zag between the subscans in maps and pointings. The values of this zig-zag depend on many parameters (source coordinates, elevation, scanning velocity, ..., position within the map (=pixel number), beam width). They may reach even a couple of arcseconds and due to averaging the coordinates across the telescope beam of different size are in general different for the 1 and 2mm data. This "tracking error" zig-zag explains why the average telescope beams are *always* elliptical, i.e. there is no way to correct the zig-zag for all beams with one single time shift of the backend data.
This zig-zag is at least of the same order as any putative zig-zag caused by any synchronization errors between NIKA and the telescope, makes therefore the determination of the last impossible.
Such bad tracking behaviour of the telescope appeared after the replacement of some gear boxes last September. I identified this problem in March but it was present already 1st of October. According to IRAM Granada its reason was found only after the last NIKA run. Currently the tracking is much better but still not at a level as prior to the change -> the tracking has to be verified during the coming NIKA run ! Update August 9: Contrary to informations from Granada the tracking problem is still present. The figure below shows the telescope tracking in azimuth (in black) and elevation (in blue) during a map observed on August 4th. The max. wind velocity was below 10m/s.
