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 behavour. 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).

Mars_azTrack.png Mars_Jupiter_azTrack.png

Within the subscans the tracking values 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 a map or 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 (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 !