The primary objectives for PED are as follows:
It was also interesting to us that the team building the Allen Telescope Array (ATA) had followed a similar approach and built a small prototype array (Rapid Prototype Array) in order to test and evaluate various aspects of their proposed design for the ATA.
By March 2006 approval had been granted for the construction of PED at a vacant area on the grounds of the South African Astronomical Observatory (SAAO). A small out building that had once formed part of a solar transit telescope was dedicate for use as the PED control room. It was discovered that the building had not been entered for around 35 years. Some cleanup work was necessary.
During the second quarter of 2006 design was completed on the antenna controller and the receiver chain was constructed and exercised. Receiver first light (detection of a GPS satellite) happened in July 2006.
Unfortunately many procurement delays plagued us, and coupled with a lack of manpower due to other projects, meant that construction of the first antenna only occured during March 2007. However, much of the site preparation had been done by this stage so construction was relatively quick. A work party of interested individuals was convened and the first dish was completed in a matter of hours.
Another delay followed in which the focus of the KAT team shifted to delivery of our first antenna prototype located at the Hartebeeshoek Radio Observatory. Once this system had been successfully delivered in Dec 2007 some time became available for work on PED to continue. A project manager was appointed and a couple of people made time available to PED.
After completing the hardware phase and performing a number of single dish experiments our first interferometric observations were done. On February 15 2008 we produced our first fringe of the sun, proving the basic operation of the facility.
These antennas were chosen primarily for their low cost (around $250) and their suitability for use at 1.4 GHz. As shipped the antennas come with a basic fixed polar mount. The larger of the antennas has been left as a fixed mount with a Zenith pointing.
The smaller antennas are equipped with an horizon to horizon driven mount from Jaeger. This has a ball and screw jack driven declination adjustment with a geared horizon drive. Coverage is fairly limited with around 90 degrees horizontal and 30 degrees declination.
This layout is shown below (the open circles are snapshot UV points, the closed circles are physical antenna placings):
The baselines vary in length from a minimum of 5m to a maximum of around 40m.
Since part of the PED mandate was to test software we are using on our full scale telescopes the decision was made that the controller should be ethernet enabled so as to fit in with software that was under development at the time. To this end we constructed a controller consisting of a Microchip ENC28J60 Ethernet MAC and PHY, an Atmel AVR Mega microcontroller and a power driver.
A simple UDP communications protocol was implemented that allowed the software to query the mount status and position and accept a desired velocity command for either axis in order to drive.
The plots below show the result of the feed and dish analysis as carried out by the project. Shown is the far field pattern for the combined feed and dish system. It was determined that the optional choke supplied by RAS was not required. (The beam pattern cut is from -180 to 180 degrees)
As we had an HI optimised feed it made sense to use a similarly optimised LNA. We decided on the SLN series from SSB-Electronic which has a 0.3 dB noisefigure, 30 dB of gain and a 40 MHz 3dB bandwidth. At a price of around $300 these represented great value at the time.
These boards are closely linked to the Gnu Radio project which provides a framework for Software Defined Radio (SDR) use. This means that we have easy access to a complete digital receiver and extensive background processing suite.
In its default configuration a USRP board runs from a local 64 MHz XO. With slight modifications these boards can accept an external reference. To generate this we start with a 64 MHz VCXO and a reference 10 MHz signal provided by a Trimble Thunderbolt GPS disciplined rubidium oscillator. Using a Reflock II board the 64 MHz is then phase referenced to the 10 MHz signal giving a very clean and stable 64 MHz clock which is then distributed to the USRP boards.
A fair portion of the operating software is an extension of the work carried out by the CONRAD collaboration under the CTOS (CONRAD Telescope Operating System) project. In particular the CONRAD-SW-0011 document may be of interest.
An overview of the software is shown below (each major component is described in the sections that follow):
Each component that requires control or provides monitoring information runs an SNMP agent that communicates with a host SNMP daemon via an internal protocol known as AgentX. This allows for any number of agents to run on a single host with a single SNMP daemon handling network traffic.
Control commands are issued via a number of SNMP set instructions that configure the parameters for a particular command. The command is then triggered to execute either at a specified time or in an ASAP fashion. Due to this time trigger, real time control of the facility is not required as control can be performed a priori.
Each physical machine in the facility makes a range of monitoring information available via SNMP such as CPU temperature, fan speeds, etc... We chiefly use the IPMI tool to extract system parameters in place of the less reliable lm-sensors package.
Interaction with the system is done via the HELIOS Python libraries which abstract the low level SNMP commands and provide an object based interface for use by the various user interfaces. An LDAP directory is used to store system layout and configuration information which is essential for providing the SNMP abstraction.
Currently PED uses gnuradio 3.1 to handle the capture of the I and Q complex values for the two channels on each board. GNU Radio uses a streams and filters based approach to signal processing and includes a large number of components for manipulation of the input data.
The data capture setup consists of three data capture machines running Debian 4.0, with a single USRP board connected to each. One of the machines is designated the host and the other two slaves. At capture startup the master machine emits a clock reset pulse to the slaves in order to sychronise the sample counters.
The processing software has three components. The first writes the raw I/Q values for each channel, along with a common samplecounter to disk. The second produces the real time cross correlation between channel A and channel B, and the third produces a total power value for each channel.
The cross correlation and total power value are averaged and written to a UDP socket once every second. These values are used by the online interface for diagnostic purposes.
This ACSM is an in house software library that provides a wide range of antenna control and tracking functionality. This generic component communicates with a PED dish driver instance that converts standard coordinate requests into mount specific control (in this case a velocity request for each axis).
The ACSM is currently being used in PED, at the XDM at HartRAO, and will be used for KAT-7 and MeerKAT (for more information on these projects see www.ska.ac.za
The dish driver sends velocity requests to the mount which contains an embedded drive controller (also developed in house) that enacts the requested velocity for each axis.
The offline correlator is stand alone GNU Radio based software written in Python. For each antenna combination the software is run and produces a single baseline. The first step is two align the samples from each Antenna. This is done by matching the sample counter from Antenna A with that of Antenna B. Once the streams are aligned the same time domain correlator used in the realtime correlation is used and the cross correlation is written to disk.
The data from the slave machines is copied to the master machine prior to correlation.
The web interface has been developed in house using Adobe Flex.
The second interface is an IPython interactive shell that exposes the low level functionality provided by the main HELIOS python library. This is primarily a debug and diagnostic interface but does provide more direct control of the facility.