Front End PAS Reference Data Electronic Format
The data for FE SN12 is included in the XML file "FE12-PAS-refData.xml" and the accompanying text files. This page describes the contents of the file, how to interpret the data, and known problems with the data format, including items which may be subject to change in subsequent releases.
The top-level XML document contains the following elements:
MM Note 2010-01-05:
<FrontEndAltConfig id="401"> <- example of where warm testing config. will go.
We plan to introduce the warm testing configuration at the top-level, as though it were another front end. I've added a sample element to the XML chunk above. The structure of this new element will be identical to the <FrontEnd> element except of course things like serial numbers and ESNs will not be meaningful. Think of this as a fictional front end -- a configuration which we could actually use for multiple front ends.
The <FrontEnd> element
The <FrontEnd> element contains the configuration data for the front end. This includes all data which has normally been provided as part of an INI file.
Within the <FrontEnd> element there are two kinds of nested elements:
- A <component> element describes a sub-assembly of the front end such as the LPR or a cold cartridge.
- A <CartAssembly> element creates a link between two <component> elements which correspond to a WCA and a CCA (and perhaps later will include the bias module.)
Here's the LPR's <component> element:
<component id="3159" type="17" typeDesc="LPR">
Note the following:
- The id="3159" attribute is a database generated unique ID for the component. Test data which refers to this ID is tied to the LPR.
- The type="17" attribute identifies this component as an LPR.
- The typeDesc="LPR" is a human-readable description of the component type.
- The TS element is a timestamp of when this component record was created or modified.
- The Band element is empty as it does not apply to the LPR.
- The SN element gives the human-readable serial number for the LPR.
- The ESN element gives the electronic serial number for the LPR.
- The Description element gives a human readable description for the component.
Now here's a partially-expanded <component> element for a cold cartridge assembly (CCA):
<component id="3150" type="20" typeDesc="CCA">
What's different here:
- The type="20" attribute identifies this component as a CCA and tells your software which reads this to look for the cold-cartridge specific configuration data inside.
- The typeDesc="CCA" is a human-readable version of the type.
- The <Band> element indicates that this is a band 3 CCA.
- The <MixerParams> section contains the mixer and magnet biasing configuration for the CCA.
- The section contains bias values for Pol0 SIS1, etc.
- The <PreampParams> section contains the LNA biasing configuration.
- The section contains bias values for Pol0 LNA1, etc.
The WCA elements are similar to the CCA sections in that they contain special bias and operation data:
<component id="3154" type="11" typeDesc="WCA">
Comments on the WCA configuration:
- The type="11" attribute identifies this component as a WCA.
- The lower and upper YIG oscillator limits are given.
- The operating parameters for the LO PA are provided.
<Description>Band-3 Cart Assembly</Description>
Each <CartAssembly> element creates a link between a WCA and a CCA component:
MM Note 2010-01-05:
- The id="7" attribute is a database generated unique ID. Test data which refers to this ID is tied to this CartAssembly.
- The <WCAComponent>; and <CCAComponent>; included in this CartAssembly are specified. They match the IDs found in component sections above.
- TOFIX: The CartAssembly should contain a cross-reference to the bias module, which in turn should appear as a component record above.
The database structure that we are working with no longer directly supports the notion of CartAssembly
and it would be ideal if we could eliminate this element. However it is possible we could synthesize it from the data structure we do have. What do you think about not having this element and instead relying on the type
attribute and <Band> element within the <Component> elements?
The <TestData> element
The <TestData> element contains the PAS reference test data. It consists of a collection of <TestItem> elements:
<TestItem id="2" type="15" typeDesc="PAS YFactor" dataStatus="1">
<CartAssembly>10</CartAssembly> <- this will go away ???
<Band>9</Band> <- this will be added ???
Things to note about this <TestItem>:
MM Note 2010-01-05:
- The id="2" attribute is a database-generated unique ID for this one data set.
- The type="15" attribute describes what type of test data is contained. See the table below for all defined types.
- The typeDesc="PAS YFactor" attribute is a human-readable description of the test data type.
- The dataStatus="1" means that this is reference data taken with the cold receiver. Warm receiver data would have dataStatus="2".
- The <CartAssembly> element cross-references this data to <CartAssembly id="10">, the band 9 CCA and WCA. See the table below for cross-referencing rules.
- The <FrontEnd> element cross-references this data with <FrontEnd id="12">. This is redundant here but is helpful for human readers.
- The <Content> section contains the Y-Factor data. The formatting within the >Content> tags is custom to this data type.
A consequence of not having <CartAssembly> elements in <FrontEnd> and <FrontEndAltConfig> is that <TestItem> elements can no longer cross-reference to it. Instead we propose to have every <TestItem> specify a <Band> where applicable. See the annotations in the block above. Some <TestItem> blocks do not reference a band so they would only have the cross reference to the id of the <FrontEnd> or <FrontEndAltConfig>. Does this break anything?
Table of data types which may appear in <TestItem> sections:
|| CCA LNA Bias
|| CCA Temp Sensors
|| CCA SIS Bias
|| Cryostat Temps
|| FLOOG Dist Health
|| FLOOG Dist
|| IF Total Power
|| IF Spectra
|| LPR & Pmx Health
|| IF Switch Temps
|| IF Switch
|| WCA AMC Bias
|| WCA PA Bias
|| WCA Misc Bias
|| Y Factor
|| CPDS Monitor
|| Cryostat Rate of Rise
Notes on the above table:
MM Note 2010-01-05:
- The <FrontEnd> cross-reference is included in every <TestItem> in addition to other cross-references.
- The <Component> cross-reference is included for items which pertain just to a single sub-assembly.
- The <CartAsssembly> cross-reference is included for items which involve all the cartridge parts acting together to produce the test results.
- The warm and cold columns indicate which types of data will be taken with the cryostat warm and cold, respectively.
This table will have to be updated with the elimination of CartAssembly
, if adopted.
IF spectrum test data
IF spectrum data is not all included in the XML file but is bundled along with it as text files. The files are tab-delimited and contain only the frequency in Hz and the power level in dBm for each spectral line. The <TestItem> gives meta-data about the files:
<TestItem type="7" typeDesc="IF Spectrum" dataStatus="1">
<Trace channel="IF0" IFGain="15" file="Band 3 Pol0USB.txt" />
<Trace channel="IF1" IFGain="15" file="Band 3 Pol1USB.txt" />
<Trace channel="IF2" IFGain="15" file="Band 3 Pol0LSB.txt" />
<Trace channel="IF3" IFGain="15" file="Band 3 Pol1LSB.txt" />
Notes on the the IF spectrum <TestItem>:
- dataStatus="1" indicates cold receiver data.
- It is cross-referenced to a single <CartAssembly>
- For this CartAssembly at this LO frequency there are four traces, given in the specified files.
Bugs and problems
In addition to the items marked as such above, the following problems are known:
- TOFIX: Only the cold configuration is given in the <FrontEnd><component> sections. Need a way to include the warm testing configuration.