Sunday, July 20, 2008


I have implemented some early code to support Phil Covington's Quicksilver receiver. Thanks to Ken K9VV for access to his receiver over the internet. Still needs a lot of work, but does prove the basic concept.

Thursday, July 17, 2008

Windows XP

Yes, I finally succumbed, I have run Windows XP to test the Java GUI running on it. And it worked!!!

Actually the screen grab shows the Java GUI running on Windows XP remotely controlling the server which was running on a Mac with a Softrock connected to it using the built in sound card.

I see no reason why this should not run on Vista as well as this part is 100% Java.

Wednesday, July 16, 2008

State saved

svn version 129 and greater now saves state and restores the layout when restarted.

No more having to start all the objects each time ;-)

SDR1000 working

The latest code is now working with the SDR1000 (in receive).

Also added debug windows for DttSP and SDR1000 to monitor the commands being sent to the fifos.

Getting the SDR1000 working with this code just required writing an Object that communicated with a fifo to send commands to the hardware which is connected via USB or parallel port. The SDR1000 sends a message to set the oscillator offset to 9000 Hz, which the DttSP object receives and sends to the fifo to control sdr-core. Any messages to se the frequency are received by the SDR1000 object and translated into a SetFreq command to the hardware. No other objects had to change.

Monday, July 14, 2008

GUI Changed

I have changed the user interface to create a JFrame and then add the different components as JInternalFrame objects rather than add them to the desktop.

This means the relevant components for a specific radio can be kept together and will make it easier to have different configurations.

The initial state is an empty window. The File menu lets you start the different components within the window. You need one instance running the RMI server and Message Switcher as the main server. You will also need a DttSP object and a Softrock Object with the DttSP object running on the machine with the soundcard you are using. You can then start other instances and add the different UI objects as required.

The image below shows 4 instances all running on the same machine, one of which is running the RMI server and is also running the DttSP object. The other instances locate the RMI server to register their components to receive the required messages and show how they can be configured. Each of these could have been running on a different machine.

This version is not in the svn archive yet!

Saturday, July 12, 2008

RMI code now in svn

The version in the svn repository is now quite useful and at this time the version number is 106.

The RMI based code can be checked out using the command (without the quotes):

"svn checkout --username guest"

This will create a directory called Radio which contains the source code as a NetBeans (6.1) project.

Java 6 is required to run the software.

You do not have to install NetBeans to simply run the software. It is only required if you want to modify the source code.

To run the software there are 3 main scripts in the Radio directory:

  1. start_base will create the fifos (if not already created), start jackd, start sdr-core and then make the jack connections. Depending on your soundcard this will need changing. Note that there is also a start_base_64 which runs the sdr-core compiled for 64 bit Linux. The 32 bit version is starting jackd for an FA-66. The 64 bit version is starting jackd for a Delta 44. Currently only UNSUPPORTED (i.e. motherboard sound card), Edirol FA-66 and M-Audio Delta 44 cards are supported. This does not mean that other cards will not work, it just means the calibration will not be correct.
  2. start_radio will start up all the java code that implements the radio. You will need the host name of the server machine to be resolvable to it's IP address on the network if you want to run the remote GUI. The simplest way to do this is to add an entry to the /etc/hosts file. If you do not then the IP address that gets resolved for the RMI will be the localhost which will not be the correct address for the remote clients to use.
  3. start_remote will start the java GUI code running on a remote system. It requires you to be running the java code on the server machine. The script will need changing to specify the IP address for the RMI registry.
This software includes compiled versions of sdr-core for 32 bit linux and 64 bit linux (in Radio/bin/linux). It assumes you have installed jack on your machine.

The Java GUI code should run on any platform supporting Java 6. I have tried it running on a Mac and Linux. I have not tried it on any Microsoft OS as I don't have a system wth their software installed.

Running on Ubuntu 64 bit system

I have finally built a 64 bit 8.04 Ubunto system running the 2.6.24-19-rt kernel.

I tested the new RMI code using the Delta-44 card. I had to recompile sdr-core for the 64 bit system, but not the Java code ;-)

Wednesday, July 9, 2008

Resizing windows

The Panadapter and Waterfall windows are now resizable.

Tuesday, July 8, 2008

Improved Panadapter and Waterfall display


Having talked to Frank Brickle at Dayton I decided it would be an interesting experiment to put together an SDR radio where the components are all independent and communicate using Java RMI (Remote Method Invocation).

The first experiment is a simple interface to control a Softrock.

A quick view of all the components running on a Linux box (Ubuntu 8.04):

Click on image for full size image

In addition to the UI components there is a central 'Radio' component running that handles the registrations and message distribution, a DttSP component that handles communication with DttSP and a Softrock component that handles the Softrock hardware. Actually there is nothing to do for the hardware, but it does translate the frequency changes to messages to set the oscillator frequency which is handled by the DttSP component. The Softrock component can be replaced with an SDR1000 or a Flex5000 component that actually controls the hardware.

Note the network activity. This was because concurrently I was running the display components on a MacBook Pro:

Click on image for full size image

I started 2 copies of the Panadapter display on the Mac. Each spectrum snapshot is 4096 float samples. which translates into 16384 bytes for each snapshot. At 15 per second this is ... well you can work the math!

All controls stay in sync, regardless of the host thay are running on. When a VFO frequency is changed all the other VFO's and Panadapter displays will change frequency. When a Panadapter display is dragged the VFO's and other Panadapter displays stay in sync.