Glade
Linux
XP

What does it look like

The first question usually asked, are there any screen shots. Well I have to admit it's not much to look at yet, but for what its worth here are the obligatory shots.

This first one shows the Glade GUI development environment (running on XP, but of course just as capable in its home territory of Linux). This shows the 4 separate windows comprising the interface. The options window is not yet hooked in but is based on a properties view commonly found in development environments.

This second shot shows the system actively running on a Linux Ubuntu box under Gnome.

The third one shows it running, of course under XP.

It's also perfectly happy running across machines, which can be the same or different OS's. There is a fuller explanation of how this works in the technical section.

Quick start to ERLINK-SR

This is the quick start to understanding what this project is about. It is non-technical and written from a user perspective. I hope it is understandable - if not please shout!

First things first, the project name is ERLINK-SR standing for ERlang LINKed Software Radio. The modules comprising the system are all named erlink-xxx. At present there are three modules (it's just a start). These are :

erlink-gtkmain	The main user interface (in fact the entire user interface in the current implementation). The 'gtk' bit is because it is built using the GTK+ user interface library so it leaves room to have a erlink-pythonmain or erlink-csharpmain etc.
erlink-sm	The application, for want of a better name (the 'sm' actually stands for state machine - but I said I would keep this part non-technical). Think of it as all the code which is not directly concerned with managing the controls on the screen, the hardware or the DSP.
erlink-sw	This is the hub of the communication between other modules of the system, known as the switcher, obviously this is what the 'sw' stands for. Think of it as the telephone exchange. Users of the exchange must register so the exchange knows who they are and will therefore be prepared to switch messages on their behalf. There may be some exceptions where the exchange will set up a channel directly between subscribers but in general all messages go through the switcher.

One term that will be used is node. It so happens that in the current implementation each module is also a node. A node is nothing more than an executable, multiple nodes can run on the same machine or on different machines. The only way nodes communicate is by sending messages to each other, generally via the switcher.

A simple use-case

The following diagram shows a typical use-case (a use-case is just a term that means a scenario of one use of a system, such as logging on). Something external to the system will always initiate a use-case such as a user pressing a button or a CAT device sending a request. The use-case I will explain here is the user pressing the 'PowerOn' button but the sequence holds true for just about any user interaction. The messages are labelled in sequence and explained below.

For ease of explanation the modules will be called user interface, application and message switch rather than their cryptic module names.

Message number	Description
1	The user interaction pressing the button.
2	The user interface sends the message 'POWER-ON' to the message switch.
3	The message switch relays this message to the application. The application performs all the duties required of a power on. This will include initialising the hardware and DSP and preparing updates for the UI.
4	The application sends the user interface updates to the message switch. Note that these are completely agnostic to the type of user interface. It would be the same update data for GTK+ as for Python as for C#. The updates are sent as a single message although there might be many individual updates.
5	The message switch forwards the updates to the user interface which receives and applies the updates.

There are a few subtleties to note - ignore this if the above was enough information. You might be wondering what value the message switch adds, why not just send the messages direct? What it does is to make it a level playing field, not all modules are as capable as others.

First thing it does is provide a store and forward queue for each connected node. So if the consumer can't take messages fast enough it will hold on to them until requested. This also decouples nodes completely from each other and thus removes dependency issues where node A depends on node B but node B is not running or not reachable.
It also provides full asynchronous paths with an option of forwarding messages to a node as they arrive or keeping them until the node asked for the next message. Many nodes find it hard to be a client (a sender of messages) and a server (a receiver of messages) at the same time. A client can send a message and wait a response, a server can receive a message and send a response. The message switch will cope with nodes that want to be one or the other or both (native Erlang nodes can easily be both, others may struggle).
Importantly it also provides routing mechanisms. These are rudimentary at present (see the technical description) but will get more advanced in the future.

This capability offered by the message switch to queue messages until the next is requested is very useful for our two communicating nodes. The power-on interaction is actually the most demanding because multiple updates are applied to the user interface as a result. Some of those updates generate new messages to the application which responds with more updates. The user interface would rather forget the new updates until it has finished with the current batch, this much simplifies the programming model.