Hank noticed some adc = 0 pedestals, so I have dug into the issue a little deeper.  All of the pedestals taken for the epd for Run 18, Run 19 and Run 20 can be found at:

drupal.star.bnl.gov/STAR/system/files/EpdPedsRun18.pdf
drupal.star.bnl.gov/STAR/system/files/EpdPedsRun19.pdf
drupal.star.bnl.gov/STAR/system/files/EpdPedsRun20.pdf

Hank picked out EQ2 BD10 CH16, EQ2 BD13 CH17 and EQ2 BD14 CH10 as having 0 pedestals.  All of which are QT32Cs.  No other channels seem to have this problem.

There was some discussion whether this was related to the EPD Cold Tile issue noted earlier (for a detailed analysis, see: drupal.star.bnl.gov/STAR/blog/rjreed/epd-cold-tile-issue), but that was mainly the result of the algorithm change in trying to incorporate the QT32B boards into the trigger algorithm, so it is unlikely these are related.  Skipper was also looking at some issues with calibration, where we would see a giant spike in the middle of the data (see drupal.star.bnl.gov/STAR/system/files/Kagamaster_EPD_14p5_Calibration_Final.pdf) but it doesn't seem like this is related to that.

For example, in his calibration of the 14.5 GeV data (Run 19) he saw the issue of a second spike in EW0 PP3 TT28 (which is  EQ2 BD0 CH20).  Looking at the pedestal, we actually can see that this is not a great channel.

Figure 0: EQ2 BD0 CH20 From Run 19.  It was also having this back and forth movement between values in Run 18 as well, though less problematic.

Looking at the first channel that Hank noted (corresponds to EW0PP7TT6).

Figure 1: EQ2 BD10 CH16 Run 18

Figure 2: EQ2 BD10 CH16 Run 19

Figure 3: EQ2 BD10 CH16 Run 20

For EQ2 BD13 CH17 (EW0 PP3 TT3), Run 19 also had a nearly 0 pedestal, and Run 18 was very flaky (which for this channel meant that different pedestal runs could have drastically different results, but the sigmas didn't look too bad).  For EQ2 BD14 CH10 (EW0 PP6 TT4) it also had this flaky behavior in Run 18, and then Run 19 it just slowly decreased to 0.

The question then is - does this matter (for these 3 tiles)...

For additional checks, Jeff took run21168008 with CAMAC ON (pedAsPhys) and run21168009 with CAMAC OFF (pedAsPhy).  For some reason, running on the *.dat file for 008 showed some strange corruption, so I called the control room and had them run another pedAsPhys run to compare. This run is 21168041.

What was noticed is that all channels seem normal with the CAMAC off, but have strange values regardless of the vped or vbias.  So I did a vped scan using pedestal rhic clock clean (instead of pedAsPhys - the pedestal subtraction confused me).
21168049 vped -20
21168050 vped -10
21168051 vped 0
21168052 vped 10
21168053 vped 20

21169001 - default
 
The results can be found at:
drupal.star.bnl.gov/STAR/system/files/VpedOut06172020.pdf
Or a zoomed out version:
drupal.star.bnl.gov/STAR/system/files/VpedOut06172020ZoomOut_0.pdf

drupal.star.bnl.gov/STAR/system/files/VpedOut06172020ZoomOut_0.pdf
EQ2 BD10 CH16, EQ2 BD13 CH17 and EQ2 BD14 CH10 are EW0 PP7 TT6, EW0 PP3 TT3 and EW0 PP6 TT4

Figure 4: Black points are the pedestal mean vs vped value.  The red point is the CAMAC off point.  We see here that for all of these channels, the vped value would be high.

21170028 - pedestal with new settings (For the channels going beyond +/- 100 I put them at 100.

The results look at the pedestals are: drupal.star.bnl.gov/STAR/system/files/VpedOutCheck06182020.pdf
Unfortunately these were a little strange, the blue points indicating where the pedestal was with the "new" settings seems to be quite some distance from where it should be (the red point for CAMAC off).  There are 2 things that could have caused this, something came up when the run was originally taken so that there was 20 minutes between when Jeff turned the CAMAC off and took the run.  Secondly, there was not much space in between runs, so the beam had started to come back before the pedestal finished.  But to look at our 3 tiles:

Figure 5: Our 3 problem channels after the change - the blue points are the recent pedestal taken after the change.  But there was a problem...

Figure 6: ADC spectra from the online EPD viewer.  These 3 channels had no in-time hits.  (EW1PP4TT6 shown for comparison)  Mike's thought is that changing the vped to be positive means that we don't pass the threshold and fire the discriminator.

21170032 - pedestal revert - Problem went away with the values used at the start.

21170034 - pedestal only changing 3 problem channels to vped = 20 - This at least gives non-zero values for the pedestal for the 3 problem tiles.

My notes from Run 20 are:
EQ1BD6CH24,CH25,26,28,30,31 (27 has a little discontinuity) step function (QT32B)
EQ1BD7Ch30,31 look messy (QT32B)
EQ1BD14CH4 Looks dead? (QT32C)
EQ1BD14CH20 Starting to get flaky (QT32C)
EQ2BD9Ch0 - Rising value (QT32C)
EQ2BD9Ch18 - Falling value (QT32C)
EQ2BD10Ch3,4 - starting to get flaky (QT32C)
EQ2BD10Ch16 - ped = 0 (QT32C)
EQ2BD13Ch1,3 - Flaky (QT32C)
EQ2BD13Ch10 - Rising value (QT32C)
EQ2BD13CH17 - ped = 0 (QT32C)
EQ2BD14Ch1 - Rising value (QT32C)
EQ2BD14Ch8,9 - Starting to get flaky (QT32C)
EQ2BD14Ch10 - ped ~ 0 (QT32C)
EQ2BD14Ch18 - falling value (QT32C)
EQ3BD0CH25 - rising value (QT32B)
EQ3BD0CH31 - Flaky (QT32B)
EQ3BD3CH8 - Died? (QT32B)
EQ3BD3CH9 - Step func (QT32B)
EQ3BD3CH29,30,31 - Flaky (QT32B)
EQ3BD4CH9,10 - Starting to get flaky (QT32C)
EQ3BD4CH14 - Sometimes very flaky (QT32C)
EQ3BD4CH16,17 - Starting to get flaky (QT32C)
EQ3BD6CH0 - starting to get flaky (QT32C)
EQ3BD6CH9 - starting to get flaky (QT32C)
EQ3BD6CH18 - starting to get flaky (QT32C)
EQ3BD9CH8 - Increasing value (QT32B)
EQ3BD9ch18 - Flaky (QT32B)
EQ3BD9CH24 - Flaky perhaps (QT32B)
EQ3BD13CH2 - Flaky (QT32C)

I should remember I have macros at: drupal.star.bnl.gov/STAR/blog/rjreed/epd-macros