Subject: Re: ECAL anomaly Carol Anne, I have looked at the ecal anomaly that you report. It is caused by the onboard software, or rather by the interaction of the DFEE and the DPE sw, and is revealed by studying the order of arrival of the HK and calibration TM packets. Events are collected by the DFEE are stored in a buffer and transferred to the DPE in chunks of 4 kwords. At the end of each data taking this buffer should be emptied by putting in fillers to reach the 4 kword mark and initiate a transfer to the DPE. However, it is a known, but not well understood, "feature" that this may not always happen (we are not sure if we should blame it on the DFEE or the DPE sw). That leaves some events hanging until the next data taking starts. This may cause trouble in electronic calibration, as the anodeSwitch value put into the packets are not stored by the DFEE generating the events, but rather read off by the DPE from the current setting when the data are received from the DFEE. So if the "hanging" buffer is processed after the anode configuration has been changed for the next electronic calibration the data will have the new value for the anodeSwitch, and not the one active when the data were actually recorded. The quick fix on ground is as you indicate: as long as the amplitude value is not decreasing, then keep the old anodeSwitch setting. my two cents, Søren Carol Anne Oxborrow wrote: > > Dear Sirs, > > while investigating the spurious alerts sometimes produced by j_calib_adc > (the electronic calibration checking program), I discovered something rather > strange in one set of calibration data that had triggered such an alert. > Attached are pertinent parts of the Rev. 167 electronic calibration data: > jmx1.rev167.anodeswitch.all.ps shows how the electronic pulse amplitude (red) > and the anode switch value (blue) vary from line to line in the raw ECAL data. > jmx1.rev167.anodeswitch.detail1.ps is just a detail of this figure, showing > the change over from the second to the third anode segment. There should be > a complete set of pulses with the full range of amplitudes for each anodeSwitch > value. > > In all other cases > of ECAL data I've looked at the change in anodeSwitch occurs exactly where the > amplitude drops to its lowest value, but for this single case, the anode value > switches in the middle of the penultimate series of pulses for the second anode. > > It seems likely that this is just an incorrect report of the value of the anode > switch, but questions arise: where did this incorrect changeover occur? > Onboard or in ISDC Preprocessing? Is it truly a single isolated incident, or > does it cover up a more serious problem either onboard or in Preprocessing? > Shall we ignore it, or should we investigate it further? > > Version 2.2 of j_calib_adc can handle this problem ('if a change in anodeSwitch > occurs without a HUGE drop in pulse amplitude, stick with the old anodeSwitch > value'), so it is possibly academic. However, if there's someone out there > who can explain why this has happened, just once as far as I know, I'd like to > hear from them. > > Best wishes, > > Carol Anne > > .DANISH.SPACE.RESEARCH.INSTITUTE.DANISH.SPACE.RESEARCH.INSTITUTE.DANISH. > Dr. Carol Anne Oxborrow > Email: oxborrow@dsri.dk Homepage: http://www.dsri.dk/~oxborrow > Telephone (direct): +45 35 32 57 33 > Telephone (secretary): +45 35 32 57 01 > Fax: +45 35 36 24 75 > > ------------------------------------------------------------------------ > Name: jmx1.rev167.anodeswitch.all.ps > jmx1.rev167.anodeswitch.all.ps Type: Gswin32 File (APPLICATION/postscript) > Encoding: BASE64 > Description: jmx1.rev167.anodeswitch.all.ps > > Name: jmx1.rev167.anodeswitch.detail1.ps > jmx1.rev167.anodeswitch.detail1.ps Type: Gswin32 File (APPLICATION/postscript) > Encoding: BASE64 > Description: jmx1.rev167.anodeswitch.detail1.ps