Dataset: p+p 500 GeV, 2011, BHT1 trigger (id: 320501, dsmAdc > 18)
Library: SL11d
Trigger Simulator Library: SL15c + modifications

drupal.star.bnl.gov/STAR/blog/trzeciak/dsmadc-issue-trigger-simulator
Issue: dsmAdc values obtained from the trigger simulator seem to be incorrect for some BEMC towers (additional bands in dsmAdc vs Adc0 distribution with incorrect slope), it looks as if for some towers dsmAdc = Adc0 >> 2, instead of >> 4.
Issue 2: offline DB is outdated, so the online one should be used, but on PDSF only the offline DB is available, which might be a problem in embeddings (depending what information is taken by the trigger simulator for the DB).
-> not sure about all the implications - for sure trigger thresholds are taken from DB, so if using offline DB for the trigger simulator, the list of triggered towers migh be incorrect (if a threshold changed from 2009, which is the case for 2011) - but, I make the decision if a tower fired the trigger by myself, by comparing dsmAdc in a tower with the threshold (provided by myself to the code).
BEMC offline tables on PDSF are fine (at least from 2011), so dsmAdc values should be calculated correctly. The out of date offline DB for the trigger simulator may imply however incorrect trigger thresholds stored in DB - better to hardcode a value of a threshold in your analysis code.
?Issue 3? - additional bands due to dsmAdc overflow - but not a big issue for the analysis since the trigger threshold is below 32.

dsmAdc obtained from the trigger simulator in the following way:

  StTriggerSimuMaker * trigSimu = new StTriggerSimuMaker;
        trigSimu->useOnlineDB();   // trigSimu->useOfflineDB(); - on PDSF
        trigSimu->setMC(false);      // true for embedding
        trigSimu->useBemc();
        trigSimu->useEemc();
        trigSimu->bemc->setConfig(StBemcTriggerSimu::kOffline);   // to get values after calibration

        trigSimu->bemc->barrelHighTowerAdc(towerId);

Modifications to the trigger simulator code that solve the issue:
Trigger simulator code checked out from the cvs in SL15c, then following file modified:
StRoot/StTriggerUtilities/Bemc/BEMC_DSM_decoder.cxx
In function:
     simulateFEEaction(int adc, int ped, int bitConv, int &ht, int &pa, bool
debug) after int adc2 operationBit ? (adc1 - pedestal) : (adc1 + pedestal);
          if(adc2 < 0) adc2 = 0;
And, what solves the "strange towers" issue, is to hardcode the binConv variable:
         bitConv = 2;
This forces adc to be shifted by >> 4. It seems that for some towers binConv value in DB is set to 0, instead 2.

Alternative solution that should work (but haven't been tested) when picoDsts are produced:

simulateFEEaction algorithm:

 int operationBit = ped & 0x10;
  int pedestal = ped & 0x0F;
  int adc1 = adc >> 2;
  int adc2 = operationBit ? (adc1 - pedestal) : (adc1 + pedestal);
  if(adc2 < 0) adc2 = 0; // adc2 = -1*adc2;
  int adc3 = adc2 >> 2;
  pa = adc3;
  if (bitConv == 0) {
    ht = adc2;
  } else if (bitConv == 1) {
    int adc4 = ((adc2 >> 1) & 0x1F) | ((adc2 & 0x03C0) ? 0x20 : 0);
    ht = adc4;
  } else if (bitConv == 2) {
    int adc4 = ((adc2 >> 2) & 0x1F) | ((adc2 & 0x0380) ? 0x20 : 0);
    ht = adc4;
  } else if (bitConv == 3) {
    int adc4 = ((adc2 >> 3) & 0x1F) | ((adc2 & 0x0300) ? 0x20 : 0);
    ht = adc4;
  }

For some towers bitConv = 0 in the database, then dsmAdc value return by the trigger simulator is adc2: operationBit ? (adc1 - pedestal) : (adc1 + pedestal)
In the case of bitConv = 2 (as it should be), the return value is a further modified adc2: adc4 = ((adc2 >> 2) & 0x1F) | ((adc2 & 0x0380) ? 0x20 : 0)
So it should be enough to reproduce this last step in an analysis code, only for the "incorrect" towers.