Signal Processing: PERTECS

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)

0.0 Description of PERTECS:

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}.

1.0 User Interface: Configuration Tools

The configuration files that define the functional operation of a PERTECS build are XML text files, more specifically property list (plist) files (a typically Apple standard). These files may be created or amended in various ways, but for the purposes of this document these are edited using a set of purpose created GUI interface tools that are described here. These are not to be confused with PERTECS but are standalone tools whose functionality is limited to maintaining and configuring the XML files specifying a given PERTECS tool.

These GUI tools give a relatively intuitive interface to PERTECS. This section describes the interface tools as a way to providing an introduction to the operation of PERTECS itself.

The goal generally is to configure PERTECS to perfom a desired function. For a given instance of PERTECS a single configuration file set is required. The file set share a common root name, and differ in their extensions. When executing PERTECS the form of the command is thus;

pertecs -c[onfig] rootname

PERTECS tools may be combined on the command line with other standard UNIX shell filters, or with other PERTECS configured tools in the usual way. In the configuration set, the first file extension indicates which of the four configuration files he/she is dealing with; build, modules, i/o or wiring. The second extension (which may or may not be visible) is predefined by PERTECS, and ties each of the configuration files to its respective GUI editing tool. Double clicking on any configuration document (or typing

open configuration_file_name

in a terminal window) will open the configuration file with the appropriate gui tool.

1.1 Building an analogue machine, PertecsMd (download OS X tool) :

We begin with the first of the four configuration tools, PertecsMd, used to build a analogue machine module set. The interface, displayed in figure Fig. 0.3 is used to indicate how many of each operational device/module is to be included for a given PERTECS tool. The illustration shows for example that 6 each of the calculus module, math module, comparator module and output modules have been selected. We may use this to demonstrate a number of basic circuit examples.

Fig. 0.3: PertecsMd build gui: Astand alone tool for selecting the complement of modules in a configuration.

Each module class has a name, e.g. MATH is the default class name for the math modules. The user is free to select another name if he/she so chooses. The modules have default input and output node names which may also be changed. The convention followed here is to use UPPERCASE for the class names and lowercase for the node names. Node names need not be unique to a given module, but must be unique for the module. That is no two nodes in a given module may have the same name.

Towards the right of the PertecsMd-build panel the user may set extensions for each of the configuration files. The build file extension is fixed, a necessity since PERTECS must be able to locate the first of the XML files in order to discover the settings for the other files.

All devices/modules conform internally to an interface definition. Standardisation of modules facilitates the interconnection and interoperability of devices in any circuit. Within these constraints new functional modules may be easily catered for. (Some currently unimplemented modules are already anticipated in PertecsMd-build panel.)

All modules are presently constrained to have not more than three inputs, six outputs, and six parameter values (used to modify a modules operating characteristics). A module may also have one or more internal buffers depending on its functionality.

In the general version of PERTECS all input & output nodes and parameters include names and label spaces. These are displayed in full by the configuration tools to facilitate the building and configuring of PERTECS tools. Once set, these additional overheads may become surplus to need, and ultimately dispensed to yield compact, efficient, robust software implementations for imbedded applications.

The scope interface provides an effective way to access variables.

Fig. 0.4: Maximising the build panel exposes the scope settings. Default settings speed the process of getting a tool up and running with a minimum of effort.

1.2 Configuring modules, PertecsPr (download OS X tool)

PertecsPr allows one to view the processing devices (each has been assigned a unique module number) and to view or edit labels, set operating parameters, buffer sizes and so on. A scrollable window gives access to all entries. Simultaneous selection of module entries (holding the command key down while making individual selections or the shift key to make consecutive selections) allows one to efficiently edit multiple selected modules at once.

Fig. 0.5: PertecsPr presets gui: itemising individual modules and setting up initiisation param- eters. And PertecsNm io naming gui: listing in this case only output channels for the current demo build.

1.3 Configuring I/O, PertecsNm (download OS X tool)

PertecsNm provides similar access to the input and output channel modules. Each input channel and output channel is treated as a module in its own right. A frame counter is automatically included with the inputs and outputs respectively. The i/o modules are numbered consecutively following on from the process modules in the PertecsPr panel. Default module labels and signal labels are generated by PERTECS from the assigned names in the PertecsMd panel. These may be edited, to give more meaningful labels perhaps corresponding to those on a schematic fro example. This level of record keeping is essential to facilitate in documentation, an especially important aspect of any project when more than one person is involved.

