After fixing the input LED signal to RAT board by Stephen, we still have not been able to read the correct LED bit from trigger data file. Although run control shows reasonable trigger rate with or without LED being turned on. It is possible that the code was looking at the wrong place in the data file.

The analysis code deduces LED bit from lastdsm[8] array, it previously reads the last entry (lastdsm[7]) and checks if the bit has been set:

(from Select_ADC_QT)

Bool_t LEDevent=false;
UInt_t LEDbit=d.lastdsm[7];
Int_t bc=d.Bclo+d.Bchi*(Int_t)pow(2,32);
      if(Rnum>10000000){
          if((LEDbit)%16>0){
              LEDevent=true;
            }
        }
      else{
          if((LEDbit/2048)%2==1){
              LEDevent=true;
                 if(lastLED!=0 &&((bc-lastLED)%2000001<10) ||(bc-lastLED)%2000001>1999997){
                       LEDevent=true;
                }
            }
        }

But analyzing run12036053 where LED was turned on, I saw the bits of all events were identically 1

and I am not sure if this is the way to find out led bit in Run9

Then I poked around and found the 2009 Last DSM Algorithm :nsac2004.bnl.gov/public/trg/TSL/Software/l1_ld301_2009_g.pdf.

It says FMS-led bit is at channel4 bit0 of the last dsm board. And accroding to Zhangbu and Akio, the new TCU since Run9 has adopted the same inputs as the previous last dsm board, so data structure remains the same. "lastdsm[8]" array in the trigger data file is equivalent to new TCU input.

As a trial, I assumed the order of lastdsm[8] entries is the same as the channels of TCU input. Then channel4=lastdsm[4](another thing is that each entry of lastdsm has 4 bytes, where as each TCU channel only has 2 bytes. Again I assume only the lower 2 bytes are being used). I tried to filter the events by the first bit of lastdsm[4]:

     UInt_t trialLED = d.lastdsm[4];
      ledbit =  (trialLED & 0x0001);

Processing through run12036053, I seemed to get the LED peaks of every cell. Here is a quick look of a single cell:

And the number of entries matches that of the triggered LED events accroding to Runlog

Following attched are the "LED peaks" of every cell, and "LED events(blue line) embedded in physical events"(run12036053)

Need further confirmation if this is the right bit to look at.