• Main INDEX
  • Monthly INDEX
  • PREV
  • NEXT
    Make New Entry, Make Followup Entry

    User name R. Michaels

    Log entry time 09:45:03 on March10,2011

    Entry number 351187

    This entry is a followup to: 351172

    keyword=replay warnings in recent runs

    For run 2658 :

    First, a comment about the "standard" warnings. We've seen
    these before. They happen when you are not pedestal suppressing
    and you sometimes (rarely) get 65 words on an ADC instead of 64.
    If you examine the event in detail you should find that two of
    the words from that ADC are identical. No harm done. I did not
    check it this time because I'm too busy and as I said I've seen
    this many times. But you may want to check it yourself.

    21000
    THaSlotData: Warning in loadData: too many data words for crate/slot = 8 9: 64 seen.
    (I think the warning reports last one seen, so 64 is 65th since index starts at 0).

    ====================================

    Secondly, a comment about the "new" disease in ROC10. It looks like
    what happens is that the decoder finds the variable "dt2" resulting
    from the following CRL code. (I think Larry found this also.)

    dt2 = Read3800(0xab8000,1);
    *rol->dabufp++ = 0xdeaddead;
    *rol->dabufp++ = dt1;
    *rol->dabufp++ = dt2;

    And if dt2 has bits in the range of fastbus slot, then
    THaCodaDecoder::fastbus_decode will interpret it as a
    fastbus slot. E.g. in event 176999 near the end of ROC10:

    evbuffer 938 fabb0000
    evbuffer 939 deaddead
    evbuffer 940 8c36a09
    slot slotold model 1 25 1877
    header, wdcnt = 521

    The decoder thinks that 8c36a09 is slot 1 with 521 words in it,
    which is ridiculous. The next word is 8c36a1e and is interepreted
    as first data of that 1877 but chan 97 which is illegal.

    roc 10 slot 1 chan 97 data 27166 ipt 941 raw 8c36a1e device tdc
    THaSlotData: Warning in loadData: channel 97 out of bounds, ignored, on crate 10 slot 1

    The slot and the data are essentially random, resulting from
    this decoding.

    What to do ?

    Well, I was always very careful about putting words into the
    datastream but I didn't write bb_sfi3.crl ....

    E.g. you may see

    output 0xfabc0008

    The 'fabc' makes it impossible to be a fastbus slot (slot number
    too big) and the decoder now knows to skip 8 words. If, instead,
    you put words in a random location in the CRL, wierd things
    like this can happen. And you have to worry about the events
    for which there is no warning, because the decoder will silently
    over-write possibly legitimate fastbus data !!

    However, it should be fixable:

    I suppose we can fix it by skipping, in the analysis, all
    data after "0xdeaddead", which the authors put near the end
    of the ROC10 readout. "0xdeaddead" looks sufficiently unique
    that it may make a good flag.

    Other possible solutions to try:

    1. Remove the new lines in CRL that write these words.
    But I suggest to now scrutinize all this crate's data because
    more stuff like this may be happening. Essentially, the person
    who writes the CRL must also support the decoding !

    2. Put the lines underneath 0xfabc0008 with "8" increased to
    cover the new words. I *think* this will solve it but it
    needs to be checked.

    Ultimately it should be fixable. The 1877 and 1881 have header
    words which tell how much data follows. The 1875 (which we're
    not using) do not have headers, only data, so they are potentially
    more confusing. But from logical consistency we should be able
    to decode ROC10 eventually.