Purpose

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.

Introduction

Additional Reading

FYI only, should not be required to understand this document.
Array M&C Software Design
I2C reference

Components of the Array

The KFPA monitor and control (m&c) points communicate using the Inter-Integrated Circuit (I2C) 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.

Pixels

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.

Duplicated Devices

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 (?)

Hardware

The hardware consists of many pixels, and the associated monitor and control (m&c) points described below.

Architecture

The general hardware architecture:

              Ethernet
                  |
          +-------+-------+
          |               |
          | Control Board +
          |               |
          +---------------+
                  |
                  |
        +---------+(future)-+
        |          (...)    |
        |                   |
+-------+-------+   +-------+-------+
|               |   |               |
| I/O Expander  |   | I/O Expander  |
|               |   |               |
+-------+-------+   +-------+-------+
        |                   |
        |                   |
+-------+-------+   +-------+-------+
|               |   |               |
| Device Chain  |   | Device Chain  |
|               |   |               |
+---------------+   +---------------+

Control Board

The control board, a Freescale Coldfire 5270 microprocessor and associated hardware connections, manages the I2C interface which communicates with the various control points for the receiver. Transmissions follow the Philips I2C standard (reference).

The board has an Ethernet interface that allows firmware updates and access to a self-contained web server.

I/O Expanders

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 I2C bus.

Device Chains

The device chains are a series of hardware components connected using I2C lines (described above).

Firmware

The Netburner development kit includes C APIs to communicate with the various interfaces on the microprocessor board, including I2C 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, I2C, etc).

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?

Issues

  • 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 I2C 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.

-- PatrickBrandt - 05 Nov 2008
Topic revision: r12 - 2016-06-08, PatrickMurphy
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback