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-enable 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:
s186: @nkotf 22 28 -65 +45 30 60 radec
s187: @nkotf 22 28 -65 -45 30 60 radec
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 (scans 171-175), 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:
spikes = signal of Uranus is excluded ? RZ

During the B213 "science" scans (in Eq coords) this effect was not present.

We try a beam-map (scan 210) on Uranus. The scan gets stuck. We guess it consists of too many commands even for the 60s time set by Jean earlier this evening. Nevertheless, note that earlier the scans got stuck at the "loading" step, while now the beam-map gets stuck at the "tuning" step (i.e. right after loading. Note also that it took roughly 1m20s to load the scan. We try again (scan 211) but it gets stuck again. We also try with the beam-map with 95 sub-scans, instead of 99, but the result is the same (scan nr. 212). After 3 minutes with a hanging "tuning" process, the turbofan of the NIKA2 electronics rack starts and we kill this scan too.

Now we test some bright extended source: the Horsehead Nebula, with 10x8 arcmin scans, 40 arcsec/s, two orientations, 6 repetitions, i.e. 12 scans in total (213 to 225). The goals are to: a) compare to previous results obtained at the 30 school; b) check the behaviour of tracking and scanning over longer time; c) check against zig-zag effects (seen this morning with EMIR).

After midnight UT, we start a pointing session (scans 20240123s1 to s35). Very stable focus.

January 23rd, Tuesday

We take control of the telescope at 16:50 UT.
This morning a new sweep has been done by Martino and Alessandro.
A new NIKA2-driven pointing model has also been applied, based on yesterday's pointing session.
OHB worked on the ACU. They added the 2s wait before sub-scan-start.

As first task of today, we will try to run a beam-map, so to see if Jean's new patch works and it can be performed. Jean increased the max waiting time to 3 minutes.

We target Uranus. Scans:
20240123s40-51 pointing trying to find the starting point of focus and pointing model; big troubles finding it. We change the focus completely (randomly in the range +1.4 to -0.5), but the beam shape does not change at all. The hexapod wasn't active. Pedro fixed it manually.
52-56 focus
57 pointing
58 beam map test (YES! it works now!). Note that the quality of the beam map itself probably won't be great, because it's dusk, but the test is passed.

The tracking overshoot today is better contained in the time between sub-scans and enters in the sub-scan by a much smaller amount. Evidently the work by OHB on the ACU has some effect.

We celebrate the beam map watching Africa at sunset...

We try a fast moving target: the NEO 1685 Toro (aka. 1948 OA), that passed its perigee earlier in January. Today it is moving at ~9.6 arcsec/minute. Scans 60, 61, 62. Not detected.

We then prepare for taking a beam map for the new sweep. Uranus. Pointing, focus, pointing using the old sweep (scans 64 to 70), switch to the new sweep, beam-map (scan 71), go back to old sweep.

KIDs lost old sweep: 63, 6, 68
KIDs lost new sweep: 25, 1, 35

Beam-map with NEW sweep: scan 20240123s71.

After the new sweep beam-map, we continue the bright extended source tests (Horse Head, scans from 20240123s82 to 93), this time with scan speed 60 arcsec/s. We proceed with B213 with 80 arcsec/s (standard script of GASTON, scans 20240124s1-2).

We switch to compact sources and try some radio jets.