Once a tool is configured these files may never need to be looked at again. Conversely the internal labeling and references simplify making sense of a 'circuit', and for making amendments and adjustments if and when the need arises.

1.4 Wiring, PertecsPp (download OS X tool)

Finally, PertecsPp, is the PERTECS patch-panel tool, to make and manage connections between modules. It is sufficient to uniquely identify a connection node by specifying a module number and corresponding node name as set out in the build panel. Input connects tend to be colour coded by mustard yellow and output nodes by grass green, whereas the weights and offsets by carrot orange.

The PERTECS patch-panel gui: for managing the interconnections bewteen modules.

Each line in the table corresponds to a single interconnection. However a connection may comprise up to six outputs, a constant weight factor and an offset. While inputs are coded yellow, and outputs in green, it is possible to connect the input of a scope for example to the input of a module, although it is not possible to connect two module inputs otherwise. The horizontal scroll bar allow one to view multiple output entries in the table when these do not all fit within the view. Alternatively a selected line and its entries appear in the condensed table to the lower right of the interface and it is in this area of the panel that values are updated.

Multiple lines may be selected if common column elements are to be updated at once. The rows may be sorted by column value by clicking the mouse on the respective column headings.

In future the module labels and connection signal labels may have more significance in terms of identifying uniquely the connections, but at present these are more for convenience in identifying the modules and wiring lists.

A connection may be summarised by:

When making n separate connections (one line per connection) to a given input, these are handled as a summation, thus:

Implicit in this are simple weighted sums:

or polynomial functions.

Fig. 1.6: Schematic representation of sum and product operations implicit in the connection.

These tools are simply specialised editors. Just as a text editor doesn't check for content and structure in a document, so also, these assume appropriate input. They are for expert users, PERTECS on the other hand checks the content for consistency and correctness as it reads in the configuration files, so the user is not left without some error feedback.

1.5 Potentiometers, PertecsPots (download OS X HUD)

The potentiometer-control interface (Fig. 1.7) enables connection weights and constants to be changed by the user in real-time, while PERTECS is running.

Fig. 1.7: The PERTECS potentiometer input controls.

1.6 Runtime controls, PertecsCtrl (download OS X HUD)

A further control interface (Fig. 8) gives the user the ability to interactively suspend, reinitialise and resume the running of PERTECS.

Fig. 1.8: The PERTECS control panel: left shows halted state, right shows the running state.

2.0 Building a PERTECS tool pertecs (download UNIX executable)

Pertecs is an executable executable file currently compiled for mac only... core 2 duo... no garantees this is right for your machine. A windows of version of pertecs has been successfully compiled under visual studio and will be posted here in due course.

Download the executable: pertecs (put file in /usr/bin)

It is usual to place this in for example the /usr/bin directory. Type the command

sudo cp /Downloads/pertecs /usr/bin/ 

you will be asked for the system admin password before the copying can be completed. Pertecs assumes the Expat libraries are installed on your system. Instructions for installing Expat are at to found at Expat installation.

Once these libraries have been installed, you may wish to confirm normal operation of pertecs from the terminal command line. To do an inital test you need to downloaded a set of test configuration files, for example (coming shortly): Download TEST_CONFIG
After downloading copy this folder to your home directory.

cp -R /Downloads/TEST_CONGFIG ~

(make sure you observe the syntax exactly, the white space must be critically observed in shell commands.) In your terminal window type:

pertecs -c test -D 1000

You should see a scope window appear with the sin and cos functions of time displayed. If this is working you may now follow the examples below to understand how to use these tools.

Building a PERTECS configured signal processing tool from scratch is also straightforward.

The process of creating the configuration files is coordinated by invoking PERTECS itself. A three step process during which PERTECS creates default XML configuration files for editing with the aforementioned gui tools.

In an open terminal session, set the current working directory, then invoke PERTECS. The command:

pertecs -c demo -b

will create the first of the XML configuration files with the name demo.build.pertMd.

This document file may opened either by double clicking on the file icon within finder, or by typing in the terminal window:

open demo.build.pertMd

When opened the user will find a default set of class names and node names for building a virtual analogue machine. For simplicity, default names and labels may be assumed for most operations. It remains to select a set of modules and output channels to work with.

In this case six (6) each of the output channel modules, math modules, comparators, and calculous modules have been selected. The selections are automatically saved to the file.

Once the build configuration is saved type the command line:

pertecs -config demo

PERTECS will now create two more files with the root name demo. The first is called demo.presets.pertPr and the second demo.io.pertNm.

