The method of this test is as follows:
- Configure modules to return the content of the ConfigurationRegister?. This ensures that a constant data packet is returned in response to each L1A trigger, give or take the L1A and BC counters (which we don't read anyway).
- Enter the main loop
- Set RX Threshold
- for(i=0, i<n, i++)
- send L1A
- trap raw event in ROD's input FIFO
- read it out in software
- histogram in software (SctApiRaw?.cxx)
- Analyse the "toothbrush" pattern for each datalink to determine the upper and lower bounds for which the pattern is received reliably (in other words, the region for which "slices" through the histogram contain only the values 0 and n, nothing in between
- Set the RX threshold of each datalink to a value 3/4 of the way between the lower and upper bounds.
This test outputs:
- The minimum threshold at which the communication works.
- The maximum threshold " "
- The best threshold
- New: The risetime of the light output of the VCSEL. Long risetime is reported by TW to be a good indicator that the VCSEL might be close to the end of its days.
Recent upgrade
- Since Dec2005, we now return a slightly different pattern on odd and even datalinks, to give a better indication of OpticalCrosstalk?, which may occur if the Infineon connecors are not seated correctly. (Chips 0->5 are set to have the calmode, compression and trim range set to '2', while chips 6->11 are set to have these registers set to '1'.)
Here is a pretty picture of the kind that you see when you have just run a NEW FANGLED successful RxThresholdBasedOnConfigRegisterTest
Here is a pretty picture of the kind that you see when you have just run an OLD STYLE successful RxThresholdBasedOnConfigRegisterTest
Update July 2006 For Endcap People or anyone who reads out through only one link a lot
Updated the analysis to cope with situations like that shown in the following picture in which the config register return exceeds the length of the sampling window:
Now we allow the return to be clipped, so long as at least one payload (one chip) is seen. If we run out of return part way through a chip payload, we do not look for a trailer. The analysis ought not to fail if the break were to occur EXACTLY at the point between a trailer and the last packet, but this hasn't explicitely been tested. Should be OK, though, I think. Chris