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 T. 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 more contained: no data discarded on PIIC-QL processing so far.

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, because 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 behaviour of scans 174 and 177 (El. about 40 deg). 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?

15:00 UT we test the next level of Jean's solution. The first level implemented yesterday was to allow for a 3s wait for all commands of a scan to be processed, before starting the scan. In that frame, all commands are processed individually, one after the other, taking ~250 ms each. This new solution is to send instead all commands at the same time. With yesterday's solution, the time needed between when we gave the beammap command and when the scan effectively started was roughly 1m30s. With today's new implementation it takes ... nothing. The experiment did not work. Jean installed back yesterday's version. But now we have the system stuck. Salvador tries to put the system in "local" and acknowledge the errors manually, in the intention to avoid a reboot of the ACU. But the ACU interface does not seem to let him do it. There are 3 interfaces open at the same time, we don't know why, nor which one is the good one *facepalm*. At 16:00 UT the telescope and ACU are unlocked and we continue. Nobody has understood what happened and how the problem was solved. SB's humble opinion: there's still a lot to work on the user-friendiness of this new ACU system indeed. Thank you Jean, Enrique and Salvador for your help.

Conclusion of test: the new solution by Jean sends all scans commands to the ACU in one single package at once. The ACU gave an error message never seen before. When asked, the answer by OHB is that this operation is described in the (ACU?) user manual, but is not implemented yet. Therefore at the moment it is not possible to do it and we keep the solution implemented yesterday with the 3s delay and each command sent individually sequentially. When OHB implements this capability, the Blue Pill has already Jean's new piece of code ready.

Meanwhile, Robert Z. has started to process the new sweep's beam map, after SB copied it manually to Grenoble (the mirroring from Pico to Grenoble does not work yet, as usual when a new season opens). So far Ar2 is being analyzed and Robert reports the presence of a big zig-zag effect. Quoting his words: "The zig-zag is quite large. This means that the time of the telescope and the time of the slow traces are not the same (or not as they were before). The major question is: is it constant? This can be done reliably only with the beam maps, therefore the calculation and analysis of the zig-zag is quite time-consuming." Thank you, Robert for your help.

16:25 UT. The focus is still very unstable and distorted. In a normal science pool, we would now stop, but we're just testing different observing modes. We restart. Now we observe the asteroid Metis with 40 arcsec/s scan speed at El~27 deg (i.e. low elevation test of a non-sidereal target - scans 204, 205, 206 - not detected - the elevation is low, more than 10% of records affected by large tracking deviations).

A skydip follows (scan 207). Nothing special to report. It goes smoothly.

The beam is still very unstable. We then give the telescope to some Pulsar EMIR observations.

[Comment: when speaking about tracking errors, please add information on the wind situation from the wind meter readings. Note also that all the many speed warning messages of pako are still referring to the old servo system. We still need to find out the speed limits at a given elevation for the new system.<CK>] [SB: all observations so far were performed with wind <<10 m/s]

January 25th, Thursday

Resuming observations at 06:30 UT. Low wind (speed <2 m/s), tau about 0.3. Restarting DAQ (bad KIDs: 54/7/78). Pointing (scans 54 and 60) and focus (scan 55-59) on 3C279. Last pointing correction 7.6,-10.8. Reasonable beam width (2 mm): 17.3"x18.5".

Continuing observations of compact sources:

3C273: scans 20240125s61-66, azel, 10x5 arcmin, angle 0 deg, step 20 arcsec, speed 40 arcsec/s.
M87: scans 67-72, same setup as 3C273.

We tried to observe comet 62P. We start the script, but the telescope tries to go to a completely different position than where the comet is supposed to be. We check the orbital parameters on the JPL pages and we update them to the latest solution, but it does not solve the problem. We don't know yet what is happening. The other comet 12P/Pons-Brooks observed yesterday worked. Pablo T. later tells us that during the night, when he tried to observe 62P with EMIR, he encountered the same problem. He also triple checked on the JPL page and did not find any mistakes in the the orbital parameters used. Apparently the JPL ephemeris are correct, but the orbital parameters not. We take new orbital parameters from the Minor Planet Center and we will test them likely tomorrow.

Then we observe Pablo T.'s Magnetar, close to the Galactic center: AXP1810-197
scans 83-85, 8x5 arcmin, step 15 arcsec, speed 40 arcsec/s, azel 0 deg. We realized it's a very crowded region, hence we increased the map size
scans 93-98 + 106-109, 12x5 arcmin, step 20, speed 40 arcsec/s, azel 0 deg. The beam is gradually degrading (10:30 UT)

At 13:07 UT we stop the DAQ and we give space for other tests. The afternoon is booked by Ioannis for XPOL tests.

Update about beam-maps and zig-zag from Robert Z.: The figure below shows the value of the zigzag as function of the time shift for the coordinates, red is 20240123s58, green is s71. Whereas for s58 the shift is ~0s (roughly -11.3ms different than it was during NCS), the shift for s71 is completely different: roughly -33ms. It seems, that the time of the slow traces is strongly variable. For comparison, note that the zig-zag detected by Carsten with EMIR few days ago had a time shift of roughly 400 ms.

