Overview

This is  a first pass at showing what I am aiming for as a target architecture. The general scheme is that control signals and parameters pass between nodes using the Erlang switcher.  Sampled data however will reside in shared memory which will be mapped by nodes that need to manipulate sampled data. Should those nodes be distributed then parts of the memory mapped data will also be distributed and managed by a synchronisation protocol. Generally speaking it is expected that most nodes manipulating this data will reside on the same machine. The display and metering node may reside on a different machine and this portion of data in that case would need to be synchronised. The reason for the dual mechanism is performance and flexibility as it allows many more processes to participate in the sampling process than would otherwise be the case. For example:

• The acquisition can be separated such that it can deal with sound cards or USB interfaces without having a performance hit of a extra hop. 
• Multiple displays can use the data without it needing to be explicitly sent to each. 
• Multiple staged data can be used such that data in all parts of the pipeline can be made visible for various purposes. 
• Data can be shipped in/out to virtual sound cards or other programs  by a separate process without overhead.
• There is potential to orchestrate the DSP in various ways, dynamically assembling the pipeline or running multiple DSP processes for different purposes.

In order to cater for virtually any SDR configuration the system is highly componentised and loosely coupled. Components may be Erlang nodes or Erlang processes as appropriate. Loose coupling is achieved through the messaging bus. The shared memory is somewhat more tightly coupled across those processes that map it. Access to shared memory will be protected and synchronised.

There are multiple possible nodes in the areas where there are differences between systems. In general only one node would be active in each set in a given system but there may well be cases where more than one would be active.

The relatively large number of nodes in the system requires more sophisticated routing than available with the current class system. In addition to those shown above there can be multiple UI parts and scripters. These routing requirements will be dealt with as and when required.

One further consideration is the physical device access for samples and control signals. In some cases these will be on separate I/O devices; parallel, USB or sound cards (real or simulated). In other cases they may be shared on the same device either in separate channels (end points) or using in-band-signalling. The logical architecture should retain separation of different functions in all these cases.

Stream Management

There will be different stream management components, two are envisaged at present, for audio cards and USB devices. The audio managers will be much like those in the system at present with the functionality moved from the DSP processing chain to a separate process. A USB stream manager will initially be written for the HPSDR OZY protocol and at present will assume in-band-signalling for the hardware control. The stream manager will be responsible for separating/combining the control and data streams and for correct routing of the signals and data. Data will be acquired or emitted to/from shared memory directly. Control signals will be routed to the hardware controller. Signals from the hardware controller will be sent to the stream manager for transmission.

Access Control and Synchronization

Access control will be implemented by some form of global lock. Erlang provides a global locking mechanism which should be suitable. The granularity of lock will depend on the contention profile. A course granularity is assumed at present. Synchronization will be achieved by a separate state machine with the state variable and state-transition matrix held in shared memory. This will also be covered by the locking mechanism. When a node has work to do involving shared memory access it will take the lock, queuing as necessary. If the state machine is in a state that allows the required action the action will be performed, the state machine moved on and the lock released, otherwise the lock will simply be released and the node will back off and try a little later. This process will ensure that data acquisition, signal processing, data display etc trigger at the right times. It is possible that this mechanism could be extended to regulating the tuning and scan rates to ensure they don't exceed the rate at which samples can be acquired and processed or if they do that there is an audio cut-off during rapid frequency excursions.

Components