The prototype flasher system was setup and tested on the NDOS. The setup was performed and checked in the following manner:
In the first configuration the LED was attached to the side of a horizontal module on the PVC. The black paint was removed from the PVC prior to attaching the LED and a black adhesive tape was used to fasten it to the plastic. In the second configuration the LED was attached to the spacer frame that separates the optical interface on the module from the APD carrier frame. The LED was positioned nearest the APD pixel column containing pixels 0-8.
Data was collected from the system using the following procedure:
- The DCM firmware was programmed into the DCM
- The FEB firmware was programmed into all the FEBs on the DCM
- The FEBs were configured for dual correleated sampling operation
- Internal pulser was diabled
- Microslice window was set at 250
- Thresholds were varied depending on the test
- Timing system was set to internal mode (-1)
- FEB masks were limited to 1 board at a time
- Pixel Masks were varied depending on the test
To program the firmware:
- Versions of the Firmware use were
- DCM: DCMFPGAFullChannel83_28Sep12.rbf
- FEB: FebV4.00.12.bin
These were loaded using:
dcmControl program /usr/firmware/DCMFPGAFullChannel83_28Sep12.rbf dcmControl programfeb /usr/firmware/FebV4.00.12.bin
The FEBs were then specially programmed using:
dcmControl dcs [uslice] [pulser period] [threshold] [feb mask lo 0-31] [feb mask hi 32-63] [timing link] [pix mask]
Example for microslice size=250, pulser=off, threshold=100 adc, FEB=22, timing=internal, pixels=1,2,3:
dcmControl dcs 250 0 100 0x00400000 0x0 -1 0x00000007
The data was then read out using the "dcmDataDrain" application in memory mapped mode and with a flush of hte kernel buffer:
The output that is generated is then:
FEB: 22 PIX: 24 PH: 169 TDC: 0x324995f8 usOff1s: 760471.8750 FEB: 22 PIX: 24 PH: 365 TDC: 0x329dca18 usOff1s: 846696.3750 FEB: 22 PIX: 24 PH: 317 TDC: 0x32da8cf8 usOff1s: 908915.8750 FEB: 22 PIX: 24 PH: 231 TDC: 0x33141a38 usOff1s: 967848.8750 FEB: 22 PIX: 24 PH: 157 TDC: 0x3321ddb8 usOff1s: 981942.8750 FEB: 22 PIX: 24 PH: 167 TDC: 0x33565458 usOff1s: 35665.3750 FEB: 22 PIX: 24 PH: 112 TDC: 0x33a3d898 usOff1s: 115042.3750 FEB: 22 PIX: 24 PH: 119 TDC: 0x341d79d8 usOff1s: 239591.3750 FEB: 22 PIX: 24 PH: 149 TDC: 0x34585ed8 usOff1s: 299899.3750 FEB: 22 PIX: 24 PH: 251 TDC: 0x346ab1d8 usOff1s: 318663.3750 FEB: 22 PIX: 24 PH: 225 TDC: 0x349f8c98 usOff1s: 372786.3750 FEB: 22 PIX: 24 PH: 209 TDC: 0x34a38918 usOff1s: 376868.3750
Where the different fields are the FEB number, Pixel number, Pulse height (adc value), TDC clock value in 64 MHz clock ticks (roll over at 67s boundary) and the final field is the offset of the TDC value in micro sconds from the 1 second boundary (i.e. time into the current second).
The flasher system was set to a specific period, pulse width and maximum drive current. The raw data was then collected under this configuration for a periods of time (typically a few minutes) and the resulting time and pulse height distributions were plotted to identify excesses that would indicate the flasher being detected by the APD.
The raw data files were copied to the Nova bluearc disk and then parsed to extract the pulse height and time into second information using:
cut -d ' ' -f 6,16 flaser_test_data.txt > flaser_test_data_ph_time.txt
This delimits the the fields based on spaces (the -d ' ') and then extracts fields 6 and 16. Because of the way the output is formated, the fields are either 5,6,7 or 15,16 (depending on the channel you are reading out and the way the formatting happened to insert spaces).
The time into the second was histogrammed (in this case with mathematica, you can do the same with root) so that excesses associated with the flasher firing could be identified. In the case of the histogram below time increases from RIGHT to LEFT. The two peaks are the flasher firing (clear excesses above background) and the deficits immediately following are the effect of the inhibit on retriggering caused by the tail of the amplifier's 7ms fall time (during which the DCS algorithm won't trigger since the n-2 sample is typically higher due to the tail than the nth sample)
The flasher width can be determined by the width of the deficit region.
TDU Setup for Sync Testing¶
The following sections document how the tests were performed with the TDU master. For all of these tests the TDU master was installed at NDOS and used to drive the CLIM (Coupe Light Injection thing). For the sync tests it was also used to perform the sync and to drive the master clock for the DAQ.
The version 2.12 firmware for the master TDUs now supports turning the TTL (5V 50 Ohm) on and off as well as setting its pulse width. To do this you need to program the output pulse width register of the TDU in the following manner:
- The pulse width register is address 0x001A
- Writing a value of 0x0 to the register disables the TTL output
- Writing a non-zero value to the register enables the output
- The width of the output is set to the value of written * 7.63 usec.
- The CLIM unit will output this duration of a pulse to the flasher
- The dynamic range of the output is 7.63 us to 0.5 s.
- 0x1 = 7.63 us
- 0xd = 100 us
- 0xffff = 0.5 s
This functionality has been tested and works appropriately.
For testing the Flasher system we have setup a master TDU in the NDOS building. The TDU is connected to the GPS antenna on NDOS. To use this TDU as the master timing source for the test setup the following procedures should be followed.
- Boot and verify the TDU
- The TDU should boot as tdu-08 on both the ARM and PPC boards
- Ensure that the powerpc interface finds its boot files and is able to boot all the way into Linux
- If the TDU is going to be used as the timing source for the slave TDUs (which are installed below it in the rack) then the timing input to the first slave needs to be changed
- Disconnect the fiber optic input from the first slave
- Connect the copper (yellow) cable coming from the master TDU to the input on the slave
- Verify that the l-clk (lock clock) light comes on
Now login to the TDU from a terminal as root
Verify that the TDU is up and configured correctly. First make sure that the kernel module is loaded on the TDU. Use the "lsmod" command to list the modules that are loaded. If the tdu_kernel is not listed then load it using insmod.
[root@tdu-08:~]$ lsmod Module Size Used by [root@tdu-08:~]$ insmod /nova/novadaq/releases/development/tdu_kernel_module/tdu_kernel.ko
Setup the nova software suite for the TDU
source /nova/novadaq/setup/setup_novadaq.sh --xcompile --opt
This will give you access to all the TDU related diagnostics.
Next readout the registers in the TDU using tduRegDump. You should see a valid register map.
Now you can issue commands using tduControl or the other tdu utils.