For completeness, these Figures show the beam map 20240123s71 with the zig-zag:

At 13:37 UT Pablo M. informs us that he fixed Tapas. Now all scans taken during these days of commissioning are recorded there and the new ones will automatically flow into Tapas too. Thank you Pablo!!!

We resume the NIKA2 tests at roughly 21:00 UT, under the light of a nice plenilunio.
The first scan is 20230125s195. Tapas receives the information of the scans correctly, even faster than before.

We observe Uranus and we want to obtain additional data to study the zig-zag, therefore we take beam-maps. Since we also have a new sweep that will be the one used in the future science pools, we take the chance to perform again a beam map with the new sweep. After this, we will also perform one with the old one, just in case this has any influence on the zig-zag time delay (it shouldn't be related).

Beam-map with new sweep: 20240125s208 option "a", i.e. El<60 deg -> 65 arcsec/s
Not-tuned KIDs in the new sweep: 26, 1, 36.

Beam-map with old sweep: 20240125s210
Not-tuned KIDs in the new sweep: 53, 4, 66.

Question: on 2024/01/23 we took two beam maps (scans 58 and 71), but only one of the two shows the zig-zag (see notes above). Let's check what option we used for the two. Checking on Tapas, we see that scan 58 was taken at El. 66 deg and scan 71 at El. 63 deg. Both had a duration of ~41 minutes, which tells us that we used for both the same option "h" (i.e. El>60 deg, scan speed 40 arcsec/s, effectively 39 arcsec/s) [SB was wondering if the zig-zag difference between the two could be due to a different scan speed, but it does not seem so].

We then complete the speed test on W3OH, started yesterday:
Scan 212 azel, 15x5 arcmin, angle 0 deg, step 20 arcsec, speed 100 arcsec/s
Scan 213 radec, 15x5 arcmin, angle 0 deg, step 20 arcsec, speed 100 arcsec/s
Scan 214 radec, 15x5 arcmin, angle 45 deg, step 20 arcsec, speed 100 arcsec/s
Scan 215 radec, 15x5 arcmin, angle 90 deg, step 20 arcsec, speed 100 arcsec/s
Scan 216 radec, 15x5 arcmin, angle 135 deg, step 20 arcsec, speed 100 arcsec/s
Scans 217-221 same sequence, but speed 120 arcsec/s

The elevation was between 42 and 37 deg.

At 100 arcsec/s the behaviour is the opposite to what was reported yesterday at 80 arcsec/s. SB thinks that the difference between the azel and radec scans is not due to the scanning coords system, but it rather might be due to Elevation. In fact, yesterday the source was rising, today it is setting. Hence yesterday azel was taken at lower El than radec, while today it's the opposite. This could explain the opposite behaviour seen today wrt yesterday. To be investigated further, if we wanna have the final answer on what's causing this and whether this is an issue at all. Extra explanation: by "El. dependence" I mean that: the scripts first observe the scan in azel and then those in radec. Therefore when rising, the azel scan is at lower El than the radec scans, and when setting the azel scans are at high El than the radec ones. The difference in elevation between azel-0 and radec-90 is roughly 1.5 deg, which to me should not create such differences in tracking deviation, but who knows.

January 26th, Friday

We proceed with a test on very long scans (1 deg subscan length) and medium scan speed (60 arcsec/s), observed in equatorial coords in direction N-S and small deviations. Scans nr. 20240125s223 and 20240126s2,3,11-16.

We orient the scans N-S and with a small angle (90+/-10 and 90+/-5 deg), so to verify if a small angle makes any difference on the amplitude and incidence of the tracking overshooting (so to be sure this isn't an issue in what we've noticed with the W3OH test, see above). The tracking along the long scans is stable. The max amplitude of the overshooting is >10arcsec even at El>50 deg, likely because of the scan speed and the N-S direction (?). Being the sub-scans very long, the fraction of affected records is generally small. At a first look, the small angle difference does not seem to play a role in producing different tracking deviation behaviours. Nevertheless, it is difficult to appreciate the details on the PIIC monitor (because there are many subscans) and therefore will need to be analyzed elsewhere.

Another beam-map follows (scan 19, old sweep). This one is mainly aimed at studying the zig-zag only, because it targets 3C279 (variable QSO). That's also the reason why it's done with the old sweep only.

Finally now let's observe comet 62P, using the correct orbital parameters taken from the Minor Planets Center (see above). We obtained 15 maps of 9x6 arcmin, angle=[45,0,-45] deg, step 15 arcsec, speed 40 arcsec/s, radec: 1.45 h in total (scans 20240126s21-26 + 35-40 + 48-50). Some hints of the comet in several individual maps. Offline reduction will say anything else. Pointing & focus quite stable so far.

Pointing and focus on 1757-240 before continuing on the magnetar AXP1810-197 (see above). Scans 59-64 + 77-82; 12x5 arcmin, step 20, speed 40 arcsec/s, azel 0 deg. Stable atmosphere (p2p variations of the raw timelines at 2 mm < 1.5 Jy/b), but the geometry of the beam gradually deteriorated (last FWHM estimation at 2 mm after focusing: 18.0x21.5 arcsec). On the other hand, Miguel asked for testing OTF maps with EMIR on NGC6217. DAQ stopped at 11:30 UT.

Update on the zig-zag analysis using beam maps by Robert Z. (thank you Robert!):
the 3 additional maps confirm the results of yesterday, see the figure below. The atmosphere was more stable than yesterday: the distributions are narrower and reach lower zig-zag values down to roughly 0.6 arcsec.

Using Grafana, we obtain the plots of "everything" that was going on in the Blue Pill + ACU system during the beam maps. We took screenshots of the Grafana plots and we copy them below here (click to enlarge). The five figures belong to beammaps 20240123s58, 20240123s71, 20240125s208, 20240125s210, 20240126s19, respectively. We do not see anything obvious, but we're sleepy after the long night and we might be missing it. We invite the readers to take a deep look into these plots and see if they can find any correlations with the zig-zag time delays reported in Robert's figure.

SB's suggestions for Grafana. Despite the main purpose of Grafana is to monitor what's going on to the system in real time, we found it very useful to check back in the past what was going on during specific scans. Therefore here SB takes the liberty to give a couple of suggestions for possible improvements, based on his very short experience surfin' in Grafana.

• the selection of scans is performed by time. One needs to know the exact start and end time of scans (e.g. using Tapas). Would it be possible to
  • add the scan number in the Grafana page(s)
  • select by scan number
• The time in Grafana is local. This is odd and we took sime time to realize it. Using UT would make more sense as everything in the observatory refers to UT.
• to produce the plots above, SB had to take screenshots of the long Grafana page and paste them together with the Gimp. It would be useful to add a "print" capability (preferably on PDF). The print function of the browser does not produce a good output: it prints only the first A4 page, all the majority of the information is not there. I guess this is because the Grafana page is calling scripts for each plot. I know that it's possible to share a specific plot, but I mean printing the whole page.

Thank you!

The late morning and the afternoon are dedicated to EMIR and XPOL observations by Miguel and Ioannis. After dinner Ioannis starts the EMIR Horsehead maps requested by Carsten. The wind is increasing and is very close to 15 m/s. We remind that with the new system, for now the wind speed limit is 15 m/s because above this threshold very strange noises come from the motors and the cabin. At 21:21 UT first time above 15 m/s. At 21:50 UT the telescope must be stopped and parked because the wind is now repeatedly >16 m/s, unfortunately before the Horsehead EMIR maps could be taken. We completed only the onoff-psw scan that precedes the OTF maps.

These are the tracking errors of the psw scan (s106) before stopping <CK>:

While we wait patiently for the wind to set, we found a little treasure and we'd like to share it with you... (and nowadays we complain how complex is to reduce NIKA2 data...)
Click to enlarge.


... almost done.

January 27th, Saturday

The telescope was stopped the whole night, because of wind > 15 m/s. Observations resumed at roughly 8:00 UT, but stopped again at 9:48 UT. With wind gusts up to 11-13 m/s and the wind facing the antenna, it was impossible to get a focus. Moved to a direction perpendicular to the wind and the focus was done. Moved back to the pointing source facing the wind and the beam was again terrible, and about 20% of the records lost in the pointing scans because of tracking deviations.

TAPAS problem: the az,el position recorded for a given scan corresponds to the position at start. Therefore if one is slewing from far away, the position recorded is wrong (e.g. the position of the previous source). It seems that it takes for granted that the telescope is already on source when starting. Is it done on purpose or not? This needs anyway to be fixed. In fact - for example - if for computing a pointing model from a pointing session, we use the Az El coords given by tapas (as we often do), the result will be wrong.

Here comes a comparison of three pointing scans and two calib_1scan, in different wind conditions (click to enlarge):
20240124s140: pointing with no wind (<5 m/s)
20240127s22: pointing with side wind (max gusts 14 m/s)
20240127s20: pointing with face wind (max gusts 14 m/s)
20240124s153: calib_1scan with no wind (<5 m/s)
20240127s24: calib_1scan with side wind (max gusts 14 m/s)

January 28th, Sunday

We resume the observations at 7:08 UT. The wind has finally calmed down enough (current avg wind speed 5 m/s with max 8 m/s). We continue the long scans test, now at lower elevation (<40 deg), to further verify the tracking behaviour.
Scans 20240128s10-12 scan speed 60 arcsec/s, El. ~34-30
Scans 20240128s14-16 scan speed 80 arcsec/s, El. ~25-20

Effect of a mild wind: [images follow]

At ~12 UT we try a pointing at 85 deg elevation on MWC349, but it complains it's too high. [Who complains ?] <CK> We went there with a track (scan 40), but the pointing does not even start. This means that the pointing scripts uses a too fast speed for this elevation. I then send the telescope to El 75 deg using directly a nkpoint script, but it does not move (scan 41). We cancel and I send it first with track (scan 42) and after the track nkpoint (scan 43). This time it works. After the pointing, we go back to MWC349 at 86 deg El with a track and we start a slow OTF at 10 arcsec/s. It executes it.