Orbit > InterferenceSubsystemInterface

User Interface (UI) specification for the Interference Subsystem

This document is a draft specification for the User Interface to the Interference subsystem on the ORBIT indoor testbed. The Interference subsystem includes,

• instrument hardware, which currently includes an Agilent ESG (Signal Generator) and a Spectrum analyzer,
• instrument software, which includes all the Agilent libraries and tools required to control the instruments. The libraries and tools for the Agilent instruments reside on a Windows machine (instrument1) inside the ORBIT domain. The instrument hardware is connected to this machine over GPIB and Ethernet.
• ORBIT service software, which will be the tool that exposes instrument functionality to experimenters. It is expected to run on the same Windows machine which is connected to the instruments and use the instrument-specific libraries. Since these libraries are available only for the ​Microsoft .NET platform, this service will also require atleast some components to be written on this platform. The languages used on this platform include ​Microsoft Visual Basic and ​Microsoft C#.

Constraints and design issues

The two most basic operations that will be carried out using this subsystem are the generation of signals and their observation in different domains (time and frequency). Experimenters should be provided with interfaces for the same. While designing these interfaces, the following points should be carefully considered.

1. Instrument Complexity - Instruments are quite complex and experimenters should be shielded from this complexity. Commands to the instruments can potentially take a large number of arguments, some of which are instrument-specific and require a thorough understanding of how the instrument functions. The interface should hide this complexity from the experimenters, possibly even hiding the existence of instruments. As far as the experimenters are concerned, they should be able to generate or observe signals according to their specifications.
2. Heterogenous Instruments - The subsystem should allow for the inclusion and possible addition of instruments, with different capabilities. Thus, there can be instruments from different manufacturers that generate the same signal, but either have different number of default arguments or require arguments to specified in a different order. Again, these details should be hidden from the experimenter.
3. Experimenter expertise - It is expected that a majority of experimenters are novice users when it comes to using such a system and its capabilities. At the same time, it is possible for some experimenters to request for an "expert" interface. The system should attempt to provide hooks for both kinds of users.
4. Instrument protection - All instruments are very expensive hardware and should be protected from both malicious users as well as unintentional misuse. Commands passed to the instruments should be thoroughly checked before they are used.

Basic Operations