Jan 2013

From Hall A Wiki
Jump to: navigation, search

Date : 2 Jan 2013 (R. Michaels)

After a 2 week vacation ....

Prior to X-mas, I wrote some code to decode and plot data for the block mode. I'm not completely done yet, however.

Also, Chris Cuevas gave me a Random Signal Source Module. It was a prototype built in 2002 by Fernando Barbosa. A small VME library exists from Hall B (Serguei Boiarinov and Sergey Pozdnyakov) and is presently on ~adev/vme/rpulser. I tested the outputs. There is a random output which, I think, is supposed to follow (at least roughly) the synch output in frequency. Some documentation from Fernando was put into the code. However, the module seems to not work well. I have sent these data to Chris and Fernando. Maybe they will have an idea for how to fix it.

The 2nd channel appears to have a synch output whose frequency matches expectation, but the random output is low and appears to "saturate" at about 1 kHz. Using the scope triggered with infinite persistence, it does seem as though the random output is random in time (= good and expected). 

Observed frequencies (Hz) versus 16-bit register versus what it should be

register  source A (chan 1) source B (chan 2)   "should be"
           synch  random     synch  random       synch  
       
Low Range
0xc075     21.6   16.4       22.8   15.3         22         good

0xc339     428    111        440    208          400        ok

Mid Range
0xa08a     25     17         2030   755          2K    chan 1 not working

0xa100     157   108         12.5K   922        12K     

0xa392     434   126         34.3K   967        33K     random output is
                                                         saturating 
High Range                     
0x601f     7.3   8.1         51.6K   965        50K

0x604d     14.9  11.3       102.3K   959       100K

0x63ff     449   129       2.89MHz   530      3MHz

Date : 2 Jan 2013 (R. Michaels)

I made some progress on my decoder for block readout. In ~adev/fadc/bob_decode It fills histograms like number of samples, number of events, snapshots of events (for raw mode), and integrals (for pulse integral mode), etc.

See halog 385750. http://hallaweb.jlab.org/halog/log/html/1301_archive/130102161435.html

Clearly, there is an optimization needed for the threshold. Also, I think the window timing was not right, since for run 1592 I don't see pulses in the window.

Date : 3 Jan 2013 (R. Michaels)

Today I carefully setup the timing in the TI mode and using my new software in ~adev/fadc/bob_decode. Some pictures and results are shown in halog 385751 http://hallaweb.jlab.org/halog/log/html/1301_archive/130103153652.html

Next, I checked how the DAQ deadtime (or livetime) depends on rate. While some features of the pulse-integral distribution are not understood, they appear to be invariant wrt rate. See halog 385752 http://hallaweb.jlab.org/halog/log/html/1301_archive/130103155233.html

It would be nice if we could post pictures here on the wiki; that's why I use the halog.

Next, we need to understand the pulse-integral distribution in more detail and we should try to find/borrow/scrounge a random pulser that goes to 1 MHz.

Date : 4 Jan 2013 (R. Michaels)

If the pulses are stable, the pulse integral distribution should be narrow. It wasn't yesterday. After some investigation, I found that this is a property of the pulser (or the downstream electronics) and is affected at high rates. At low rates the pulse integral is clean.

Halog 385754 http://hallaweb.jlab.org/halog/log/html/1301_archive/130104140402.html

But the TIME data seems peculiar. Here are some runs to check 

run     mode     threshold

1631    integral   1500
1632    raw
1633    integral   1000
1634    integral   500
1635    integral   300
1636    integral   100  (in the noise)
1637    integral   1000
for run 1637, near event 52 (seen on GUI, so ~5200) I unplugged cable to FDC and inserted 15 nsec to calibrate TDC.  Then at 
event 152 (seen, so 15.2K), I removed the 15 nsec and replugged cable.
1638    raw

Analysis of this is shown in HALOG 385755 http://hallaweb.jlab.org/halog/log/html/1301_archive/130104152816.html

It seems the TDC resolution is about 3.8 nsec (I guess 4 nsec is from 250 MHz), so this is ok. Also, the fluctuations in TDC are presumably due to the noise in the setup. Indeed, one can see these fluctuations in the RAW mode and on the scope. So, everything looks ok.

Date : 7 Jan 2013 (R. Michaels)

Today I got a random pulser from D. Abbott and repeated my scan from the other day. The livetime is 100% below about 500 kHz, then drops above that.

See halog 385756 http://hallaweb.jlab.org/halog/log/html/1301_archive/130107162055.html

(Note added Feb 5: Later we realized this was wrong. The max rate is about 250 kHz. See Kalyan's notes below.)


Date : 24 Jan 2013 (K. Allada)

  • Based on the Excel file that Bryan provided there is theoretical limit on sustained trigger rates that can be achieved using FADC. I wanted to test this limit by varying the parameters: number of samples (WINDOW, also PTW), number of pulses in the window (currently fixed - one pulse), NSB and NSA. The last two are not very sensitive.
  • This limit will tell us what we can expect from the FADC in terms of rates.
  • Few of my observations on the current setup (I used the random pulse generator for these tests):
    • In PULSE MODE with PTW (WINDOW)= 80, the max coda rate obtained ~250 KHz with ~0% deadtime. Note, the deadtime was crudely calculated by observing CODA rate vs input trigger rate. The theoretical limit for this setting is about 420 KHz. So, something doesn't make sense.
    • If the input trigger rate is > ~250 kHz there is a different problem - the "datascan" becomes zero and we get errors such as "data not ready" for every event. When this happens, basically we get empty events.
    • We can avoid these errors happening at high rates (I tested up to 275 kHz) by using tiSetTriggerHoldoff() routine at the expense of additional deadtime. For eg: For an I/P trigger rate of 275 kHz I set the arguments such that it accepts no more than 4 triggers in 2*500ns=1000ns window. This gave me ~40% (crude) deadtime (based on coda event rate that I observed). And datascan doesn't become zero.

Date : 29 Jan 2013 (K. Allada)

Yesterday Bob, Alex, and myself swapped the old crate that has out setup with the new VXS crate. Also, we swapped the old FADC(v1) in our setup to the new production version (v2) FADC.

I put connected back the trigger setup and it is working as of now. I can see the pulse in raw mode ( with some help from Bob on decoder). Tomorrow I will check the pulse integral mode to get see if everything makes sense.


Date : 30 Jan 2013 (K. Allada)

http://hallaweb.jlab.org/halog/log/html/1301_archive/130130171711.html

  • Following are the current settings:
    • PL(Latency) = 230, PTW (WINDOW)=75 and BLOCKLEVEL = 100
  • With these settings I can reach 250KHz with negligible deadtime (confirms what I observed with old FADC). Beyond this rate I get "Data not ready" errors (datascan becomes zero).
  • I found a routine to set pedestals but it is not working at the moment - faSetChannelPedestal(FA_SLOT,12,1000.) should set threshold of 1000 on chan=12, but it is not working.
Retrieved from "https://hallaweb.jlab.org/wiki/index.php?title=Jan_2013&oldid=17801"