Installation

This is just preliminary information. Essentially installation should be straight forward on XP or Linux. There are a number of pre-requisites but once they are installed the rest is easy.

Pre-requisites

Erlang, GTK+ and the usual suspects which should be available if you run PowerSDR i.e. fftw, pthread, [PortTalk & PortAudio (if on Windows)], [ALSA, Jack, Python (if on Linux)]. The DttSP software is built with the application on Windows so nothing extra is required. There is also a build available on Linux but in this case it is a separate application. I also have a library build of PortAudio.

Application

The application is two executables, one for the user interface and one for the application. The switcher is an erlang file which needs the erlang runtime system to execute.

All three nodes are run from the command line. The best way to appreciate this is to look at the screen shots. I have pointed to the XP shot as this shows the command line arguments better.

What	Command	Comments
switcher	erl -sname switcher -setcookie sdrnet sysmon:system_startup().	This starts an erlang interpreter telling it the name of its node is switcher. and its cookie is sdrnet (all nodes must use the same cookie). When erlang starts it also automatically starts the erlang port mapper which is required to resolve addresses from names so you don't have to talk IP addresses. The second command starts the switcher application. Note the full stop is required to terminate the command.
application	erlink-sm -n node -h host -c myclass -s switcher -u uiclass -p state	This starts the application node where : 'node' is the node name to be given to this node (nominally c2 for cnode 2). 'host' is the host it is running on (the computer name). 'myclass' is the class of this node (nominally 'sm'). It must match the -m switch in the user interface command line. 'switcher' is the address of the switcher such as switcher@mycomputer (note the name must be the one given to the switcher when started and the host is the name of the computer it is running on). 'uiclass' is the class of the user interface node (nominally 'ui') (it must simply match the myclass parameter you give to the user interface node on the command line). 'state' is the path to the directory to hold the state files. The directory must exist.
user interface	erlink-gtkmain -n node -h host -c myclass -s switcher -m smclass	This starts the application node where: arg1-4 are the same as above except the node name must be different (nominally c1) and of course the uiclass is now the smclass (nominally 'sm') as these two exchange messages.

About the build environment

As of now the entire source tree including DttSP is held in a local SVN repository with a separate dependencies directory which is not under source control and holds PortAudio (Windows only) and the Jack Python interface (Linux only). There is one source line for the system with some conditional compilation to account mainly for the different hw control and DSP interfaces.

There were several options for managing the build. Make files was one option but requires quite complex juggling to make it work on both platforms. In the end I used Visual Studio Express for C++ on Windows and Anjuta on Linux. For the Erlang files a text editor is quite adequate but I used Eclipse with the Erlang plug-in as it gives syntax highlighting and automatic compilation with error indications. Both build environments are in SVN.

Startup

When the user interface starts (you should start nodes in the order given above) it sends an initialise message to the application. On Linux this will cause some python code to execute which starts up Jack and DttSP and then connects them. When you power-on/off the audio is enabled and disabled. On Windows the PortAudio system is initialised and made ready. You can see the startup for Linux in the screenshot.

Important-1

There is an additional erlang file called scripter in the ebin directory. This is mostly a demonstration but provides one necessary feature. There is no option panel at the moment, most defaults and the auto-search functions for audio cards should get things up and running. However, I don't have an RFE and you may (probably will) need to turn on the RFE flag. To do this the scripter can be used. This allows for a few programmed commands to be sent to the application, others are easy to add if you know how (ask if interested).

For simplicity run the scripter from the same console session you are running the switcher.

erl> Pid = scripter:register().

erl> scripter:rfe(Pid, 1).

This will send a command direct to the application to turn the RFE flag on.

erl> scripter:deregister().

Important-2

When using this on Linux the pipes (actually only the command pipe is used at the moment) should be set up in the same directory the executable is launched from. There is no facility to give a path at the moment.