Links
 
Home 
Background 
Papers 
T-codes: 
·Properties 
Deterministic-IT: 
·Tools 
Signal Processing: PERTECS 
Graphics: Space Odyssey 
Logistic Map 
 
 
Analogue Computing
 
Bernd Ulmann's museum 
.

Signal Processing: PERTECS

A RECONFIGURABLE UNIX TOOL
EMULATING AN ANALOGUE COMPUTER
All software tools on this site subject to terms conditions.
May be used freely for educational and personal use only.
Commercial use subject to license terms on request.
Specifically, all military and defence applications precluded.
Pages dedicated to the peaceful application of science
for the benefit of all species with whom we share planet Earth.

(pages in flux, last update 01/11/2011)





Introduction to PERTECS:

click here for access to PDF documentation and resources
PERTECS is a Programmable Environment for Real-Time Emulation of Continuous Systems. It operates as a UNIX filter, which optionally accepts one or more signals (input channels), processes these within a reconfigurable environment, and optionally outputs one or more of the signals (output channels), all running in real-time.
The Input and Output channels are passed as telemetry frames over standard i/o. An integrated 3D graphics (see SpOd) flexibly displays up to 500 signal channels simultaneously. A further text overlay is available to display all state variables updated in real-time, and further enhancing this interactive user environment for signal processing, modeling dynamical processes, and/or control applications.
PERTECS is invoked as a UNIX shell command. Thus within the constraints of shell commands and shell programming PERTECS may be combined with itself and other UNIX tools, including data acquisition, data capture, display and control tools.
Within the PERTECS environment, an array of functional modules are configured and 'wired' to process signals, as in a virtual 'circuit'. At the core of PERTECS is a programmable switch that supports the flexible interconnection of input and output nodes, as on a patch panel. Building a PERTECS tool is much like playing with lego. From a repertoire of standard modules one may construct a complex signal processing and control system, virtual instrumentation and data analysis and graphical display algorithms. The build, configuration and wiring are stored in a set of XML files read by PERTECS on initialisation. A given PERTECS configuration performs a specific user function to a user specified design. Combining PERTECS tools in a piped command sequence or with other input/output tools that include audio, serial digital, flow and pressure sensor acquisition yeild practical instrumentation solutions. A series of examples are provided here for signal generators, data analyzers, experimental instrumentation, and control systems, indeed a virtual test bench intended to assist/inspire a potential user. As with lego, the user's imagination is its principle limitation.
Fig. 0.1: Showing the functional organisation of PERTECS, and an example of its invocation as a shell command.
In the following pages working examples illustrate how PERTECS may be used to solve specific practical problems. Needless to say PERTECS is work in progress but it has arrived at a mature point in its development. It is used ever day by its author and others to solve specific problems. It is primarily a research tool, not a commercial product. Some of the anticipated features are reflected in the gui interface panels that are part of a suite of tools available to assist in the building and configuration of PERTECS tools.
Configuring PERTECS is intentionaly akin to programming an analogue computer. This is virtually a lost art and hence the example circuits provided here give the potential user access to practical circuit solutions with PERTECS functionality is dependent on the user making appropriate connections between functional modules. Where conventional analogue computers could be criticised for lack of precision, today we have the advantages of the underlying digital machinery. Nevertheless the discrete emulation of continuous systems carries other limitations which ultimately and unavoidably impact precision. Just as analog electronics components must be compensated for, here it is also generally necessary to make adjustments and compensating 'circuitry' in a given PERTECS solution. What a digital implementation affords is a level of consistency and repeatability not available in real analogue systems.
We go to some trouble to imbue PERTECS with the analogue paradigm, and address areas of weakness where possible, and to hide the conventional digital flavour of the underlying machinery. Our goal is to avoid the conventional programming cycle that typifies software development generally. Nevertheless, a digitally emulated analogue machine callable within programmable shell scripts implicitly incorporates the best of all providing in effect a hybrid computing environment. As the examples below attempt to show, PERTECS solutions can give powerful, breathtaking functionality.
One may well ask, why would one want to return to an analogue computing paradigm? Isn't it so that these dinosaurs have been outmoded/displaced by modern digital computing systems?
Fig. 0.2: The year is 1968, picture from Systron Donner brochure.
A shame that so much of this technology has been directed against mankind itself through military and so called defence applications.
In the words of Charles Care[1] Analogue computers are machines that enable a user to reason about a mathematically complex physical system through interacting with another, analogous, physical system. Slide-rules, planimeters, astrolabes are examples of some of these. Analogue computers have a much much longer history than digital machines. The name "computer" is possibly misleading when applied to an analogue machine since the role these machines have played is closer to that of scientific instrumentation, central in helping us understanding the world around us. An analogue computer imparts a level of intuitive understanding of a problem in a way that seems not to be generally the case for digital computers.
"digital" computers are of course also a special kind of analogue machine in which the discretet '0' and '1' symbols are represented by non-overlapping voltage ranges, and non-linear amplifiers and components are operated deliberately in saturated states to effect appropriate 'digital' operations. The 'bang-bang' circuit described later and the comparitors are examples of circuits and modules offering non-linear operations in the analogue domain. But also the multiplier operations permit non-linear operations central to many interesting analogue phenomena.
If digital computers are also analogue computers then one must logically conclude these too ultimately will suffer the same limitations attributed to traditional analogue computers?
An important recent advance in the area of non-linear dynamics has been the recognition that continuous descriptions of dynamical systems and corresponding coarse grained symbolic encodings of the same, are but equivalent duals of each other... Digital computers in this respect may be more properly viewed as symbolic (string) processors rather than as 'numerical computing engines', and the duality that exists bewteen string descriptions and continous descriptions allow us to recognise the equivalence. The principal distinction lies in the way the contrasting architectures exploit the available resources. A digital machine allows one to more flexibly allocate resources to address and overcome key limitations, choice of word size, algorithm etc, to mitigate sources of error. The errors are not absent in either domain. The cost of mitigation is generally in speed and complexity. Analogue computers are more obviously limited by virtue of their amplifiers, when it comes to resolution and thus accurracy, but they exploit the natural bandwith of the electronics to achieve their speed.
Digital computers further present a different kind of interface to the user, one which does not impart the same feeling of responsiveness, immediacy, continuity nor transparency that seemed intrinsic to the old fashioned analogue instrument. No question that a digital computing machine is a wonderful invention, but so complex and opaque is its operation that few users have any real concept of the underlying processes taking place for example between pressing a key on the keybaord and seeing the character appear on the screen. Digital machines encourage the use of layered abstractions, programming languages and data structures that hide the underlying complexity and architecture. Such abstractions may prove especially attractive when they create for example an interface with the qualities of an analogue instrument, one which facilitates user understanding of the problem at hand. This is precisely what PERTECS aims to do.
The history of the development of both computing paradigms, the analogue and digital is rich as it is fascinating. For those interested in the historical roots of the ideas encapsulated in PERTECS I throughly recommend visiting Bernd Ulmann's web pages. Specifically look at his wonderfully documented analogue computer collection
PERTECS specifically attempts to recreate an analogue computing experience, and to hide aspects of its 'digital' implementation. PERTECS is not unique in this aspiration but a relative newcomer to a growing list of other software packages all attempting to do the same.
What then is special about PERTECS? The most obvious differences arises from contrasting the comparatively closed, self-contained proprietary environments of say Labview or MATLAB's Simulink, with the altogether open environment UNIX offers, in which PERTECS is but one of dozens of tools one may bring to bear to a problem. By standardising on interfaces, for example at the data telemetry exchange handled over STDIO (standard Input/output), and on XML (plists) configuration files, we have what amounts to as a modular collection of interchangeable tools accessible from the terminal command line. These may be combined with standard UNIX commands like cat, grep, head, tail, and awk etc. Modularity provides flexibility at the point of use. At the same time it facilitates and simplifies the development of new functional tools. Each tool tackles one kind of problem. No one software tool need attempt to be all, do all , or solve all, in a single environment. Having transparent access to data streams at all tool level interfaces as well as the internal modules provides the user with absolute and transparent control. Making connections and adjustments while a system is live and operating helps one to gain understanding about a problem and its operating neighbourhood. Changes in real-time afford a level of immediacy not ordinarily achieved within a compiler based development cycle.
Thus configuring PERTECS contrasts with conventional programming languages. A set of gui tools attempt to emulate the feel and performance of the analogue computer interface.
A PERTECS build internally comprises an array of i) data inputs, ii) data outputs, and iii) the processing modules own respective inputs and outputs. Wiring is effected as a programmable switch supporting flexible interconnection of virtually any combination of input and output nodes. A connection is regulated by an additive offset and multiplicative weight. Where more than one output node is listed in a given connection, these will be combined as a product. Once system initialisation has been completed, PERTECS loops through the tasks of delivering data values to the respective module input nodes, then the processing of these inputs to derive output values, and finally the sampling of outputs to deliver an output telemetry stream or scope trace. The data exchange is handled entirely and efficiently through pointer combinations generated from the users circuit configuration file, Present implementations on a mac laptop (3GHz Core 2 Duo) achieve a megahertz sampling/cycle rate.
The module names and node labels are not critical to the operation of PERTECS but ease the user's task of setting up and interfacing with the system. Once a circuit has been implemented, there is no especial need for these name and label overheads to be carried forward. Thus a stripped down version of PERTECS is being developed to enable an imbedded configuration to targeted appropriately in resource limited situations. A compact selection of basic modules, effectively ensures efficient reuse of code, but in principle may be expanded to accommodate additional user-specified modules. The modules in this version of PERTECS operate by way of a tightly constrained interface that includes three double-floating point inputs, and six double-floating point outputs, and accommodating a buffer and six general purpose parameters. These may constitute strings and values accordingly.
This simplified interface is conducive to integrity. The modules are constrained in their behaviour and ultimately comprise well tested and simple code routines. The analogue connection paradigm further constrains the opportunity for unexpected bugs or spurious unstable coding to arise as in conventional programming. Changes in a circuit do not alter executable code, so no unexpected, unforeseen errors can arise from working within this medium, and where unexpected behaviours occur, these may shed new insight into the dynamics of the problem to hand and may be 'debugged', thoroughly investigated and understood using the scoping tools implicit in PERTECS. Thus a PERTECS configuration lends itself to being altered in real-time without the usual cycle of recompilation, linking, debugging, testing, and without surprising outcomes that come from scripted coding alternatives.
PERTECS is aimed at interactive real-time problem solving, but may be used as effectively in offline processing and analysis. PERTECS tool configurations developed over time to fulfill particular tasks, may be called upon as tools in their own right. This document offers a variety of examples as a starting point for others. It will be clear that the particular complement of functional modules, and the underlying digital implementation, impart an approach to problem solving that is unlike other environments, and requires a different way of thinking when solving specific problems. This way of problem solving may be alien to the newcomer, but the extensive set of examples included here may guide the user in his/her own applications.
Fig. 0.1 illustrates the functional architecture of PERTECS, and how it may be invoked from the command line. Here an input stream is acquired from a real-time interface tool, or stored file. The format of the data is assumed to be a repetitive telemetry frame, each frame residing on a single line. Each input channel is assigned to a column in a space or tab delimited text array. The first column corrsponds to a line counter (sample/frame counter). This input stream is piped to PERTECS which performs an algorithm according to the given circuit configuration, and optionally outputs values, piped as in this example to a second instance of PERTECS assumed to be performing yet another processing step. PERTECS includes many of the graphical capabilities of spod (Space Odyssey) and thus the final stage in many applicatons will involve PERTECS giving specific visualisation of data series.
PERTECS includes many modules essential to solve a wide range of problems. Though the fully interactive version of PERTECS remains in the pipeline, it is in its present form already a powerful reconfigurable UNIX tool, offering comprehensive options for signal processing and modeling problems.
PERTECS supports interactive potentiometer controls, and allows the user to make/break connections and change connection parameters while the processes are 'live'. In this way one may explore a solution through a process of experimentation, resulting in better understanding of complex systems. Better understanding leads to better designs, and more robust outcomes.
The versatility PERTECS and an associated growing suite of tools allows one to address a wide range of standard signal processing problems, including data acquisition, test signals generation, filtering, spectral analysis, data logging, and visualisation. In the following sections a series of examples show how these might be accomplished.
PERTECS includes flexible 3D scoping options. But it may also be used in combination with SPOD (SPace ODyssey). By incorporating the SPOD graphics within PERTECS useful real-time features with low latency is achieved. The PERTECS scope options are described in section \ref{sec:scope}.

Last modified: 25th May 2013