Checking the mapping all the way from TUFF box to StEvent (and muDst)

The issue to be addressed

The Sr90 source tests done by Bill, Prashanth, and Joey tested (and helped find a bug in!) the mapping between the physical location of tiles, and the TUFF box location, as represented and accessed in Wanbing's GUI.

The next mapping to test is to go from "TUFF box to StEvent"  (Recall that StEvent is the data structure used by STAR analyzers to extract data.)  This mapping relies on correct mapping in
  • FEE to Rx
  • Rx to QT
  • QT to StTriggerData object
  • StEpdDb (database)
  • StEpdHitMaker (fills StEpd)
  • StEpdHit (data storage)
  • StEpdGeom (position-space information)
A lot can go wrong here!

Checking the mapping graphically (and numerically)

So, Rosi and I agreed to a game whereby she would
  1. Set all Vbias to zero and all Vped to some reasonable value
  2. Take a pedestal run.
  3. Change Vped on a selected set of tiles so as to give them significantly larger negative DC offset, without telling me what they are. 
    • Also, set Vbias to non-zero for these channels.  While that should not affect the DC offset (hence the ADC values) much, Wanbing's GUI can look at Vbias and make a nice graphic showing "who is on and who is off."  See below.
  4. Take a PedAsPhys run.  In such a run, pedestal is subtracted.
  5. Point me to the resulting data file
Then, my job is to run the STAR Big Full Chain (BFC) on that file, reading the data all the way to StEvent and the muDst.  Then, to loop over the StEpdHits in the StEvent object, applying the StEpdGeom class from the StEpdUtil/ package, and make a picture of which tiles have non-zero ADC values.  These should be the ones that Rosi set in step 3 above.




The Output

It has taken me longer than expected to get the visual result (2:30 AM), so Rosi is now asleep and cannot tell me whether I see the "right" tiles light up.  However by (ahem) close inspection of the pattern, I believe it is correct.......



Or, with labels (which sort of take away from the beauty, so I keep both images here):




There does seem to be a tile missing--PP08TT27-- in the "H" on the East side, so we'll have to look at that.  Also, while the pattern is clearly correct in broad strokes, let's be VERY SURE about the "phase."  We do NOT want to be extracting an event plane that is off by 30 degrees or so...



The input

In the morning, Rosi sent me the "input."  This is the event display on Wanbing's GUI:




The Outlook


I believe that if we can validate this mapping, we can have confidence that the mapping is understood, all the way from physical space to the representation of that space in STAR's data model.






First identified problem : one bad QT channel (?)

The "LEHIGH" pattern test above showed something strange at PP08TT27-- the ADC value apparently did not change when Vped was changed.  To test further, we changed Vped for ALL tiles, and indeed, PP08TT27 is the only bad one:




Joey went to the racks with a scope and watched the changing DC voltage in real time as Rosi changed the Vped values.  The DC voltage for this suspicious channel changed exactly the same as three of his neighbors.  (Vped=0 gave DC offset of +3 mV, and Vped=100 gives DC offset of -40 mV, all measured into 50 ohms.)

Hence, this seems to be a QT problem.  Crate is EQ2, second-from-left slot (address 0x11, apparently), channel 27 (where the channel number starts from zero).

dd