Run 4
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.
The calibration error of the system (flats, cnts/Jy, beam positions & sizes, ...) due to this problem alone is already above 20% ! 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 figures below show the telescope tracking in azimuth (in black) and elevation (in blue) during a map observed on August 4th and a focus observed on August 9th. The max. wind velocity was below 10m/s. in both cases. The statistics of the tracking behaviour (below) shows that the coordinate errors might reach values even larger than the HPBW@1mm at quite moderate wind velocities (indicated by the red arrows and the messages "lost tracking"). The errors "explode" when the angle between the telescope and the wind direction reaches a critical value. This demonstrates that the loop for the tracking control is not optimized.
Shown are: in red the rms of the tracking error in azimuth (true angle), in green the rms of the tracking error in elevation, in blue the average wind velocity within 1min, in cyan the max. wind velocity within 1min; for August 12-13 also: in magenta the elevation of the telescope, in yellow the angle between the telescope and the wind direction.
Run 5
The observations with NIKA seem to be affected in particular by synchro and/or tracking problems. The figure "median of az-tracking rms" below shows the medians of azim tracking in 5deg*5deg pixels for all data since June 5 2012 except Lissajous and obvious synchro. problems and "median of az-tracking rms, no NIKA" in addition without the observations with NIKA run 5. The first figure is clearly "noisier". The "noisy" pixels are dominated by observations with NIKA.
The tracking rms values are elevated at higher scanning velocities but reach the highest values at velocities around 0. The figure below demonstrates this.
In some cases the telescope lost the tracking and oscillated with amplitude >10arcsec (encoder angle). The example below rather indicates that the observations (maps) as performed with NIKA cannot be done at some conditions, i.e. reach the limit of the NCS.
