Feb 2013
Date : 6 Feb 2013 (K.Allada)
We are now using the new FADC(v2) and a fixed pulser.
I did few more checks to find out why we are getting "data not ready" errors at trigger rates beyond ~250KHz (with PTW =75 samples). This is related to datascan becoming zero for few-tens-of-events/100 triggers, and this becomes worse as we go to higher trigger rates. When this happens the event is empty. And since we do blocking, we get a empty blocks. Blocksize is 100.
Also, note that the theoretical limit (from the excel sheet) with PTW=75 samples and FADC v2 is around ~430 kHz. We should be able to take this much rate with a fixed pulser.
From the routine tiSetTriggerHoldoff(1,40,0), the trigger limit, without additional deadtime, is 40*16=640ns (= 1.56MHz). So this is fine...we are not there yet.
Below is a table showing observed data rate from the Run Control GUI for different trigger rates. It seems like the data rate is saturating at ~5K Bytes/sec ( which is around 250 KHz) and that's when the datascan becomes zero (error).
run trigger rate observed event rate observed data rate error condition 1910 31 kHz 31 kHz ~600 Bytes/sec no error 1909 85 kHz 85 kHz ~1500 Bytes/sec no error 1908 121 kHz 121 kHz ~2200 Bytes/sec no error 1907 168 kHz 168 kHz ~3000 Bytes/sec no error 1906 251 kHz 251 kHz ~5000 Bytes/sec no error 1905 315 kHz 315 kHz ~5200 Bytes/sec error 1904 434 kHz 434 kHz ~5200 Bytes/sec error (Note added by Bob: actually, these are kBytes/sec. The rcgui reports incorrectly Bytes/sec.)
To check if disk is a limitation, I turned off writing to disk in the coda config. And I still see these errors. So disk may not be an issue. (adaq1 has 1.1 GB/sec speed)
Next is the network. We have 100MBits/sec (12.5 MBytes/sec). How can we max out at 5K Bytes/sec? How can I turn off transfer through the network (instead write to local memory) to check the limitation?
I tried this by replacing dma_dabufp in faRead() with dummy pointer to local memory, but I could not make it work yet. I am still seeing these errors (although now the raw data contains full of 0x000000s)
Date : 7 Feb 2013 (R. Michaels)
Info about network speed.
According to Brent Morris, we have gigabit between adaq1 and hallasfi1, so I think network should not be an issue. To check this, I tried turning off writing to the network.
Recommended procedure is to do this:
// dma_dabufp += nwords;
which allows DMA transfer but doesn't put data to network.
We see the same problems as before. About 1/3 of events have 0xda00bad2 in the datastream, and the printouts "ERROR: Data not ready in event".
Observations at high rate in integral mode:
Input 342 kHz in scalers Busy output 3420 Hz in scalers. This is also the "In-EvtRate" in the Run control GUI. Block size 100 ... implies 100% livetime since 100*3420 = 342 kHz (don't believe it, though) xcefdmp shows normal events with about 518 words or 2072 bytes. but some events with less bytes and about 1/3 of events empty (0xda00bad2 flag). Assuming 2/3 events have data, then expect a data rate = 2/3 * 3420 * 2072 bytes = 4.7 MBytes/sec. I would conclude tha the "In-DataRate" field is kBytes/sec, although the histogram Y axis is labelled Bytes/sec.
K. Allada:
In the readout list a flag is added on the top to change the mode(RAW,PUSE INTEGRAL) of FADC250. You just have to change it and rest is taken care.
#define FADC250MODE 3 /* mode 1(RAW) 3(PulseIntegral) */
The data rate histograms on coda run control are kB/sec and not bytes/sec as it indicates (its a bug!) Found that at high rates (> 250KHz) the fadc is skipping events. The trigger counter from the fadc sometimes increments by 25. And this number seems to be constant, always 25.
Date : 20 Feb 2013 (R. Michaels)
Getting ready to test the helicity-correlated asymmetries with the new FADC DAQ. I've set up the helicity board and set up a NIM circuit to generate signals with an asymmetry and rate that is tunable. At the moment we can get 200 kHz < f < 2 MHz and 0.1% < A < 4%. Note, A and f tend to be anti-correlated.
Info about helicity board (halog 385791) http://hallaweb.jlab.org/halog/log/html/1302_archive/130214131309.html
Info about asymmetry generating circuit (halog 385793) http://hallaweb.jlab.org/halog/log/html/1302_archive/130220124926.html
Date : 21 Feb 2013 (R. Michaels)
Noticing that the DAQ was unstable in RAW mode, I let the BLOCKLEVEL be adjustable based on the FADC250MODE. For 1 (RAW) BLOCKLEVEL is 1, and for 3 (pulse integral) it is 100. This made the DAQ stable as it doesn't require too much memory. In addition, the minimum event size is observed to be MAX_EVENT_LENGTH = 1024*250. We also have MAX_EVENT_POOL = 200, though I guess this could be increased now.
The helicity bit was plugged into channel 9 and this channel enabled. BTW, it seems channel 8 does not work. I see the bit go on/off in the data. Will try to measure an asymmetry. Run 1997 is a longish run (10 min, 50K events) to hunt for an asymmetry.
What to expect ? The signal is 150 mV into the V2F with a 30 mV modulation from helicity. Given the V2F calibration f (kHz) = 200 + 210 * V, we expect about a 1.3% asymmetry on a nomimally 235 kHz signal.
Date : 25 Feb 2013 (R. Michaels)
Today I managed to find an asymmetry in the FADC. Some problems before (apart from really dumb problems) : double pulsing going to FADC and significant deadtime ("ERROR: Data not ready in event xxxx"). The former was cleaned up by adding more modules and using discriminators, and the latter (DT) is rather fatal -- it dilutes the asymmetry more than I'd expect ! I expect A_obs = A_true * (1 - DT) where DT = deadtime, so DT is effectively a dilution.
Observations of rates Case ... Signal source to V2F .... rate (kHz) ... comment A ...... nothing ................. 192 ........... pedestal B ...... NIM-true DC level ....... 138 ....... subtracts from pedestal C ...... TTL-true DC level ....... 256 ....... adds to pedestal D ...... NIM-helicity signal ..... 192 and 138 observed, helicity-dependent, average 161 E ...... Add TTL-true to above ... 192 and 250 observed, helicity-dependent, average 227 F ...... We can add a random pulser to any of these cases, f > f_case. Observed asymmetries Case ...... Deadtime ? ..... Expected A ..... Observed A (in data) A, B, or C ..... none ........ zero ........... zero D .............. none ........ 17 % ........... 20 % E .............. none ........ 13 % ........... 14 % F with 126 kHz .. YES ........ 8 % ............ 0.6 % !!!! F with 17 kHz .. none ........ 11 % ........... 10 %
The errors in A are around 1 or 2 %, I guess. I don't know how much deadtime was in the 4th test, nor do I know yet why the dilution is so big. Pretty good start, though. With no deadtime, the system makes some sense.
Later, I learned to measure f+ and f- (for + and - helicities) but looking at scalers with a NIM-true added to the V2F input (+) or not (-). This gives more precise predicted asymmetries. I also dilute the asymmetry using a random pulser to achieve a range of asymmetries. Results:
The sign of A is negative, and this agreed between data and prediction, but I show absolute value. A = (f+ - f-)/(f+ + f-), and take abs. value. Run .... f+ .... f- .... A predicted .... A observed (sign agreed) ....... (kHz)... (kHz) 2034 .. 118.5 .. 128.6 .... 4.1 % ........ 4.0 % 2035 .. 193.0 .. 128.6 .... 20 % ......... 20 % 2036 .. 224.6 .. 169.5 .... 14 % ......... 17.6 % 2039 .. 290.4 .. 235.1 .... 10.5 % ....... 14.4 % 2040 .. 226.2 .. 216.4 .... 2.3 % ........ 1.8 % 2041 .. 292.3 .. 282.4 .... 1.7 % ........ 1.5 % Notice that for runs 2036 and 2039 the observed Asy is higher than predicted, while for runs 2040-41 it's lower. Thinking ....
Date : 26 Feb 2013 (K. Allada)
There are two kinds of trigger losses in FADC at high rates (> ~250 KHz)
1. FADC can lose triggers within a block (usually trigger counter skips by 25 counts, it happens few times within a block) 2. FADC can lose an entire block (that means block_size of triggers get lost, and you get messages like "ERROR: Data not ready in event xxxx")
The deadtime calculation should take care of these two cases when this happens.
I checked two runs 1904 (434 KHz with DT=89%) and 1905 (315 KHz, DT=59%). Seem too high!
