The purpose of this page is to serve as a primer for discussion about designing a scalable M&C software package for the K-band FPA receiver.
FYI only, should not be required to understand this document.
Array M&C Software Design
Components of the Array
The KFPA monitor and control (m&c) points communicate using the Inter-Integrated Circuit (I2
C) protocol. These hardware devices can be roughly grouped into three categories within the context of the KFPA: "pixels", "duplicated points", and "non-duplicated points". Each category is briefly described below and attempts to quantify what devices it contains.
Certain devices will be duplicated on a per-pixel basis (or a fixed multiple per-pixel).
- Bias m&c (x2 per pixel, one per amplifier)
Pixels are the "unit" of hardware that will be duplicated most frequently in the KFPA.
Some m&c points will be duplicated, but not strictly on a per-pixel basis (perhaps as one-per-N-pixels, but N is not known).
- I/O expanders (explained below)
- Power cards (?)
Non Duplicated Devices
The remaining points will not be duplicated as the number of pixels increases.
- Vacuum sensors
- Temperature sensors (?)
The hardware consists of many pixels, and the associated monitor and control (m&c) points described below.
The general hardware architecture:
| Control Board +
| (...) |
| | | |
| I/O Expander | | I/O Expander |
| | | |
| | | |
| Device Chain | | Device Chain |
| | | |
The control board, a Freescale Coldfire 5270 microprocessor and associated hardware connections, manages the I2
C interface which communicates with the various control points for the receiver. Transmissions follow the Philips I2
C standard (reference
The board has an Ethernet interface that allows firmware updates and access to a self-contained web server.
I/O expanders are chips that "hide" the addresses of the devices chains connected to them. An I/O expander is something like a demultiplexer, controlling access to several devices at once. This allows the devices behind an I/O expander to have the same addresses across each "port" (similar to output lines on a demultiplexer) of the expander, and potentially even across multiple I/O expanders. Once a port is enabled, the device connected to that port may be addressed as though it was connected directly to the I2
The device chains are a series of hardware components connected using I2
C lines (described above).
The Netburner development kit includes C APIs to communicate with the various interfaces on the microprocessor board, including I2
C and the web server (Ethernet interface).
The board runs a web server with basic HTTP capabilities (GET and POST request processing, possibly cookies?). It is presumed that this will be the interface used to connect the GBT M&C system to the receiver, because of the remote location (top of the GBT) of other available interfaces (serial, I2
The board also has the ability to execute C/C++ code via server-side function calls embedded in web pages (each time the page is loaded the embedded function is called, and can write characters into the web page's source).
How will it scale?
How can the design encapsulate various types of devices (in varying numbers) to scale up from one pixel to seven to sixty-one?
- Not all devices are the same. Aside from physical hardware differences, each device requires specialized initialization and addressing, particularly with the current architecture (I/O expanders controlling access to several devices; each one is on a particular I/O expander port and must be enabled through that port before addressing).
- Not all devices are duplicated. Some are only present once and some are duplicated (potentially) arbitrarily more than per-pixel.
- Communication to the manager. The manager (or some client) will have to have a way to retrieve data from the board, probably via the web interface (due to the remote location of the control board's other interfaces, i.e. the receiver room on the GBT; this is currently required since it is using directly wired I2C lines). The protocol it uses to do so should have the scalability in mind as well.
- Memory space. As with most embedded platforms, there are a relatively limited amount of resources available on the chip. It is entirely possible that one control board will not be sufficient to control all of the hardware for the final 60+ pixel array.
How It Works Now
The control board provides access to the monitor data and manipulates the control points, both via the I2
C controller. Data is shipped to a client via the web interface.
The web interface consists of several web pages, each with a single function call to a routine that prints out the values of associated control points, in comma-separated format. For example, all values from the power card are printed on a single page.
For display, these are parsed by an asynchronous request on the main page, scaled with the appropriate multipliers, and inserted into table columns.
- 05 Nov 2008