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 (faster than the standard scan by GASTON, scans 20240124s1-2). The B213 scans are very long and are good to test the stability of the system, the performance of tracking, and consequently the quality of the resulting maps.

We switch to bright compact sources, scan in AzEl at 40 arcsec/s: M82 (scans 5 to 7), Mrk231 (scans 8 to 10, wrong coords), Mrk231 (scans 14 to 16, correct coords).
Increase the scan speed to 60 arcsec/s: M82 (scans 11 to 13), Mrk231 (scans 17 to 19).
Next in the list, I'm going to observe a compact source with jets: 3C273 (pointing, scan 21; and then see below -> will continue tomorrow); M87 (tomorrow).

At 2:45 UT we received the awaited call from SMA and we give the telescope in the hands of the VLBI tests.
While waiting to be back online, NIKA2 celebrates the 55th anniversary of the Yellow Submarine (pulse tubes included!):

January 24th, Wednesday

Resuming observations at 09:30, after a successful VLBI session. Low wind (5-6 m/s), tau about 0.25.

Overshooting effects on pointing/focus corrections (i.e. about 7,2 arcsec/1.2 mm) are quite contained: no data discarded on PIIC-QL processing.

Refocusing after checking the beam at 2 mm (17.2" x 19.2") on 2013+370 (pointing scans 122 & 129, focus 123-128). Trying to observe comet P/Pons-Brooks. I launched by mistake the script of another non-sidereal target. Kike cancelled the scan. Unable to get the hexapods activated in the ACU after activating the axes & homology in the Dozer. Fixed after a while. Getting pointing correction again (scan 140). Good 2 mm-beam shape (17.2" x 17.9").

Comet 12P/Pons-Brooks observed (scans 141-149: about 1h) at El. > 60 deg. Something can be seen in the individual maps, to be coadded later.

We run a very small experiment and give the Sun as source. PaKo accepts it! We think that this should not be possible and that PaKo should refuse the Sun as source a priori... and maybe also send a message to the Station Manager warning that the observers have gone crazy.

Standard calib_1scan observations of the usual calibrators (MWC349, NGC7027, CRL2688) follow (scans nr. 20240124s150 to 153).
NOTES: Scan 152 got stuck, or at least hanging for a long time. Target Crl2688, Az 80 deg, but it was "thinking" at 66 deg (where NGC7027 was observed) without moving.

Then a compact object that we use for testing different scan modes, speeds, sizes, etc.: W3OH
Scan 164 azel, 10x5 arcmin, angle 0 deg, step 20 arcsec, speed 40 arcsec/s
Scan 165 radec, 10x5 arcmin, angle 0 deg, step 20 arcsec, speed 40 arcsec/s
Scan 166 radec, 10x5 arcmin, angle 45 deg, step 20 arcsec, speed 40 arcsec/s
Scan 167 radec, 10x5 arcmin, angle 90 deg, step 20 arcsec, speed 40 arcsec/s
Scan 168 radec, 10x5 arcmin, angle 135 deg, step 20 arcsec, speed 40 arcsec/s
Scans 169-173 same sequence, but speed 60 arcsec/s
Scans 174-178 same sequence, but 12x5 arcmin, speed 80 arcsec/s
Scans ... same sequence, but 15x5 arcmin, speed 100 arcsec/s (NOT PERFORMED, bcause it's that time of the day when the beam is uncontrollable)

These sequences give us the means to study the behavior of the tracking overshooting as a function of scan speed and scan direction.
Like a couple of days ago, as the scan speed increases, the amplitude and relative duration of the overshoot increase.

Even with yesterday modification of the ACU, at 80 arcsec/s more than 10% of the science records are affected by tracking deviation > threshold, when scanning in Az. Note that in this case, scanning in Az (i.e. AzEl with PA=0 deg) is very close to scanning along the Declination direction. Interestingly enough, though, scanning in RaDec at an angle of 90 degrees (i.e. in the Dec direction) DOES NOT produce the same effect (PIIC warning). Compare the tracking behavious of scans 174 and 177. In both cases there seem to be almost a double overshoot in Az, BUT for scan 174 (scanning in AzEl coords) the two components are much more apart than for 177 (scanning in RaDec coords), and therefore probably they affect more science records than in the 177 scan. Is this expected or is it weird?