After a few subtle software mysteries were solved, we've finally finished processing the M1 to M1 transfer function data taken last Tuesday on BSFM01, mounted in the assembly test area. Though the measurements do not exactly match the model*, everything looks qualitatively excellent, and I therefore approve that X1 BSFM 01 is ready to move over to mate with H2 ISI ITMY to become H2 SUS FMY.

Attached are the results (as "alltfs").

* The model was built from previously designed physical parameters, and does not yet reflect the recent changes to get the pitch mode frequency higher. Given that fact, the small discrepancies between model and measurement are understandable. We'll work toward getting a better model. More importantly, LLO is ready to suspend their BSFM, so we'll see how well it reproduces this measurement suite.

Details of the software mysteries:
Mystery #1 - Incorrect model of M1 V to V transfer function.  (see pg 1 of "mysteriessolved")
Up until recently, we had been using the Mathematica-exported Matlab model that was a closed loop, combination MIMO and SISO triple suspension model, that needed simulink to run (see T1000724-v2). In this model only some degrees of freedom were cross-coupled, only some stages had inputs, and sensor noise was included. This resulted in a confusing arrangements of inputs and outputs, so much so that we couldn't find the M1 V to V transfer function, and could only find wha looked to be the M1 to M3 V to V transfer function.
 
However, Mark had developed a fully MIMO triple model in July (with full 6x6 inputs and outputs for every stage plus 6 DOF ground inputs -- just like the QUAD model that we've been using), so I incorporated that into production QUAD-like analysis scripts. Further, because we're interested in open-loop loop transfer functions, I've stripped out all the clunky old Simulink parts. The with the new model, the inputs and outputs are all sorted out and organized nicely, so it was trivial to find the appropriate M1, V to V transfer function.

For the record, this model now lives in 
${SUSSVNHOME}/sus/trunk/BSFM/Common/MatlabTools/BSFM_Model_Production/
in which one should use the wrapper
generate_BSFM_Model_Production.m
which calls the following files
ssmake3MBf.m
    -> triplep.m
        -> BSWIRE2008_Nov.m
    -> symbexport3full.m



Mystery #2 - DC scale factor of ~100 between measurement and model for Pitch DOF.  (see pg 2 of "mysteriessolved")
The BSFM was measured using the exact same electronics (save the OSEMs themselves) as the previous QUADs. Since we haven't measured and compared any other degrees of freedom on the BSFM besides pitch to the model, I had been scaling the measurement by 2.7, and assumed this was just "the number" for the BSFMs. However, once I compared the other DOFs, they matched their models quite well (withing 50%) by scaling the measurements by the same factor of 225 used on the QUADs (which in retrospect is obvious). This screamed of some software bug, which after glancing over the OSEM2EUL and EUL2OSEM matrices, I noticed the Pitch matrix elements were quite small (they should typically be the largest coefficients in the matrix). I traced the route of this problem back to the script that calculates / defines these matrix elements, 
${SUSSVNHOME}/sus/trunk/BSFM/Common/MatlabTools/make_susBSFM_projections.m
and found that the distance between the F2F3 plane and F1 had been mistakenly defined to be 0.55 m (half a meter!!) instead of the actual distance of 0.055 m (or 55mm -- see attached). This factor of ten in both the OSEM2EUL and EUL2OSEM matrix explained away the factor of 100. I corrected the script, and repopulated the matrices, retook the pitch measurement, and voila! 
 
The data / xmls for this measurement suite can be found in
${SUSSVNHOME}/sus/trunk/BSFM/X1/BSFM01/BUILD02/SAGM1/Data/110823_1900_X1SUSBSFM01_WhiteNoise_*.xml
Note that the re-measurement of the pitch degree of freedom after the matrix corrections is
${SUSSVNHOME}/sus/trunk/BSFM/X1/BSFM01/BUILD02/SAGM1/Data/110829_X1SUSBSFM01_WhiteNoise_P_0p005to50Hz.xml