Differences between revisions 8 and 9
Revision 8 as of 2024-01-22 17:07:49
Size: 2662
Comment:
Revision 9 as of 2024-01-22 17:15:54
Size: 3020
Comment:
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
Angel and Stefano arrived to the telescope.
Line 10: Line 12:
NIKA2 is tuned. The PIIC monitor tells us that the 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. NIKA2 is tuned. The PIIC monitor tells us that the 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.
Line 17: Line 19:
OTF with no zig zag (141) OTF with no zig-zag (141)
Line 20: Line 22:
Without zigzag we avoid the big positive overshoot. Without zig-zag we avoid the big positive overshoot.
Line 29: Line 31:
We write here all scans of today, because the telescope feed is not transfered to Tapas.<<BR>>
Line 45: Line 47:
168-169 OTF 120 arcsec/s, 18x5, El 55 deg (but limit for this speed is 51 deg as warned by Pako) 168-169 OTF 120 arcsec/s, 18x5, El 55 deg (but limit for this speed is 51 deg as warned by Pako) <<BR>>
170 pointing <<BR>>
171-175 focus sequence <<BR>>
Line 47: Line 51:
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.
The faster the scan speed, the higher the fraction of records affected by the tracking overshooting (obviously). <<BR>>
The faster the scan speed, the larger the amplitude of the tracking overshoot. <<BR>>
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. <<BR>>

Back to the NIKA2 Run 64 main page

Daily Reports

January 22nd, Monday

Angel and Stefano arrived to 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 lauch several scans to study how the tracking behaves.

NIKA2 is tuned. The PIIC monitor tells us that the the data of the pointing pixel (Ar2) are corrupted. We tune again (lost KIDs: 58, 8, 68), but we dont 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 transfered 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
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

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 of stopping or avoiding the execution of the scan.

DailyReportsNika2Run64 (last edited 2024-08-08 17:55:03 by NikaBolometer)