The TDC modules are pipeline units, stopped by a common stop signal. When the common stop is received, all hits (up to 16 edges) recorded by the TDC in the last 16usec are digitized and read out. The TDC reports each edge as an integral number of counts (1 count = 0.5 nsec) relative to the common stop. So, in the most raw data as delivered by the TDC, a lower count corresponds to an edge later in the TDC window, i.e., closer to the common stop.
The TDC also reports the sign of the edge, whether it is a leading or a trailing edge. This sign is tricky, because the TDC determines the sign as it reads out the hits in the channel, in reverse order. This means that starting at the common stop and working backward in the window, the first edge is taken as leading. This is opposite what would be expected by thinking of the pulses in time rather than in TDC counts. At least this is what seems to be the case.
This can be tested by several means. The common stop is delayed by 16usec from the leading edge of the TRG pulse by means of a digital 50MHz (20ns) counter. This means that while the width of the TRG pulse may vary, the leading edge relative to the common stop ought not to vary by more than 20ns.
In fact, Hans found that in examining some raw data buffers read from the Dual Port Memory modules, the leading and trailing edges were reversed. That is, the TRG edge that the TDC reported as trailing, "0" sign bit, had a distribution relative to the common stop with a 20ns overall width. The leading edges, those with a "1" sign bit, had a relatively flat distribution with 50-60ns overall width. The correct pulses were being used. Plotting the width of these pulses yielded a possibly Gaussian (low statistics) distribution ranging from 180-220ns, exactly what Hans measured for the TRG pulse widths using a scope in the mine, averaging over many triggers. A GIF file, courtesy of Hans Berns is available here.
Another test was to look at the relative counts of the edges of the TRG pulse recorded in the TDC. The edge which was reported as "trailing", ("0" sign bit), came within 20ns of 32768 and had a 20ns distribution. The edge reported as "leading", ("1" sign bit), had a lower count by roughly 400 (200ns) and had a 50-60ns distribution. The sharp distribution of the "0" sign bit edges, and the fact that they come close to 32768 strongly indicates that they are in fact the *leading* edge of the TRG pulse. It is the leading edge of TRG that starts the digital delay counter that provides the common stop.
As one final check, Hans also looked at events which have multiple triggers in the TDC window. He checked the lowest 4 bits of the event number which are recorded in spare TDC channels. He found that when the TDC event is read out, the highest event numbers had the lowest counts. For example, if the window contained hits 11, 12, and 13, then event 13 would be found with the lowest count value, indicating it is closest to the common stop. Event 11 would be found around 32768 since it started the delay counter for the common stop. The events would be read out in the opposite order, however. When read out, you get events 13,12,11. The next event read, however is 14. All this is perfectly consistent with the TDC reading out the event starting at the stop and going in order of TDC counts.
So what is the result of these tests? They are good evidence that the actual operation of the TDC is to read out events in the window starting at the common stop with an increasing time count as one goes back in time through the window. Further, there is good evidence that the sign bit is assigned as the data is read out so that trailing and leading edges are reversed. It is clear that what the TDC reports as the trailing edge of the TRG pulse is actually the leading edge.
The TDC data is stored in a circular array with 8 buffers. For each event, the FSCC reads one buffer from each TDC and adds a counter word called the Header & Counter Word to the front. The data is then sent to the DC2 for that quadrant in the central hut VME crate. The DC2 writes the event into the Dual Port Memory for collection by the OD DAQ software. After the data left the TDC, no piece of hardware affects an individual channel's data word, the data is simply transferred as a block of first module, then crate data with no reference to individual hits.
The collector process running on the OD workstation reads the Dual Port Memory modules as a block transfer and packs all 4 DPM blocks into a NOVA buffer along with the VME crate auxiliary data for that block of events. Again, the transfer is done as a block and individual hits are not referenced.
The NOVA buffer is passed to the sorter process where individual events are finally broken out. In the sorter, edges are read out of the TDC data blocks. The sign of the edge is determined by the sign bit in the TDC data. The data for each event is then reformatted as follows.
Each PMT hit is reformatted into a 3 short word record (short = 16 bits). The first short is the channel number defined by (crate*5+module)*96+channel. The 5 online status bits are OR'd into the uppermost bits of this word.
The second word is the time of the leading edge of the hit, i.e. one with a "1" sign bit. The time is determined by (65535 - TDC count). This sets an arbitrary reference point and makes all times monotonically increasing as real time goes on. If a leading edge is missing, i.e., there are two consecutive trailing edges, the time is reported as 0x0000.
The third word is the time of the trailing edge of the hit, i.e. one with a "0" sign bit. The time is determined by (65535). This sets an arbitrary reference point and makes all times monotonically increasing as real time goes on. If a trailing edge is missing, i.e., there are two consecutive leading edges, the time is reported as 0x0000.
An important point happens right here. The output of the sorter is a pmt number, leading edge, trailing edge, where leading and trailing are defined by the TDC sign bit. We have already demonstrated that this sign bit gives the reverse of what is expected. What is called a leading edge is actually the trailing edge of the QTC pulse. The big trick is as follows. By unwritten agreement between Larry's sorter program and John F's reformatter, the second word of the 3 short word block is simply DEFINED to be T+Q, and the third word is DEFINED as T. This effectively reverses the leading/trailing edge again, simply ignoring the earlier definition according to the TDC sign bit. As a result, the arrival time T in the final data is in fact the leading edge of the QTC pulse, and Q is determined correctly also.
The fully built events are handed to the sender process which passes them to the main host as a block, again without reference to individual hits.
After reaching the main host, the event data is again reformatted by John Flanagan's program. The 3 short word structure is maintained, but with different meanings. The pmt number in the 1st word is remapped into the final mapped pmt number, retaining the online status flag bits. The second word is taken as the arrival time of the hit, T. The third word is treated as "Q" and is the width of the pulse found by the difference in the leading and trailing edge times. If the hit had either edge missing (a 0x0000 as the edge time), the bad event bit is set and "Q" is set to zero. If the leading edge was missing, the trailing edge is used as the arrival time so that at least some timing information is available.
The best clue that the correct edge is being used is from laser data taken in mid-april. John Flanagan histogrammed the T0 arrival times and they fit into a nice 20ns wide box. T0 in the final data is the leading edge time T of the TRG pulse edges as recorded by the TDC. It is the same measurement that Hans did above, but taking the data out of the stream after the main host reformatter. The result clearly indicates that T is in fact the correct edge time and the accuracy is limited by the digital delay counter for the common stop. If the edges were reversed, then T0 should reflect the arrival of the trailing edge of the TRG pulse which is known to vary by more than 60ns.
The reformatter program source code can be found in sukai09:/skam/pro/src/skrd/anticalsk.c
