FERA data readout

Here are some notes on how data from external detectors are inserted into the regular GAMMASPHERE data stream. The notes are from a setup of the CHICO array; but are generic in nature.

Trigger electronics

The figure below shows the logic of the trigger signals involved:

Sequence of events:

The added signal of all the pre-trigger signals from the 6 VXI crates is send to a discriminator to generate a fast pretrigger signal. The regular GS pretrigger signal is too slow for CHICO, hence this special signal is generated and overlapped with the CHICO trigger. A PLU adds logic to the trigger signal from CHICO. The CHICO and GS overlapped signal generates the "external trigger signal" which is feed to the MTM. This signal makes the MTM start it's wait for a master trigger and forces the MTM to immediately sends out the regular pretrigger signal to all the LTMs.
The MTM pretrigger signal is overlapped with the RF signal to generate a stop signal for the TAC2. This signal is feed to the "ext stop in" on the front of the MTM.
The MTM pretrigger signal is also feed to the FERA/VXI boards "pretrig in". This will start the state program in the FPGA of this board. One of two things will happen:
- No master trigger is received from GAMMASPHERE: The FERA/VXI boards will issue a CLI and all FERAs are cleared. It will also send out a CLI signal on the front panel which is inverted and feed to bit 6 of the MTM external word. In this case it means that bit 6 will be low at master trigger time and thus not pass the mater trigger condition of 64. Therefore, GAMMASPHERE will abort and clear it self.
- The master-trigger is received from GAMMASPHERE: the FERA/VXI board will drive the RDY/BSY signal high which lets the master trigger module know that it's getting data and it starts passing the token to the FERA modules. Since CLI did not go high, bit 6 on the MTM will be set.

Readout

If the master trigger test above was successful, the data from the FERAs are read out as indicated on the next figure:

The FERA/VXI board will wait for a readout request from the fera's -- or time out.
If a readout request is received, the token will be passed and the data from the FERAs will be transferred to the FIFO of the FERA/VXI board
The above process is asynchronous with the regular GAMMASPHERE data collection. I.e., it happens in parallel with the regular GAMMASPHERE data collection.
Once the master readout module has collected and sent the regular data to the event-builder via the fiber optics cable, it will pass it's readout token to the FERA/VXI board. This board will then transfer it's date from the FIFO to the readout module (MRM) via the VXI backplane -- and the data is passed via the fiber optics cable to the event-builder in the data room.
Once all the data is transferred, the two trailer buffers are are transferred to the event builder as well. The first word of the first trailer block contains the external detector word count
It follows that the FERA data is inserted into the regular GAMMASPHERE data stream after the regular GAMMASPHERE data, but before the two trailer buffers.

For more details of the readout procedure consult John Weizeorick's fera_brd.ps document.

CAMAC - CNAF

The branch highway is used to issue CNAF commands for the setup and control of the FERA modules in the CAMAC crate. How that is done is documented here

Pre-trigger setup

The pretrigger conditions should be:

         10    1     1
        255  255   255
              64    64

with "GS+EXT" main and late on and all others off on the "MTM Status and Control" screen. On the "pretrigger logic" screen "ext OR mask" should be on and everything else off.

The two relevant EPICS screens should look as:

In addition to the overlapped particle/GS pretrigger signals, which is the main external pretrigger signal, there is also a scaled down particle singles signal or-ed to the final external pretrigger signal feed to the MTM.

Scalers

Still to be written... I don't know how they work!

Notes and FAQs:

To look at the data stream from the Event-builder, go to one of the active event filter formatters and issue the command: "cesd". You should see something like this:

cesd
03100000   8000    22  4741  4D4D  4153  5048  4552  4521  
03100010    33E   16E   9FB   B5F     0    27     0     0  
03100020   6401  8800  6402  34DE  6403  8801  6404   4BB  
03100030   6405  8802  6406  3002  6407  A010  6408     9  
03100040   6409  1003  640A  33C7  640B  3C43  640C  9811  
03100050   640D   3ED  640E   BA3  640F  6005  6410  9812  
03100060   6411     8  6412  1008  6413  5009    40  8181  
03100070     40  8181    40  8181   D2D     0     0     A  
03100080   57BE  1101     0     0  FFFF  FFFF  8000    21  
03100090   4741  4D4D  4153  5048  4552  4521   366   134  
031000A0    8C1   B07    86    5D     0     0  6401  8800  
031000B0   6402  2C9D  6403  8802  6404  3002  6405  B810  
031000C0   6406     A  6407  1004  6408  2216  6409  2D54  
031000D0   640A  3008  640B  764F  640C  7BD5  640D  8811  
031000E0   640E  6005  640F  9812  6410     8  6411  1008  
031000F0   6412  5009    40  8181    40  8181    40  8181  
03100100    D9D     0     0     A  57BE  1941     0     0  
03100110   FFFF  FFFF  8000    21  4741  4D4D  4153  5048  
03100120   4552  4521   464   15A   992   B48     0    5A  
03100130      0     0  6401  8800  6402  74A6  6403  8802  
03100140   6404  3002  6405  B810  6406     9  6407  1003  
03100150   6408  267B  6409  2B45  640A  3009  640B  727F  
03100160   640C  7CF3  640D  8811  640E  6004  640F  9812  
03100170   6410     9  6411  1008  6412  5009    60  8181  
03100180     60  8181    60  8181   AE9     0     0     A  
value = 1 = 0x1

