32T Test Plan -Receiver Sub-system (11)
Original Author:
Documentation Number:
Latest Revision Letter:
Latest Revision Date:
David Emrich
46-03001.11
Rev 02
5 January 2010
1 Introduction
The Receiver sub-system crosses the boundary between the analogue RF electronics
domain, and the digital electronics and processing domain. Thus, it delivers the final
stages of analogue RF signal conditioning, and the initial stages of digitization and firstlevel digital filtering. Within the MWA project documentation, this sub-system is variously
referred to as the “receiver”, “receiver node” or “node”, it will be herein referred to as
simply the Receiver. Further, the “Digital Crate” is also somewhat confusingly referred to
as the “digital receiver”, but only the former description will be used throughout this
document.
One Receiver accepts the X- and Y-signals from eight (8) beam-formers located at their
respective antenna/tiles, therefore accepting a total of sixteen analog inputs. It then outputs
the digitized data that will form input to the correlator sub-system for further processing.
Currently there are two parallel output paths. Firstly a VSIB interface carries one 1.28MHz
channel, representing one 24th of the total processed bandwidth, while a Fibre interface
carries the full 24 channels at 1.28MHz each. The VSIB signals allow for a software
correlation test system, while the fibre interface will be used for the full 32Tile hardware
correlation system.
The receiver divides neatly into three sub-assemblies, the front end containing the Analog
Signal Conditioning (ASC) circuits, the Digital Crate, and the support electronics.
The ASC implements the final analog gain/attenuation stages, and pass-band analog filters
designed to block out-of-band signals prior to the inputs to the digitizing system.
The Digital crate consists of three circuit boards, two instances of the Analog/Digital and
Filter Board (ADFB) and one Aggregator/Formatter (AgFo) board. The ADFBs contain the
analog-digital converter chips, as well as FPGA chips that perform the first stage of coarse
digital filtering using firmware Polyphase Filter Banks. Each ADFB processes half of the
16 analog signals input to the Receiver. The AgFo board collects all the data streams from
both of the ADFBs into packets suitable for the correlator to digest.
46-03001.11
Page 1 of 7
Rev 02
The remainder of the receiver consists of support electronics including: power supplies, a
small Single-Board Computer (SBC) for local Monitor and Control functions, and the
control interfaces to the beam-formers, known as the Antenna Tile Interface Module(s)
(ATIM).
The Digital Crate has been primarily designed and built by the Raman Research Institute of
India (RRI), while the remaining electronics was substantially designed and built by the
Australian National University (ANU), both collaborating partners within the MWA
Project.
This Plan is responsive to requirement #11 contained in the memo “MWA 32-T Objectives
and Quality Assurance Evaluation Criteria”, dated 4 Sept 2009 (46-03001.99).
2 References
The design documentation as it stands for the Receiver sub-system is contained in a subtree on the Project knowledge tree at the following URL:
http://mwa-lfd.haystack.mit.edu/knowledgetree/browse.php?fFolderId=58
It should be noted that the various documents in this sub-tree are at widely different levels
of maturity, complicating the test plan at present.
3 Measurement Description
Testing falls into eight (8) major steps as detailed in the following sub-sections.
Verifications fall into the following categories:
Test - gives a numeric response which is compared to acceptance limits.
Demonstration – a “binary” (go / no-go) test.
3.1
SBC operation
Aim: Verify that the SBC boots up on application of mains power, and after allowing the
computer to boot up, complete logging in using SSH over the Ethernet.
Verification type: demonstration
Required inputs: Mains power, SSH username and password
Verifiable outputs: System activity and returned messages from SSH client.
3.2
DC supplies
Aim: Bring up and verify the DC supply rails.
Verification type: Test that voltages and currents are within specification.
Required inputs: commands to enable the power supplies.
Verifiable outputs: status response flags, output rail voltages and currents, and rise times.
46-03001.11
Page 2 of 7
Rev 02
3.3
Beam-former communications
Aim: Verify beam-former communications path.
Verification type: demonstration.
Required inputs: commands to control the beam-former.
Verifiable outputs: text responses from beam-former test command.
3.4
ADFB interface
Aim: Verify the interface between the SBC and ADFBs (test conducted twice, once for
each board)
Verification type: demonstration
Required inputs: commands to load and verify firmware into the ADFB, and the firmware
data file(s).
Verifiable outputs: Firmware checksums and ADFB self-test diagnostics outputs.
3.5
ASC interface
Aim: Verify that realistic power levels and responses can be seen and vary with gain
settings within the ASC.
Verification type: test
Required inputs: commands to control the parameters of the ASC. Suitable noise-source
signal into Receiver inputs (could be the radio-sky via the antennas). Normal operating
firmware loaded into ADFBs.
Verifiable outputs: Noise-Power levels reported by the ADFBs.
3.6
AgFo board interface
Aim: Verify the interface between the SBC and AgFo board.
Verification type: demonstration
Required inputs: commands to load and verify firmware into the AgFo board, and the
firmware data file(s).
Verifiable outputs: Firmware checksums and AgFo board self-test diagnostics outputs.
3.7
VSIB interface
Aim: Verify the VISB interface between the AgFo board and software correlator or DataAcquisition System (DAS)
Verification type: test?
46-03001.11
Page 3 of 7
Rev 02
Required inputs: commands to collect “burst mode” and “channel mode” engineering test
data.
Verifiable outputs: “Waterfall” or other suitable plots/graphs of the collected and processed
data.
3.8
Fibre interface
Aim: Verify the fibre interface between the AgFo board and hardware correlator or DataAcquisition System (DAS)
Verification type: test?
Required inputs: commands to collect “channel mode” (and “burst mode”?) engineering
test data.
Verifiable outputs: “Waterfall” or other suitable plots/graphs of the collected and processed
data.
4 Resources Required
4.1
Staffing
At this stage of development, the Receiver system has not been thoroughly peer reviewed
nor rigorously tested, nor been put under configuration control. Its operation during these
tests, then, requires at specific set of skilled persons on site to conduct the test(s). Particular
skills and knowledge are required in each of the system element domains, ideally this
would be provided by a representative from RRI, Mark Waterson representing ANU and
Frank Briggs as interpreter of the output system plots from the final tests. With practice the
full set of tests are expected to take an hour to complete, per receiver.
4.2
Hardware
To demonstrate the Receiver capabilities we will not attempt to operate under all possible
combinations of circumstance. The following are the minimum set of equipment required:
o One operational generator and functioning environmental control (a/c/) in the
RF screened room that houses the Receiver(s).
o Eight (8) fully operational tiles with beam-formers and interconnecting
cables.
o One Engineering Testing Computer (ETC), probably a laptop, with an
Ethernet port.
o One functioning DAS machine, connected to the Receiver under test (DUT).
o One functioning gigabit Ethernet switch and Ethernet cables.
o Calibrated noise source (or the radio-sky?) to inject into Receiver inputs for
DUT.
o Multimeter and possibly spectrum analyser.
4.3
Software
At a minimum, terminal software is required on the ETC, as well as the various tools
required to display the data captured on the DAS machine. Alternatively if the laptop boots
46-03001.11
Page 4 of 7
Rev 02
Linux, there may be an option to run a GNU window that is displaying the DAS machine’s
desktop, and run the processing and display commands on the DAS machine itself.
The operating system (Linux) and Receiver client software are required to be installed and
configured on the SBC in the Receiver. All the required FPGA firmware files must be
available on the SBC to be loaded into the relevant FPGA devices. This includes the
normal operating firmware images, plus a set of test-signal generation images to drive
known inputs through the Digital Crate.
The DAS machine requires at a minimum the Linux O/S and capture software, but may
also host the data processing and display software.
I’m sure there’s heaps more, but I’m not the best person to specify this.
4.4
Execution Time and Constraints
No other users should plan on getting work done while this test is in process. This testing
will be conducted in an Engineering test mode of the Receiver system, and so it will not be
possible to run other testing or observations concurrently. It is estimated to take a full hour
to complete the testing on each Receiver, and therefore for 32T it could be expected to take
SIX HOURS for complete testing, including setup and clean-up times.
5 Success Criteria
The various success criteria for each of the tests scenarios outlined in section 3 are liseted
below.
5.1
SBC operation
Success is defined as obtaining a command prompt after entering the username and
password into the SSH client login screen.
5.2
DC supplies
All DC supply rails must rise to a voltage and current within specifications, and within the
time given in the specifications. DC rails must maintain their condition during the remaining
testing operations, as long as those further tests are also successful.
5.3
Beam-former communications
To succeed, this test must display properly formatted and correct return-data packets from
every one of the enabled beam-formers in the set of EIGHT attached beam-formers. In order
to cover a fully representative sub-set of all possible operating conditions, it will be
sufficient to test beam-formers in the following manner. First, each beam-former should be
enabled and tested individually to confirm beam-former function, then starting with the first,
continue enabling one more beam-former at a time, observing correct return data packets
from all enabled beam-formers at all times until all eight are observed running
simultaneously correctly.
5.4
ADFB interface
This test will succeed when firmware checksums in the FPGAs match those that were
downloaded (successful FPGA ‘verify’ command outputs), and the listed output from the
ADFB internal diagnostics matches that described in the ADFB documentation.
46-03001.11
Page 5 of 7
Rev 02
5.5
ASC interface
Given measured noise-signal power injected into the receiver inputs, the success of this test
is defined by the fact that the indicated output (square law) power readings from the ADFBs
are within limits defined in the specification. It should be noted that in particular, this
condition must be met for all possible settings/combinations of ASC gain/attenuation. Since
the inputs and outputs for this test could be entirely under the control of the Engineering Test
Computer, the test measurements for each combination of gain/attenuator settings could be
automated, and the final pass/fail result indicated upon completion.
5.6
AgFo board interface
Success here is simply defined by verifying that the firmware checksums match those for the
firmware image files after they are downloaded into the FPGA chips (a ‘pass’ from the
program/verify cycle), as well as a ‘pass’ result from the AgFo board self-test diagnostics.
5.7
VSIB interface
Grabbing at straws here, but the test might well be judged ‘pass’ or ‘fail’ based on a human
expert viewing the “waterfall” plots for proper content.
5.8
Fibre interface
Same as 5.7?
46-03001.11
Page 6 of 7
Rev 02
Revision History
Rev
Ltr
01
02
Date
Author
Description
2009-Sep-29
2010-Jan-05
DJE
RFG
Initial pre-draft
Formatting
46-03001.11
Page 7 of 7
Rev 02