Nov 2012
Date : 1 Nov 2012 (K. Allada)
1. Noticed unusual behavior when setting PL and PTW windows in faSetProcMode() . When PTW gets close to the width of PL (within ~20ns) then I don't see the signal in the event display (only some part of tail exists). This turns out to be a problem with channel (#5)on the FADC. When I moved the signal to different channel, the problem is gone!
2. Wanted to test the "Pulse" and "Intergral" modes in the FADC.
- Copied Bob's fadc_try3.c to fadc_list.c and compiled. This list is meant for (pseudo) buffering
- Changed the mode to "pulse" in faSetProcMode. I did observe data every BUFFSIZE events. Same with "intergral" mode, but with much less data (as expected)
- I saw that DT for "short read" (see Bob's previous entry) is 0.5 usec and not 5 usec (typo above?)
- The PL (latency) was set to 75 (300ns) and PTW (window) was set to 50 (200ns)
Mode ....... BUFFSIZE ..... Num words ........... DT of short read ... DT of long read ...... avg DT Raw ....... 100 ........... 39316 .............. 0.5 usec ........... 875 usec .............. 9.25 usec Pulse ...... 100 ............ 2092 .............. 0.5 usec ............ 70 usec .............. 1.12 usec Integral ....100 ............ 604 ............... 0.5 usec ............ 35 usec .............. 0.85 usec
- This implies that with the integral mode (and with blocking) we can reach 0.85usec DT => 1.1 MHz!!
- Eventually, I assume, this is the mode we want to run for the Compton DAQ, and the "raw mode" can be used as a periodic check of the signal shape etc..
I restored the standard fadc_list.c with one change; Now the signal is in channel #7, so rest of them are disabled.
Date : 2 Nov 2012 (R. Michaels)
The above test is nice if the data are good. But if the data are all garbage ...
So, in order to check this I've modified the datastream in fadc_try3.c.
Empty events are like this 0x00000002 0x00000002 0xf000b10b 1st = 2nd = event count (two counters, should agree) 3rd = 0xf000b10b, it's a marker (for empty event) Full events begin like this 0x00000064 0x00000064 0xfb0b0b0b 0x00000001 0x0000025d 1st and 2nd = event count 3rd = 0xfb0b0b0b, marker for full event 0x00000001 = datascan (1 or 0) 0x0000025d = nwords returned by faReadBlock The rest are the words from faReadBlock A bad result would have nwords = 0 and the next line 0xda00bad2
Run 1334 is done with integral mode.
Run 1335 is done in Raw mode.
I'll analyze these offline.
Date : 5 Nov 2012 (R. Michaels)
The pseudo-buffered "raw" mode (as in run 1335, see Nov 2 notes) makes some sense offline. I see lots of raw pulses that look reasonable, though I didn't try to plot them.
The integral mode (as in run 1334) looks corrupted, so I'm not sure our tests up to now have a meaning. See a partial dump from a block read in run 1334 below.
The first number shown, 0x81432001, is interpreted as a BLOCK HEADER.
The next numbers have a structure: 1st column looks to the decoder like a "data type defining word", and the 2nd one is the same minus the leading 0x9. Also, these two columns look like counters: incrementing by 1 each time.
The 3rd and 5th column are increasing monotonically and are the same except for the leading 0x98 in col. 3.
Columns 4 and 6 are identical (actually, different by 1), and appear to be meaningless.
According to the manual, OPT=3 in faSetProcMode(FA_SLOT, OPT,75,WINDOW,3,6,1,0)
is supposed to to do Integral Mode, passing only a Sum and a TDC value for each pulse. At least I thought so.
Raw data from run 1334 0x81432001 0x900486f1 0x000486f1 0x9800a7ae 0x00328990 0x0000a7ae 0x0032898f 0x900486f2 0x000486f2 0x9800a7ae 0x00572a8e 0x0000a7ae 0x00572a8d 0x900486f3 0x000486f3 0x9800a7ae 0x008b0406 0x0000a7ae 0x008b0405 0x900486f4 0x000486f4 0x9800a7ae 0x00b1abea 0x0000a7ae 0x00b1abe9 0x900486f5 0x000486f5 0x9800a7ae 0x00d64f98 0x0000a7ae 0x00d64f97 0x900486f6 0x000486f6 0x9800a7af 0x000a25fe 0x0000a7af 0x000a25fd 0x900486f7 0x000486f7 0x9800a7af 0x0030d097 0x0000a7af 0x0030d096 0x900486f8 0x000486f8 0x9800a7af 0x00556f52 0x0000a7af 0x00556f51 0x900486f9 0x000486f9 0x9800a7af 0x00894922 0x0000a7af 0x00894921 0x900486fa 0x000486fa 0x9800a7af 0x00afedff 0x0000a7af 0x00afedfe 0x900486fb 0x000486fb 0x9800a7af 0x00d493b7 0x0000a7af 0x00d493b6 0x900486fc 0x000486fc 0x9800a7b0 0x00086b41 0x0000a7b0 0x00086b40 0x900486fd 0x000486fd 0x9800a7b0 0x002f1637 0x0000a7b0 0x002f1636 0x900486fe 0x000486fe 0x9800a7b0 0x0053b4bf 0x0000a7b0 0x0053b4be 0x900486ff 0x000486ff 0x9800a7b0 0x00878cd8 0x0000a7b0 0x00878cd7 0x90048700 0x00048700 0x9800a7b0 0x00ae34b6 0x0000a7b0 0x00ae34b5 0x90048701 0x00048701 0x9800a7b0 0x00d2d683 0x0000a7b0 0x00d2d682 0x90048702 0x00048702 0x9800a7b1 0x0006afe2 0x0000a7b1 0x0006afe1 0x90048703 0x00048703 0x9800a7b1 0x002d57ac 0x0000a7b1 0x002d57ab 0x90048704 0x00048704 0x9800a7b1 0x0051f4cc 0x0000a7b1 0x0051f4cb 0x90048705 0x00048705 0x9800a876 0x00840718 0x0000a876 0x00840717 0x90048706 0x00048706 0x9800a876 0x00b7e300 0x0000a876 0x00b7e2ff 0x90048707 0x00048707 0x9800a876 0x00de97d9 0x0000a876 0x00de97d8 0x90048708 0x00048708 0x9800a877 0x00033e1f 0x0000a877 0x00033e1e 0x90048709 0x00048709 0x9800a877 0x00371ce4 0x0000a877 0x00371ce3
Date : 6 Nov 2012 (R. Michaels)
I've learned that we have an "older" FADC, whose data format is slightly different. E.g. there are two FPGAs, etc. I also learned that my threshold was too high, so no PULSE INTEGRAL data. Setting this to 100, I see PULSE INTEGRAL data. I need to characterize how the results vary with threshold. I'm still not sure if this threshold is in ADC channels or what unit.
Since I had some saturation problems, I decided to calibrate the ADC in RAW mode. Here is how the peak ADC value varied for input voltage.
V (volts) .... ADC (peak) 0.3 ....... 1600 0.4 ....... 2000 0.5 ....... 2500 0.6 ....... 3000 0.8 ....... 3700
The numbers are averaged "by eye", so not very precise.
Next, I took some runs in PULSE INTEGRAL mode where I varied NSB and NSA (number of samples before and after threshold), and I also varied the voltage, and the PULSE INTEGRAL appeared to be linear in these. I need to do this more carefully, though.
There is a data synch problem: Some data may appear in run N from a previous run N-1. However, if I made the change (e.g. to the voltage) near the end or run N-1, the change appears in run N. Also, downloading seems to clear things. I need to characterize this problem some more. It could also be a software problem.
The good news from Kalyan's test : 36 usec for DT of the long read (BUFFSIZE 100) implying a greater than 1 MHz potential performance. And since the data now makes sense, I'm feeling better.
Date : 21 Nov 2012 (K. Allada)
- The new TI library is in /root/linuxvme/ti/ and the readoutlist is at /root/linuxvme/ti/rol/vme_list.c
- I added fadc readout to the the vme_list.c. Just do "make" to compile.
- A new CODA config is created. "NewTI" config uses vme_list.c (contains both TI and FADC readout)
- I got the FADC to work with new TI. However, at the moment, the readout is done using BANKS (BANK 4 = TI, BANK 6= FADC).
- Blocking mode works. Set the block size using BLOCKLEVEL
- There are some DMA error/warnings if the BLOCKLEVEL is too high. Need to fix this.
- I didn't get a enough time to do careful study of deadtime etc..
