I observed a few science targets during this run. Weather was good
during the first half of this run and later it became cloudy. I lost almost two clear nights due to IOTA control
system problems. Listed below is a delay system for the present array configuration:
N35/S15/N10 (A Fixed) configuration:
delay_sys -sname ne25 -station 1887.3711 -station 1642.3562 -station -0.3581 -station 2501.9000 -sname se15 -station -985.4137 -station 1132.4227 -station 0.2148 -station 1501.1400 -sname ne10 -station 754.9485 -station 656.9425 -station -0.1432 -station 1000.7600 -config a -delta 0 -delta 0 -delta 0 -delta 0 -delta 0 -delta 0 -delta 0 -delta 0 -delta 0 -zero -165.39062 -zero -269.57056 -zero -104.34710 -zero 0.0 -zero 0.0 -zero 0.0
The SD offsets for this delay system are [-0.4, -0.7].
A few engineering aspects:
Star Acquisition Camera (SA): The performance of the frame grabber and associated
OT tools is excellent. I used them during the second half of my run without any difficulty.
Side lopes on the Power Spectrum: Occasionally, side lopes are still seen in the power spectrum.
In addition, a peak (of low amplitude) is also seen around 200Hz.
Control system problems: (1) To start with, the script 'observe_g3.2' was not working. I found
that the script was not loading 'source' and 'setenv'. Pete fixed a bug there. We also leant that while 'iota16' and 'VxWorks' are
sufficient to run OT, iota17 is also required to run IDL.
(2) After recycling power for 'iota16', I had difficulties to startup the control system. I had two problems:
(a) wrong clock settings on 'VxWorks' and (b) clients could not memory map. In detail: 'VxWorks' didn't set it's clock at the rebooting time
and was reading the factory clock settings ( year 1970!), although 'iota16' had the correct time settings. We expect 'VxWorks' to get
time information from 'iota16' in case the network server (which provides more accurate time signal to 'VxWorks') is down. I think, for some
reason that did not occur on that night. Finally, it reset to the correct time setting when I left the system idle for about half
an hour (hopefully it got time information from the network server). I think, the 'memory mapping problem' is something to do with the
loading sequence of various 'VxWorks' processes. We didn't have this problem in the past when correct startup sequence is followed.
Pete recommends the following sequence for startup & shutdown.
COLD POWER UP:
1. start up iota16
2. start up iota17 (if you want to use "observe" program)
><=== Under normal circumstances, this is where we start each night.
3. turn on VME box. this causes VxWorks to boot on all the CPUs and it will try to set the clock using the NTP server.
4. load the vxworks programs (vxworks-start in iotamc_g3.2 directory)
5. load the lmtmc program (lmtmc-start in iotamc_g3.2 directory)
6. load the daq program (daq-start in iotamc_g3.2 directory)
Please note that you have a choice here and you COULD actually forget
steps 4 and 5. You would do this to test the camera. The consequence is
that the IDL program would most likely show an error on its first attempt
to map the memory on the VME box. This should only be a temporary
7. load the IDL "observe" program (observe_g3.2)
1. quit the IDL program
2. quit the lmtmc program
3. quit the daq and vxworks programs (daq-stop vxworks-stop)
4. shutdown VME cage.
Spikes on PICNIC data: In the beginning of my run, I noticed occasional spikes on one night.
Possible noise sources are (a) new UPS units (b) Differential power - VxWorks on dirty power while the other IOTA computers on
UPS (c) The presence of 'front panel covers' of 'VxWorks', blocking the ventilation (although the room temperature around the
CPLD board was sufficient low - 68 deg F). I opened the panel covers, bypassed the new UPS units and the spikes disappeared. I am
not sure about the source of those spikes.
Shutter problem: As I mentioned in my last run report, occasionally, Fixed beam shutter
doesn't close fully and the D2 shutter doesn't open fully.