03 March

Andreas reports:

I just tested this mode (=rcumode 6) and found the following things:
- The beamserver does not change the clock. If you set it to rcumode 6 without
  changing the clock values, then you get rcumode 6 data (i.e. 170 MHz -
  230 MHz) with the 200 MHz ADC clock, thus the data folded into one have of
  the sampled band.
- Changing the clock does not kill the beamserver. But it does reset the
  rcumode settings of the RCUs, so you'll want to kill and restart the beam
  after changing the clock.
- On the other hand the TBBs _are_ reseted when changing the clock. When the
  TBBDriver detects a change of the clock, it waits 80 seconds and then
  reboots the TBBs. So all data on the TBBs are lost when changing the clock.
- To make matters worse: TBB-board number 4 (when starting to count with 0)
  does not seem to like the 160 MHz clock. When in that mode and with the RSPs
  configured to send data to the TBBs, it kept reseting every few minutes.
  (While I watched it it came back after each reset, but only until the next
  reset.)

Test of TBBs with 160MHz clock

Testing the clock-output of the TDS board in subrack 2 (TBBs 4 and 5) did not work, as we only brought a scope with 100MHz bandwidth.

We swaped TBBs 4 and 5, after that all TBBs worked fine with the 160MHz clock, in rcumode 6. (We didn't test before the swap.)

Installation of monitoring software

I (AH) installed Tobia Carrozi's monitoring software in:  /data/home/user5/iStnMonitor

The cron-job is set up as user5, the local logfile is: /data/home/user5/logs/stnStatus.log

On lofarx it is in: /home/observer/iStnMonitor

Running checkHardware.py

The original version of checkHardware.conf does not contain a valid directory for local data storage (or that can be created by me).