To view all files created so far, type:

open demo.*

It is now possible to 'wire' up a 'circuit'. The next section includes simple downloadable examples to illustrate. These staged examples provide an opportunity to introduce each of the various processing modules in detail.

Fig. 2.0: from a brochure by Systron Donner (1968) ... computations operate in a lanaguage conducive to the problem at hand.

3.0 Process modules

3.1 Simple circuit examples

In this section we introduce the process modules. Possibly the easiest way to do this is to use each in simple example circuit.

Fig. 3.0: "Modern design - simplicity in operation": A feature of analogue computers generally is the front panel, what you see is what you get ... no hierarchy of dialogue boxes and configuration interfaces to wade through here. Pertecs attempts to emulate this mode of interface.

3.1.1 The Calculus Module

The module central to an analogue computer is the Integrator, which we have combined with a number of related functional modules and we refer to the combination as the calculus module.

The ability to perform integration admits the ready solution of differential equations. On an true analogue computer integration is implemented by way of capacitive feed back around a high gain linear amplifier. The current passed to the capacitor throught the input resister is balanced by that from the output of the amplifier in such a way as to maintain the voltage of the amplifier input at 0. Thus the input appears as a virtual earth. To sustain this the amplifier output voltage changes in accordance with the current/voltage relationship for an (ideal) capacitor:

Fig. 3.1: The analogue integrator utilises the current versus voltage characteristics of a capacitor.

At the input:

For the capacitor the total charge is:

where is the voltage across the capacitor given that the input is held to 0. Since the input impedance of the OP-amp is assumed infinite all the current flowing through the input resistor must then flow into the capacitor:

(The sign coming from the reverse direction of current flow through the capacitor.)

i.e.

and integrating;

The schematic symbol for the integrator is given as:

Fig. 3.2: Schematic representation for the integrator.

Integration is performed numerically by dividing time uniformly into fine steps and performing discrete step-wise summation of the corresponding input sample values. This is known as Euler Integration. It incurs an error that is dependent both on the input function of time and coarseness of time division. While more efficient accurate numerical integration is possible at the expense of using uniform sampling, this is not the only source of errors in an emulated analogue system. Further significant errors stem from the inability to achieve concurrency across a circuit, especially noticeable when closed (feedback) loops exist or nonlinear sensitivities. Latencies typically contribute to an accumulation of errors and these need to be managed in a balanced way with the time division. Both errors arising from Euler integration and from our approximation for concurrency are mitigated by minimising the time division step. While this imposes a heavy computational cost, advantages are also derived in terms of real-time responsiveness. A fine grained time scale implies a high sampling rate relative to the modelled dynamics.

Integration errors in PERTECS are further mitigated by utilising the second order differential component to estimate an error correction feedback term. Since our input time-series is approximated by a polynomial-fit function for differentiation, and implemented by way of linear filters, the second is available implicitly. The down side to this is the latency in the computation of the second derivative which is significant when integration is to be performed within a feedback cycle, or closed loop.

The following figure illustrates for example, the fitting of a cubic polynomial to a set of 9 points contained within a sliding window:

Fig. 3.3: Fitting a third order polynomial to 9 points of the time series. The process may be repeated for each consequtive set of 9 points to give a series of polynomial fits, each having coefficients respectively a, b, c, d, and ultimately resulting in four corresponding time-series [a_t], [b_t], [c_t], [d_t].

The best estimate of the coefficients $a,b,c,d$ that minimises the error in this over-specified polynomial is derived by matrix inversion. The over specified fitting results in a least squares fit, known to be optimal, though we make effort to address this here. From inspection of the above one may write:

which is of the form . Reworking this gives Directly computing the terms of the matrix X, we have;

Inverting X is easily accomplished in Matlab or Octave: X^-1 = pinv(X) (pseudo-inverse) and yields the coefficients included in PERTECS to achieve a least-squares fit for a to the data points within the selected sliding window.

Setting x=0 in respect of the centre point in the sliding window at time t, one obtains an estimate for y_t : y_t = d_t. Thus the time series [d_t] formed from computing the coefficients for each window position actually corresponds to a smoothed version of the input function. This is often referred to as a least-squares fit smoothing filter or the Savitsky-Golay smoothing filter.

Differentiating Eqn (\ref{polyeqn}) gives y_t' = 3a_t x² + 2b_t x + c_t. Setting x = 0, gives us an estimate of y' at the centre of the window at time t. One has y_t' = c_t. Continuing with the further derivatives one obtains y_t" = 2b_t and y_t''' = 6a_t.

