Directory "1" contains the logs from a set of tests:

	(1) started on 2 crate system after the following had been sent via bsh:

	SI.getSctApi().setDebugOption("api_config_cache_check");
	SI.getSctApi().setDebugOption("module_config");
	SI.getSctApi().setDebugOption("api_config_cache_send");

	(2) started in the order of a char seq, but one at a time by hand:

	    return tl->getTestRequestByName("NMask");
	    return tl->getTestRequestByName("FullBypassBarrel");	    
	    return tl->getTestRequestByName("Pipeline");
	    return tl->getTestRequestByName("StrobeDelay");
	    return tl->getTestRequestByName("ThreePointGain");
            return tl->getTestRequestByName("TrimRange");
	    return tl->getTestRequestByName("ResponseCurve");
	    return tl->getTestRequestByName("NoiseOccupancy");
	    return tl->getTestRequestByName("TimeWalk");

	(3) Notes:
		* NMask pass except mod 28 has problem on just one channel
		* FB and Pipeline pass
		* All raw data returned by Strobe delay looks fine, but AnalysisService seems to mess up and empties every histogram :(
		* 3pt gain looks reasonable but very noisy and fails
		* TrimRange - passes with probs
		* Npt gain fail -- modules too noisy again
		* Noise Occ pass
		* Timewalk pass

	(4) It proved possible directly after doing the above, to run the whole lot again, this time as an "automatic" (not "manual") char seq.  The same results were obtained, though they are not represented in dir "1".

	(5) As an afterthought I ran the whole lot again, but this time logging mrs output to mrs.out.  I have added this file to the "1" dir.  It is unfortunate that it's scan numbers will be out by a constant amount from the values in the first run.

----------- Directory "2" ------------------

	In the light of AJB's patches of around 5.30pm 1/6/2005 I have
	recompiled and run again with options

	SI.getSctApi().setDebugOption("api_config_cache_check");
	SI.getSctApi().setDebugOption("module_config");

	I am still seeing CONFIG discrepancies ... and the logs will
	be copied to dir "2" as soon as they are ready.

----------- Directory "3" ------------------

Alan then discovered a small problem in SctApiHist.cxx which was
separately patched becoming ver 1.138.  With this change compiled in,
NMAask and FB run without CONFIG discrepancies, but then at the end of
the FB the modules are no longer returning events on link0 again. :(
See logs in the "3" dir.

----------- Directory "4" ------------------

With HEAD of the morning of 2005/06/02 (designed to be the first test
of Alan's recent mod to SctApiRaw.cxx making ver 1.54) with 2 crates
and the debug options:

     SI.getSctApi().setDebugOption("api_config_cache_check");
     SI.getSctApi().setDebugOption("module_config");

and running:

    RxThreshBasedConfigReg
    NMask
    TXCurrent
    NMask
    StrobeDelay

I see everything running smoothly UNTIL the StrobeDelay.  The
StrobeDelay data itself looks "reasonable", but StrobeDelay reports a
number of yellow warnings to MRS saying that the Config CACHE and the
copy on the ROD have been found to differ.

----------- Directory "5" ------------------

Using HEAD of about 6:05pm 2005/06/02 and with two crates and setting
the following debug options

     SI.getSctApi().setDebugOption("api_config_cache_check");
     SI.getSctApi().setDebugOption("module_config");

and doing without HV:

    StrobeDelay
    NMask
    FullBypass
    NMask
    CharacterisationSequence
    RxThreshold
    FullBypassBarrel
    TxCurrent
    RxThreshold
    NMask
    
and then with HV:

    CharacterisationSequence

there were no yellow cache discrepancy messages and everything ran as
well as I am able to tell that it could run.  There are still
multicrate-pending-issue-yellow-messages (not mentioned before in this
README file but always present -- see "Multicrate
issue pending further information" in SctApiServer.cc) but now ONLY
these messages.  There seem to be few issues (if any) remaining with
the config cache.

SHOCKINGLY once the HV had been turned on, every module either passed
every test, or passed with a "problem" so the calibration actually
seems to do what it is supposed to do.

The three problem-not-pass items were

    (1) Module 28 has a bad channel and this is flagged by the NMask

    (2) Modules 28 and 53 had a large number of untrimmable channels:

	in the case of module 53 they were only on chip S10.  In
	module 28 they were both on S10 and S11.   NB: All modules had
	large negative offset voltages of about -6 mV but this appears
	not to have been grounds for a "problem" tag as module 56 was
	marked as a pass.

[ Case (2) above counts for two items! ]

All in all, things look perilously close to working order!