If you are paranoid, you will want to stop the eff before you do this to avoid having part of the memory overwritten while you look at it. If the memory is updated while you dump, you may see parts of events and become confused. Note: it's a hex dump!

The format of this raw CES memory data is documented here. Here is a quick walk-through of the above example:

An event always tart with 0x8000 and the cesd program will always start from the event header identifier.
0x22= 34 = # no of 32 bit words -1. That is, we should find 70 16 bit words in this event. Inded, that is what I count. The end of the event is marked by the " 0 0 FFFF FFFF" sequence.
The next "4741 4D4D 4153 5048 4552 4521" spells GAMMASPHERE-rtn in ascii. It used to check the consistensy of the data from the eventbuilder.

The last 16 words are the two trailor blocks. Here is what I learned from them:


trailer-1:

  40 pre : bit 6 set in MTM
8181 pre : ??
  40 main: bit 6 set in MTM
8181 main: ??
  40 late: bit 6 set in MTM
8181 late: ??
 D2D     
   0 TAC2 (RF was not connected in this case)

Note: I think something is not right in the header file for
trailer 1. There is more than I what the header file suggests.

trailer-2:
   
   0 user programmable word 1 
   A trigger time ttH
57BE trigger time ttM
1101 trigger time ttH
   0 user programmable word 2
   0 user programmable word 3
FFFF event separator
FFFF event separator

There is not much GAMMSPHERE data in this example. Only one line:

03100010    33E   16E   9FB   B5F     0    27     0     0

 33E  ge high res energy 
 16E  bgo hit pattern and detector ID (det 110 in this case),
      bit # 8 is the ge-bit, it should always be 1 for clean
      data. The upper bits are zero since the BGOs did not fire
      and give a bit patterns.
 9FB  trap signal
 B5F  ge time
   0  side energy
  27  ge low res signal
   0  bgo energy
   0  bgo time

I.e, only detector 110 fired in this example.

The data from the end of the ge/bgo date to the first trailer are from the FERAs. It's easy to recognize the fera data. 32 bits are used for each 16bit fera data/header word. The upper 16 bits of the 32 bit data word is used by the master readout module to give the following information:
```
        bit 31: always zero
        bit 30: error bit
        bits 29-26: dip switch setting
        bits 25-16: FERA word counter
```
in this case we always see the "64nn" as the first part of the 32 bit FERA word and then follows the real FERA data/header word. From the last FERA word we can see that 0x13=19 FERA words were read out. We can also see that the error bit is set (I don't know why!?) and that the timeout switch setting is set to "1001" which is a timeout of about 30usec.
The fera data itself ordered as it was read looks like this:
```
8800 VSN=0, WC=1  
34DE channel  6, data: 0x4DE

8801 VSN=1, WC=1
 4BB channel 16, data: 0x4BB
 
8802 VSN=2, WC=1
3002 channel  6, data: 0x2

A010 VSN=16,WC=4   
   9 channel 16, data: 0x9
1003 channel  2, data: 0x3
33C7 channel  6, data: 0x3C7
3C43 channel  7, data: 0x443
 
9811 VSN=17 ,WC=3
3ED 
BA3
6005 

9812 VSN=18, WC=3 
   8 
1008
5009
```
(The FERA data interpretation has not been double checked). Notice that normally the VSN numbers are loaded so that the VSN numbers have to increase as read out so we can check consistency. Likewise, the channel numbers should come out in order (except 16 which comes out as a zero). The FERA header words are recognizable by their 88xx and 89xx values. Remember that for 11 bit FERAs the data goes from 0-->1919. Overflow is 2047.

Here is a quick run down of the FERA data format as it will look when we use ECL readout.

Be sure to remove the gates from the FERAs when you load them. FERAs that are active usually ignores the CNAF commands that are sent to them.
Be sure to remove the gates from the FERAs when you clear them. FERAs that are active usually ignores the CNAF commands that are sent to them - including the clear signal.
Fera drivers can be cascaded. Simply continue the token and ECL data readout bus (not to be confused with the the data bus from the FERA drivers to the FERAs) to the second FERA driver. The FERA drivers used at GAMMASPHERE are modified in order to allow this cascading. The last FERA driver must be terminated, so you need to identify the module that has been modified for that purpose.
Make sure the requirement of no of clean detectors is set to zero in the EFFs if you want to take particle singles data. (or the EFFS will throw away your data)
The last FERA driver must be terminated. So you need to identify the module that has been modified to do that.
Make sure no gates are given to the FERAs when they are read out. You need to GS-busy gate the gates to the FERAs.

If you find errors in this GAMMASPHERE documentation; please send E-mail to [email protected].