Back to the NIKA2 Run 64 main page

Daily Reports

January 22nd, Monday

Angel and Stefano arrived at the telescope.

We take the telescope at 14:50 UT. It was pointing very close to the Sun for a while, because of Sun avoidance tests, therefore it will take at least 2h before it relaxes. Nevertheless, we launched several scans to study how the tracking behaves.

NIKA2 is tuned. The PIIC monitor tells us that the data of the pointing pixel (Ar2) are corrupted. We tune again (lost KIDs: 58, 8, 68), but we don't recover the pointing pixel.

We study the tracking. Lots of overshooting at the turns between subscans.
Experiments with Uranus (starting at 30 deg elevation):
pointing scans (20240122s135 to 138)
standard OTF (139)
OTF with tTune changed from 3 to 5 seconds (140)
OTF with no zig-zag (141)

When scanning only in Azimuth, the overshoot follows a repeating pattern.
Without zig-zag we avoid the big positive overshoot.

The temperature inside NIKA2 oscillates by 0.2 mK (0.1 mK amplitude) every ~7 minutes.
Dave reduces the pressure of the pump. We wait a bit for a new equilibrium.

Note that the EMIR pointing model is installed. We have no updated NIKA2 pointing model. We should make a pointing session, as soon as the telescope relaxes. For now we apply the big offsets given by the PIIC monitor (-16 arcsec, -54 arcsec) and the pointing pixel is recovered. Pointing scans: 142 to 144. We now focus properly (16 UT forward).

Then we test different scan speeds, to study the tracking, on Uranus, 12x3 arcmin scans (Equatorial), step 30 arcsec, 0 and 90 deg direction (Eq). Scan speeds 20, 40, 60, ...

We write here all scans of today because the telescope feed is not transferred to Tapas:

Summary (Uranus):
20240122s134 track
20240122s135 to 138 pointing
20240122s139 OTF
140 OTF tTune 5 instead of 3
141 OTF no zigzag
142-144 pointing
145-154 two focus sequences 155 pointing -> 2mm beam ~18,7x19.5 arcsec (best we can do at the moment); but 1mm beam still terrible
156-157 OTF 20 arcsec/s (radec system, PA=0 and PA=90 deg, as the next following OTFs)
158-159 OTF 40 arcsec/s
160-161 OTF 60 arcsec/s
162-163 OTF 80 arcsec/s
164-165 OTF 100 arcsec/s
166-167 OTF 100 arcsec/s, 15x3 arcmin
168-169 OTF 120 arcsec/s, 18x5, El 55 deg (but limit for this speed is 51 deg as warned by Pako)
170 pointing
171-175 focus sequence

Next, selected plots from PIIC-QL for scans 156 to 163, and 166-167. PA=0 at left, PA=90 at right:

• The faster the scan speed, the higher the fraction of records affected by the tracking overshooting (obviously).
  

• The faster the scan speed, the larger the amplitude of the tracking overshoot.
  

SB's gut feeling: as a rule of thumb until the tracking overshooting isn't solved, I'd say that it's better to stay below 60 arcsec/s.

The max Elevation warning by Pako has no effect on stopping or avoiding the execution of the scan.

An experiment with source B213 follows. At 60 arcsec/s the scans get stuck. Jean tries something. It gets stuck again. Some more coding, restart the Blue-Pill, and re-able connection with OHB interface. The magic is that very big scripts, the ACU needs a lot of time to process it and send the commands, so now Jean increased the time for this from 30s to 60s. There exist much bigger science scripts, though (e.g. Orion's project 117-23), this might need further magic. Jean proposes to make this time flexible (e.g. a multiple of the number of commands).

The B213 scans go through. They also have a tilt and all is good. Single scans processed by the PIIC monitor are healthy. Naturally, we shall then perform the whole pipeline data reduction by combining the scans, but single maps from PIIC-QL (see an example at left below) look similar to those obtained about one year ago on the same target (plot at right, LP GASTON):

During focus, we saw spikes in the noise tracks of the KIDs on the DAQ. We wonder if these are due to the interaction of the motor's (magnetic field) with NIKA2. Se the next plot of DAQ timelines:

After the scans on Uranus, this effect disappeared.