It is evident the time-series [c_t] corresponds to an estimate of the first derivative of the input series, [2b_t] to the second derivative and [6a_t] the third derivative. Thus the Savitsky-Golay filter gives the derivatives as a by-product of the polynomial fitings. Each of computation is performed as a conventional linear filter implemented within the calculus module. The size of the filter determines the number of points used in the fit.

The size of the sliding window introduces a delay of (n-1)/2 time steps, where n is the buffered window size. It is convenient to include an output for the module comprising a delayed input-series so that in phase computations involving both the initial series and filtered series are available to propagate forward in synchronism. Except where circuit loops are created, it is generally advisable to propagate forward the raw series to further processing steps to preserve or limit errors due to phase shifts.

The computation of the smoothed function and its derivatives reduce to a set of four linear filters each with n terms, implemented as a weighted sum. PERTECS currently supports buffered filter sizes corresponding to all odd values in the range of 2 x [2,64] with the default size 2 implying a minimum delay of 2 sample periods and a window size of 5 points.

Fig. 3.4: Deriving a correction for the numerical integration routine.

In returning to the question of integration, we note that the least-squares fit-filters are area-preserving. This means the integral of the initial time series is expected to be the same as that of the smoothed time series, but also that integration of the derivatives will also be numerically relatively precise.

PERTECS implements integration by way of the polynomial fit functions to derive a running correction. Assuming the polynomial expressions optimally characterise the input series one may perform integration in time slices corresponding to (t-0.5) to (t+0.5) , for each of of the polynomial fit functions derived by way of the sliding window, and sum the result. Integrating over the slice gives

where [2b_t] is recognisably the second derivative and [d_t] the smoothed function.

Summing over all consecutive time slices yields

The first term is simply the sum of the input time series terms, and recognisable as triangular integration. The second term is a correction term. By virtue of the implementation, the correction term is in fact delayed by half the filter buffer size, creating as we have noted another source of error. Forward predictive estimates of the error term add to the complexity of the computation that may not be justified. Numerical integration in PERTECS thus carries a penalty from the latency implicit in the finite time steps, and may need to be addressed within a given implementation by other circuit adjustments. These sources of error are a fact of life in a discrete digital solution... compensation is invariably needed in any circuit configuration as it is in real analogue circuits to overcome non-ideal behaviors.

PERTECS integration performance may be further mitgated by a judicious choice of sampling step size, i.e. the sampling rate, in relation to the data series bandwidth, set by weighting input values to the integrators accordingly. For example a 1 second integration time constant might be arrianged by setting the sample rate to 1KHz and the input connection weighting to 0.001 or 10KHz and 0.0001 respectively. Additional feedback may be used to stabilise the dynamics, especially in sitautions where feedback loops exist.

The correction term from the second derivative is indicated in the PERTECSMd pannel as a feedback term from the second derivative to the input to the integrator.

Fig. 3.5: Calculus module as depicted in the build panel. Note that the correction term is implied by the feed back from the second derivative. The special input offers the opportunity for additional compensation separated from the input function, if required.

Example 3.1: Sine Function, Damped & Undamped

Fig. 3.6: Here a pair of integrators are connected to solve the problem giving the solution . We have selected ω = 0.00001.

The constant ω may be associated with the integrators time constant and thus effectively determining the size of the discrete time steps. The smaller ω the greater the number of steps per unit time. For ω = 0.00001 , the time step is sufficiently small to give a pretty representative result for the sine function. At this time step a constant input value of 1 to an integrator, will require 10000 time steps to achieve an equivalent change in the output. We may reasonably expect the integration to be numerically pretty close to a theoretical result with this sort of resolution.

PERTECS display trace.

The patch panel entries, no damping.

Fig. 3.7: It is sufficient to specify a connection node by its assigned module number and corresponding node name. PERTECS outputs a complete set of entries in a separate log file useful in the debugging.

Reducing the time step by a factor of 100 to ω = 0.001 results in noticable deviation from the aforementioned solution. Errors in integration and from loop latency (lack of concurrency) result in (exponential) growth in the amplitude of the solution that may be managed either by the inclusion of feedback, or a reduction in the time step size, or a combination of both of these methods.

Evidence of less than perfect integration is manifest in the gradual (exponential) growth in amplitude.

Fig. 3.8: The patch panel entries for the undamped sine.

Increasing the time step by 100 i.e. ω = 0.1 , together with appropriately applied dampening (negative feedback across the integrators) allows one to speed up the dynamics with out undue compromise in the integration result, resulting in this case in a damped `ringing' response. It is imperative to evaluate results to ensure the rate at which errors propagate in a given solution are within acceptable bounds.

Damped sinusoid .

Fig. 3.9: Corresponding patch panel entries, with damping.

(N.B.: this is not the only way to obtain the sine function on PERTECS. Later examples give function generators useful in the practical setting.)

Example 3.2: Sine Function, oscillator with amplitude stabilisation and frequency control

simple quadrature chirp generator using active feedback on damping and loop gain to determine frequency.

Fig. 3.10: The corresponding patch panel entries for above schematic.

Example 3.3: Van der Pol Oscillator

This is an example of a non-linear second order differential equation:

Second order equation with non-linear damping.

With a Forced input oscillation:

With a Forced oscillator input.

PERTECS display of driving input sine and the output of the van de Pol oscillator integrators. Rotating display (right) allows the vdpol states plotted against the driving force in the z-direction, to be viewed.

Note: For best results pause the movie till it has loaded completely, then press play

If the sinusoidal signal is sufficiently large the van der Pole oscillator will synchronise to this. However as the amplitude of the sinusoidal driving function drops, a point is reached where the relaxation oscillator beats against the driving signal which has been set to a slightly different frequency of the van der Pole oscillator.

Note: For best results pause the movie till it has loaded completely, then press play

Example 3.4: Gaussian Pulse Generator

(Titchener & Stimplfe,1983) employ a gaussian pulse generator to model laser-induced interference, in "resonance fluorescence measurements of OH number density". The simulated laser pulse is obtained as a solution to the first order non-linear differential equation:

Schematic for implementation of pulse generator.

A first integrator simply provides a constant input to a second which generates a time function ramp. A third integrator solves the 1st order non-linear equation to give a single pulse using the scaled product of its output and time as input. An appropriate choice of weights sets the relationship between the rate at which the computer generates the function, and the real-time laser pulse.

Command line:

PERTECS -c gaussian -D 20

Here the

-D 20

indicates that the output telemetry rate is to be down-sampled by a factor 20. Lowercase, i.e.,

-d 20

indicates down-sampled but the output is derived by averaging the 20 samples rather than a simple re-sampling of output stream.

PERTECS display of time ramp and gaussian pulse.

Connections implementing above schema.

This example appears in a modified form in (Titchener & Stimpfle,1983) as a excitation. Pulsed laser-induced fluorescence is used to detect OH number densities in situ in upper atmospheric experiments. Such a measurement is compounded as the laser simultaneously causes photo-dissociation of the ozone-yielding excited oxygen atoms which react with water vapor to form additional OH within the laser beam. To model the magnitude of this laser induced interference contribution a detailed model was constructed from primarily integrators, each representing ro-vibronic states of molecular oxygen etc. The schematic included here illustrates the importance of the integrator in modeling time variant states in complex dynamical systems. A full description of the system is provided in (Titchener & Stimpfle,1983).

Reproduced from the aforementioned paper. Here the interconnected integrator arrays model rovibronic energy states and the interconnections, the state-to-state energy transitions. Each array is checked to ensure mass-balance is preserved to within acceptable bounds for the duration of an 'experiment'. See paper.

(A full simulation will be included in due course, primarily as a benchmark to illustrate speed improvements since the 1983 implementation. The original software ran on a Signetics 2650 8-bit microprocessor, limited to integer operations. This completed a simulation run in around 20 minutes! LAter an implementation using an LSI-11 still using 32 bit integer arithmetic, reduced this to about 45 seconds per run. PERTECS now uses 64-bit double precision floating point with sample rates to 1MHz.)

Example 3.6: Lorenz System

To be completed.

Schematic for Lorenz equations.

PERTECS display of Lorenz trajectory.

Note: For best results pause the movie till it has loaded completely, then press play

Example 3.7: Rössler System

To be completed.

Schematic for Rössler equations.

PERTECS display of Rössler trajectory.

PERTECS display of Rössler time series.

Example 3.8: Chua Oscillator

To be completed.

Example 3.9: 1D Wave Equation

The (http://en.wikipedia.org/wiki/Telegrapher's_equations) ( telegraphers equations) belong to a class of differnetial equations known as hyperbolic equations. The telegraphers equations may be simplified to the simple lossless one dimensional case:

Since the analogue computer is more often than not representing functions of time, and here we have an equation which assumes the displacement to be a function of both time and space, we need to model our transmission medium with a pair of integrators at incremental positions in x. Lets assume we have a wave on a string, the string being modeled by a series of mass particles connected elastically but constrained to move only in the y direction. To observe our wave we need similarly a scope channel for each incremental position. In this example we have set up 200 scope channels, connected to 200 pairs of integrators, each pair of integrators modeling the displacement y_x velocity y'_x and acceleration y"_x of the point mass at position x. (To be completed.)

Schematic for 1D wave equation.

PERTECS display of a pulse injected on a "wire" giving rise to the 1D traveling wave. The two pulses reflect at the end of the line and travel back to cross each other in the inverted form.

Example 3.10: Hodgkin Huxley Equations

Note: For best results pause the movie till it has loaded completely, then press play

To be completed.

Schematic for HH wave equations.

PERTECS display of axon membrane potential upper, and associated recovery wave (lower), brought about by a stimulus pulse.

Example 3.11: real-time smoothing and filtering of multi-Channel EEG Preprocessing

In this example a two stage smoothing filter is used to remove 50Hz mains hum from EEG recorded at 1KHz. This is and differentiated and reintegrated to remove any DC offset while improving the depth of the notch filtering at 50Hz.

The purpose of this preprocessing step was to remove a large part of the noise spectrum prior to computing T-entropy (see later example of T-entropy meter) This process ultimately entails the application of a bi-partitioning threshold to create a symbolically encoded series from which the T-entropy is computed. The resultant symbolic series is then essentialy independent of signal amplitude, being principally a measure of the zero-crossing characteristics. For more information oin this have alook at (Hughes, Titchener, Taylor, Chen, 2006, Titchener, Jul 2006, CHEMECA), (Titchener, Sept 2006, NOLTA) and (Titchener, Jul. 2008, CSNDSP) Differentiation is the mathematical equivalent to an ideal capacitively coupled input stage at an amplifier input.

Showing one channel only, cascaded differentiation and integration gives real-time smoothing and differentiation of EEG.

Top graph shows the frequency response of the smoothing & differentiating filter functions where both use the 33 point filter size. The aim is to remove principally the 50Hz mains signal. The two dips near the 50Hz derive from the smoothing and differentiating filters respectively. By increasing both the smoothing and differentiating filter sizes to 25 and 45 respectively it is possible to bring these in to coincidence, without unduly compromising the 100Hz harmonic filtering performance. The subsequent section on filters describes the techniques used here to determine the filter responses.

In a final filtering stage the signal is reintegrated but with a damping constant to finally remove any DC offset. The frequency response of the three stage filter is given here.

Top: EEG 84 channels of uniltered. Bottom: the same data exploiting the three stage filtering revealing considerable clarity enhancement. Note the strong presence of alpha signals in the near channels especially, arising from the subject having "eyes-closed" (refernce here to Berlin Group).

20 seconds of EEG, filtered and downsampled to 100Hz for replay.

The traces here are derived from real EEG recorded from a Brain Products device and the author as 'guinea pig' for the experiment. The format of the Brain Products device is raw-data format that is accepted directly into PERTECS. More is said later about the supported telemetry formats in the section on Input & Output.

Example 3.12: Smooth Sorting Algorithm

Example taken from the Harvard Robotics Group.

Schematic for the smooth sorting of ten values, preinitialised on the integrators (right).

PERTECS display of outputs of the integrator array, showing the sorting of ten values.

3.1.2 The Math-Function Module

The inclusion of elementary math functions adds flexibility in simulations and instrumentation.

Fig. 3.11: Math module as depicted in the build panel.

Here we illustrate the math module by way of a basic audio signal generator. The groing PERTECS tool set includes audio interface tools audot and audin, stereo output and input interface tools supporting the standard sample rates to 192KHz with the data streamed over stdio. (PERTECS will shortly include these drivers directly, configurable at build.) The audio interface on most computers these days include high quality A/D & D/A converters incorporating delta-sigma 1-bit conversion to 24-bit resolution and covering the range to 20KHz. PERTECS may be used in conjunction with audot to generate real-time streaming mode audio signals for practical test and measurement applications.

Example 3.13: Pure Sine Generator

We again use two integrators to generate a time ramp function. The initial value on the first integrator sets the slope of the ramp function input to the math sine module and thus the frequency of the signal. The initial value on the second generator sets the starting value for the time ramp which, modulo 1 , determines the starting phase of the sin function . As the sin function in the math module incorporates the constant , the input is implicitly measuring the number of frequency cycles from time t = 0. The output is . The schematic for the simple sine generator is given below.

Fig. 3.12: schematic for simple sine function generator using a math function module.

Example 3.14: Swept-frequency Sine Generator

Setting in , and further setting frequency to be an increasing function of time gives the function needed to achieve a swept frequency . The schematic is shown below. This example It generates a single swept frequency pulse from DC through to approximately 10KHz, with constant amplitude, but also with an amplitude that is reduced inversely with frequency.

The second part of the schematic below uses a second math module to output a second audio signal scaled inversely by time to simulate the de-emphasis typical for the higher frequencies in recorded audio sound.

Fig. 3.13: schematic for simple sine function generator using a math function module.

The unix command line to output the audio signal is:

PERTECS -config sine -r  | audot -rate 96000 -r

Both of these examples are ultimately limited by the range and resolution of the time ramp (represented internally by double floats) In the next section a comparator is used replacing the integrator time ramp with a sawtooth waveform that avoids this.

3.1.3 The Comparator Module

The comparator is especially useful, and may be used in a variety of ways and configurations not immediately clear. The comparator has a single input, f(t) which is passed directly to one of the outputs as a delayed signal g(t) = f(t-1) i.e. reflecting a one sample time delay. Further outputs take on the values '0.0' or 1.0' depending on whether f(t-1) < 0, f(t-1) ≤ 0, f(t-1) > 0, f(t-1) ≥ 0, f(t-1) = 0. The comparator is thus useful in determining threshold behaviors in circuits as the examples below show.

Fig. 3.14: comparator module as depicted in the build panel.

The next two examples show how a comparator may be used to give the classical hard limit ``bang-bang'' circuit ("Schmitt" trigger), and circuit with idealised hysteresis.

Example 3.15: Schmitt Trigger

Example 3.16: Hysteresis

Example 3.17: Diode

The comparator may used to emulate the classical ``diode'' transfer function.

Example 3.18: Sawtooth Function Generator

Here the comparator generates an offset saw-tooth wave and a pulse corresponding to the start of the ramp cycle. The output from the ≥ 0 comparator reset pulse may be used in a variety of functions. Here it is shown driving a bistable circuit thus creating a square wave output.

Example 3.19: One-Shot Monostable

An adaption on the above, the one-shot is a mono-stable that outputs a fixed duration pulse upon receipt of an input trigger.

Example 3.20: Bouncing Ball

Schematic for simulating bouncing ball.

Bouncing ball trajectory.

Example 3.21: Continuous Sine Function Generator

This example gives a continuous sine generator that utilises a comparator to generate s sawtooth as input to the math sine module. The input to the comparator, shown here as 0.005 , determines the slope of the ramp and thus the frequency of the tone. The ramp begins at -1 (set by the feedback constant) and terminates at 0 . The math sine module incorporates the 2\pi in its operation so that the input [-1,0] or for that matter [0,1] maps into the covers the range [0, 2\pi] radians.

Example 3.22: Audio frequency sweep generator

As in the previous example a comparator is used to generate an extended time ramp function bounded by [-1000, 0] . The square of the time ramp output is delivered to the math sine module to obtain a swept frequency (high to low). To sweep low to high requires a few further connections shown in the second schematic.

An adapation of the above example involves adding a second math module to obtain a pair of swept cos and sin functions, that may be used in tandem to compute a filter response across a swept spectrum. Using the simple result that the sum of the squares of the orthogonal components sum to the square of the amplitude, one may compute the response as half the log of the sum of the squares to give the response on a scale corresponding to dB (deciBells).

In effect many different circuits may be inserted in place of the test filter. In this approach an identical pair of circuits is used to process the quadrature pair of signals.

It is perhaps instructive to explore the frequency responses of the differentiation filters that are a part of the Calculus module. The following graphs are computed by down sampling the signal generated by the above schematic, to obtain a swept frequency range that corresponds to the nyquist sampling rate corresponding to the internal cycle rate as which PERTECS is operating. Graphs are computed for filters corresponding to sizes: 5,9,17,33 . (Note that all odd sizes in the range 5-129 are now supported by PERTECS.)

3.1.4 The Polar Module

These are additional Math functions intended to facilitate the use of polar co-ordinates. The next example shows how this may be used to reveal the phase properties of a filter system under test.

Fig. 3.14: Module for polar coordinate calculations.

These are additional Math functions intended to facilitate the use of polar co-ordinates. The next example shows how this may be used to reveal the phase properties of a filter system under test.

Filter phase

In the previous generator we have sweep-frequency pair and , with , and filtered signals and . We wish to derive the phase angle . We also create a version of the sweep generator that provides an alternating series of the sweep function pair, , which reduces the test configuration to a single in-line circuit, instead of a pair of test circuits. The penalty we pay for this is the need to capture the alternating sweeps of serial data in delay modules to enable our computation of the amplitude and phase to proceed as before.

Starting with the equation

the real and imaginary parts gives us the familiar trig identities (which I can never remember, hence)

Rearranging Eqn \ref{second} equation to eliminate in Eqn \ref{first} :

Alternatively rearranging Eqn \ref{second} equation to eliminate in Eqn \ref{first} gives :

Thus

Multiplying top and bottom by the input and output signal amplitudes S_{in} S_{out} respectively and computing the arctan yields the filter delay \phi . Accordingly:

Writing

this sum and difference of products is computed at the input to the polar module using the two input arctan function .

In our implementation the sin and cos sweeps in fact alternate in sequence giving rise to an alternating sign for . This is handled in the final circuit with the a weighted sum gated by the toggle signal.

Example 3.23: Square Wave Generator

A is used to generate a sawtooth. Combining the sawtooth with an input offset raises the sawtooth accros the threshold of a second comparator delivering a variable mark-space ratio squarewave.

% In a variation of this example a pulse width modulator is created. combining a slow changing sine generator using integrators with the sawtooth generator using a comparator, and

(Lets do a three phase pwm output for stereo )

Example 3.24: The Logistic Map

That the system is in fact operating in discrete time steps allows us to further simulate recurrence equations. The following circuit implements the logistic map is The logistic equation has the form

3.1.5 The Entropy-Function Module

Entropy module as depicted in the build panel.

Example 3.25: A Real-Time Acoustic Entropy Meter

Requires taking the input from an audio channel and passing this to the entropy module. The entropy module computes the T-entropy for a binary partitioned buffered block of input data. returning a result that computed every step increment. The step increment here is set to 200 times the sample size, and the buffered block is set to 2000 samples.

{\small \tt audin} is a tool which samples the audio input and passes the stereo data by stdout to PERTECS which then computes the entropy and passes both this and the sampled data to streamML ({\small \tt sml}) for spod to display. Since the entropy is computed 10 times a second its data rate is considerably below the input sampling rate, the PERTECS call is used with a downsampling switch reducing the output to be displayed from the 48kHz of audin to 4.8kHz, more suitable for real-time visualisation of the data and entropy.

Circuit connections for a simple accoustic Entropy scope.

Here the entropy responds to signals that are seemingly lost within the background nose. In fact the entropy scope is responding to the sound of hands being gently rubbed together approximately 20 cm from the microphone, measured in a room with significant background noise levels.

Multiband Entropy scope.

3.1.6 The Filter Module:

Currently supports a limited range of IIR filters. Allows IIR filter designs to be incorporated into the build, using code courtesy of the late R. Fisher. In the module presets one may define which type of filter to be used, Cheybechev, Bessel, or Butterworth, selected with an appropriate Ch, Be or Bu designator. The buffer size indicates the order of the filter and is limited to range 1-10. The operating band selection is set either to Low pass, High pass or Band pass designated by Lp, Hp, or Bp. If a Chebyechev filter is selected the allowable ripple in the pass band must be selected (e.g. -0.5 for 0.5 dB ripple). The corner frequency (or frequencies) are specified in normalised form, i.e. in the range 0.0 - 1.0 where 1.0 represents the frequency equal to half the sampling rate.

Filter module as depicted in the build panel.

3.1.7 The FFT Module:

Fourier transform module as depicted in the build panel.

The FFT module provides efficient real time computation of signal spectrum. The buffer size determines the window width of the FFT and should be set to a power of 2, e.g. 4096.

3.1.8 The Noise Module:

3.1.9 The Delay Module:

3.1.10 The External Module:

Entropy module as depicted in the build panel.

3.1.12 Input/output Modules

Input Modules

The input telemetry channels as depicted in the build panel.

Output Modules

The output telemetry channels as depicted in the build panel.

3.1.13 Preset Pots

The pots modules as depicted in the build panel.

3.1.14 Trace (Graphics) Modules

For high performance display of traces.

3.1.15 System Control Module

3.1.16 XML File extensions

For setting the extensions on configuration file set.