Java GUI and GTK+ GUI for DttSP and the SDR-1000, Softrock and HPSDR

2009-11-27T06:17:00.001-08:00

I have moved the blog to http://g0orx.blogspot.com/

Multiple Mercury Receivers

2009-09-11T02:52:00.001-07:00

I am testing the new Mercury/Ozy code to support multiple receivers on a single Mercury card.

I have changed the architecture so that I now have a server application talking to OZY over the USB bus and talking to client applications over UDP sockets.

A client application can connect to the server requesting a specific receiver. The server currently only allows 1 client connection for each receiver.

This is the first attempt to run 3 copies of ghpsdr. Needs some debugging as the spectrum display is not correct, but the basic concept is there.

Split Transmit

2009-08-27T08:38:00.001-07:00

Trying to design a usable UI as the capabilities get more complex is not easy!

I have added the split rx/tx full/half duplex capability. This is using VFO-A for receive and VFO-B for transmit. Now that VFO-B is used for this I have changed the sub receiver to maintain it's own receive frequency.

In the image above the main receiver is receiving on 14.195200 MHz, the sub receiver is receiving on 14.219700 MHz and the transmitter is transmitting on 14.241900 MHz. All running full duplex! Of course, the transmit frequency does not have to be in the displayed passband, but then it would not be visible!

I am also adding transverter support for the split frequency mode mainly to support working cross band on the satellites.

Note that this is currently working with a version of the firmware that is not yet generally released.

Next major UI design issue will be how to support multiple receivers both within one Mercury card and with multiple mercury cards.

AO-51 Mode-S

2009-08-20T01:58:00.001-07:00

Click for full size image

I hooked up my Mode-S down converter and quad patch antenna as I saw that AO-51 was running in Mode-S for the next few days.

Here you can see the Doppler shift as AO-51 approaches my QTH. Running at 4 frames per second for the display update so the waterfall represents 50 seconds. I need to add an interface (CAT?) to allow another program to control the frequency. On a subsequent pass I used the sub-rx to track the doppler manually, leaving the main rx on centre frequency of 2401.200.

The antenna was simply sitting on the window ledge of the shack close to a wireless router, hence the strong qrm.

ISS

2009-08-19T00:26:00.001-07:00

Click for full size image

Here is a screen dump of part of an ISS pass (using a Microwave Modules 2Mtr Transverter) showing the bursts of AX.25 packets.

You can see the doppler shift from high to low frequency as it passes over. I slowed the display update rate to 5 samples per second, so the Waterfall represents about 40 seconds.

The 3 strong signals showing up on the Bandscope at around 20MHz (136MHz) are from Gatwick Airport which is close to my location.

Video of sub rx

2009-08-02T01:50:00.000-07:00

The main rx audio is panned to the left and the sub rx audio is panned to the right.

The video was created using recordmydesktop running on Ubuntu 9.04.

iPhone video running on Simulator

2009-07-28T04:44:00.000-07:00

Can't work out how to get the audio working on the iPhone simulator!

Now have the band buttons working correctly.

Sub RX

2009-07-27T13:06:00.001-07:00

Added Sub RX for tuning second receiver (DttSP thread) across the passband.

Note the TX controls beginning to appear - coming soon.

Audio streaming to iPhone

2009-07-10T11:33:00.000-07:00

I now have the audio streaming from ghpsdr to the iPhone. I am sending it at 8K samples per second and sounds OK. Did a very simple implementation of taking 1 in 6 of the 48K samples being fed back to Mercury. Also just sending one channel.

Now it needs the ability to change band, filters and mode for a fully functional internet radio.

I should get a development board for the iPhone next week which will let me dock the iPhone and get access to line-in and line-out. I intend to look at taking the I/Q data from a softrock receiver and processing it directly on the iPhone. Should make a great little portable receiver.

iPhone

2009-07-07T05:42:00.000-07:00

I now have the iPhone working well displaying the spectrum from ghpsdr.

I have also added a button to configure the application.

Next step is to look at adding the audio stream.

More iPhone

2009-07-04T08:46:00.000-07:00

I have now got the iPhone working when I can see real time spectrum from ghpsdr using a tcp socket to get the data.

I also added the ability to change frequency by dragging on the iPhone display.

Now to try to get the audio streaming to the iPhone as well ;-)

iPhone teaser ...

2009-07-01T04:31:00.000-07:00

I got a little side tracked this week playing with the iPhone SDK. I wanted to see if I could get something working that will, at a minimum, display the spectrum for the currently selected frequency so that I could monitor HPSDR remotely using my iPhone.

This is some prototype code running on the iPhone Simulator (it does run on my iPhone as well). It is updating the display 15 times per second. The data is currently 2 seconds of spectrum samples (30*4096 samples) that I captured using ghpsdr and wrote them to a file that are repeated while the application runs.

Next step is to add the ability to ghpsdr to write them to a socket connection and add the code to the iPhone to make a socket connection to ghpsdr.

Better startup ...

2009-06-19T09:07:00.000-07:00

The code now will detect that ozy is not powered on or plugged in and allow the user to retry.

It will then run initozy if required.

Added first cut at support for transverters

2009-06-19T09:00:00.001-07:00

The svn store now has the first cut of code to support transverters:

svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk/N6LYT/ghpsdr

Major updates to ghpsdr

2009-06-07T14:22:00.000-07:00

Made some changes to cleanup the GUI and added support for clock source selection.

The version of DttSP has been replaced with a ported version of the current Windows DttSP code in preparation for the development of the transmit code to support Penelope.

Layout changes for ghpsdr

2009-04-14T14:05:00.000-07:00

rev 1022 of ghpsdr now contains some layout changes along with some changes to the band stack.

Click on picture for full size

GTK+ GUI running on Mac

2009-04-06T08:00:00.000-07:00

I finally managed to get ghpsdr compiled and running on the Mac. There are some USB performance problems that need to be resolved, but it is running. Required changes to the semaphores (I had forgotten that the mac did not like unnamed semaphores) and the libusb_open_vid_pid does not claim the interface as it does on the Linux version.

I will try to update the repository in the next couple of days.

Click on image to see full size

192K and display updates 30 times per second

2009-04-05T13:11:00.001-07:00

I tried running at 192K with the display rate for the Panadapter/Waterfall running at 30 updates per second. Uses about 60% of the cpu (3.4GHz Intel dual core), but still no pops on the audio using the pre-2.7 Mercury/Ozy code that Phil will release when they have resolved a couple of problems. Now I can read the CW ;-)

Click on image to see full size

VLF Radio Time Signals

2009-04-02T15:28:00.000-07:00

I was looking at me radio controlled clock and wondered what the signals looked like that they use. First time I have tried Mercury on VLF frequencies.

You can see the 3 time signal stations MSF on 60kHz in Rugby, England, HBG on 75 kHz in Prangins, Switzerland and DCF77 on 77.5KHz in Mainflingen, Germany.

ghpsdr - the video

2009-03-31T14:30:00.001-07:00

Testing a new version of the Ozy/Mercury FPGA code. Seems to resolved my problems of lost audio when switching to 96k or 192k. Still get the occasional burst of frames from ozy where the sync has been lost.

GTK+ alpha source in svn repository

2009-03-26T14:15:00.001-07:00

click on image to view full size

I have imported the source into the svn repository at:

svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk/N6LYT/ghpsdr

This includes libDttSP.a which is the version I have modified to not use Jack.

This is still very much an Alpha version. It does still have problems and not everything is completed.

To build the application there is a simple Makefile.

To run the application just start ghpsdr once it is built.

Currently it does not include any code to load the FPGA so you must run initozy before running the application. You must also have the latest FPGA code.

Functionally, each band has 3 bandstacks. The frequency/mode/filter settings will be saved when exiting the application for all the bandstack entries.

Tuning can be accomplished by left mouse clicking in the Panadapter/Waterfall window to move the selected frequency to the center of the current filter. A right mouse click will move the selected frequency to the cursor. You can also use the left mouse button to drag the frequency by holding it down while dragging. If you have a scroll wheel, moving the scroll wheel will increment/decrement the frequency by the current step amount.

You can also left mouse click on the bandscope display and it will move to the selected frequency.

The Setup button pops up a window to adjust the display settings. There are no tests currently if these are set to invalid values.

There are some problems when running at other than 48000. Sometimes the audio output will stop although the Panadapter/Waterfall and bandscope continue to function. It usually requires intiozy to be run again to get the audio back.

Remember - this is an alpha version.

GTK+ GUI moving along

2009-03-18T00:16:00.001-07:00

Gradually adding some more features including waterfall display.

It now also supports 48k, 96k and 192k sampling. There is a small problem with DttSP when I switch sample rates where it is breaking some times. Need to investigate the code I added to support sample rate changes to DttSP.

Will add the bandscope next and then it should be ready for some testing.

Once that is completed I will start on Penelope support.

GTK+ GUI for HPSDR Mercury

2009-03-14T04:25:00.000-07:00

Currently working on a GUI for Mercury using GTK+. One of the drivers for this was to see how well I could get the USB code working without Jack

I modified the latest version of DttSP so that I could link it with the GUI and USB code, and make calls directly to it to process the I/Q data. I shamelessly borrowed the external functions from the Windows implementation!

I should have a releasable version within the next couple of days. Once I have the receiver working well I will add support for Penelope for a complete transceiver.

A quick YouTube demo:

libusb 1.0

2009-02-18T14:24:00.001-08:00

Having upgraded HPSDR to v2.6 I ran into a problem readin the I/Q samples concurrently with the bandscope samples from the 2 end points.

The problem was caused by some real problems in libusb v0.1.12 (which is the version included with Ubunti 8.10) handling of threads. Version 1.0 has some documentation that implied it had fixed the problem, so I downloaded, built and installed it.

I then did a rewrite of the i/o code that uses libusb (the new api is so much easier to use).

I can now run 2 threads, one reading the sample data on EP6 and the other reading the bandscope samples on EP4 concurrently without them interfering with each other.

There are still some problems with synchronizing between ozy and jack, but that should be easier now that libusb is running correctly.

The image below shows the Mercury receiver running at 48K with an initial banscope display which still needs some work.

GTK+

2009-01-14T09:45:00.001-08:00

Some time ago I tried to write some C code using GTK+.

I was interested in seeing what it would take to create some panels that were similar to the ones designed by Beppe. The code is written to run with the version of DttSP that uses FIFO's and to work with the Softrock. If I get time I will try to update it to uses the latest CGRAN version of DttSP and to also work with Ozy/Penelope/Mercury.

I fired it up again and this is what it looks like.

Mercury Bandscope

2009-01-13T15:07:00.000-08:00

Just quickly added some support for the new bandscope capability of Mercury.

This is the first attempt at a GUI. I have not checked the code yet to validate it, but thought it was interesting as a first attempt. The full 0 to 55 MHz is being displayed. I am doing the FFT for this in the Java code and then calculating the Power Spectral Density which I am displaying.

More on Mercury running on Linux

2009-01-12T00:33:00.000-08:00

Upgraded to the latest 2.4 firmware. Had to run Windows XP to do that!

I have some basic code working with Mercury. This really is a great little receiver. Still some problems with the code that takes the data from Ozy and creates the buffer for jack but at least I can tune around and hear the audio with the occasional click because of the buffering problem.

Still running everything at 48K as I try to resolve the buffering problem.

And this shows the System Monitor when running the receiver and the Java GUI.

HPSDR Mercury card

2009-01-10T11:01:00.001-08:00

Quickly installed the Mercury card and after a couple of minor bug fixes to the code it seems to be working!

Image below using Mercury at 48000 listening to BBC Radio 5 on 909 KHz Medium wave.

Still some work to do, but the basic code is working.

sdr-core and datagrams

2008-11-07T02:05:00.001-08:00

Frank has released a new version of sdr-core that uses datagrams as the transport for receiving commands.

I have updated a version of my RMI based code to test this out and it is working with no problems. Note the output from the shell window at the top right with the "--verbose" output from the RX sdr-core.

Meters

2008-10-31T09:17:00.000-07:00

Finally found some time to do some more work on the RMI GUI.

I have now added a digital and analog S meter.

DttSP rev 233

2008-09-04T01:52:00.000-07:00

I am now running with the latest rev 233 of DttSP (sdr-core). Once I had resolved the distorted audio problem as being overloading the output from DttSP it seems to be working well.

On my dual core system running at 3.4GHz with 2MB of memory I see each sdr-core taking about 1% of cpu when there are no requests for spectrum sample.

The cpu goes up to about 2% for sdr-core when samples are being requested at 15 per second and of course the java cpu time increases because of the graphic display of the panadapter and waterfall.

Updates

2008-08-21T09:05:00.000-07:00

Made quite a few changes to the UI to include band selection, locking of the UI once the components are positioned and selection of the the Look And Feel.

These changes are now committed to the svn store.

The new Nimbus Look And Feel in Java 6 update 10 (currently beta) looks good.

click on image to see larger image

Quicksilver

2008-07-20T22:56:00.000-07:00

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.

Windows XP

2008-07-17T13:09:00.000-07:00

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.

State saved

2008-07-16T10:24:00.000-07:00

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

2008-07-16T00:49:00.000-07:00

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.

GUI Changed

2008-07-14T06:59:00.001-07:00

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!

RMI code now in svn

2008-07-12T09:04:00.000-07:00

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 https://java-sdr.dev.java.net/svn/java-sdr/branches/Radio --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:

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.
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 127.0.0.1 which will not be the correct address for the remote clients to use.
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

2008-07-12T01:49:00.000-07:00

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 ;-)

Resizing windows

2008-07-09T02:25:00.000-07:00

The Panadapter and Waterfall windows are now resizable.

Improved Panadapter and Waterfall display

2008-07-08T07:10:00.001-07:00

RMI

2008-07-08T02:01:00.000-07:00

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.

2008-05-22T06:11:00.000-07:00

Good progress with the Atlas bus and Ozy/Janus cards. I built the Atlas bus and it is all working when tested under Windows with the PowerSDR version that supports Ozy/Janus.

Last night I worked on getting udev (Ubuntu) to recognize Ozy and initialize it when it is plugged in, powered on or at boot time. Now to look at the code to control the SDR-1000 using Ozy.

Dayton 2008

2008-05-19T06:02:00.000-07:00

Have just spent 3 days at Dayton (my first time). If you have never been to this show then I would really recommend it. It was tiring - didn't help that I missed my connecting flight in Chicago because of a delay in London and had to wait 5 hours for the next flight to Cincinnati where I rented a car and drove to Dayton. I finally arrived at about 1 am!

It was really good to meet up with old friends from AMSAT and TAPR and especially to meet for the first time in person Frank Brickle , Phil Harman, Gerald Youngblood, Eric Wachsmann and the rest of the Flex Radio people.

I now have the Ozy/Janus boards (and a Penelope board), thanks to Frank Brickle, and I also saw the new Mercury receiver board actually running. Phil really did a great job on this board, especially getting it built and working in time for the show.

The biggest problem I see going forward is how to keep up with all the new hardware and get the java-sdr working with it! I need to retire to get more time to work on all this great hardware! If anyone else wants to dig in and help develop the software for these feel free to have a go.

Vacation time ...

2008-02-22T06:15:00.000-08:00

I am really close with the transmit. I am getting some interaction from the code that gets the ADC data for the forward and reflected power. Once this is resolved I will make a release that includes transmit.

I will be on vacation for a week now - skiing in Morzine, France.

More tansmit ...

2008-02-11T14:20:00.000-08:00

Making some enhancements to the TX side.

Added the code to monitor the ADC for forward and reverse power and calculate SWR. Output power is controlled with the output gain control for the TX DttSP process.

Need to add the setup for the PA gain values for the correct power calculations.

I should be able to commit the changes in the next day or two.

Transmit

2008-02-08T00:56:00.000-08:00

Finally managed to get 100 watts output using a test tone. Found a problem with the SDR-1000 hardware code where the PA_BIAS control bit was inverted in the Linux code. This should now be corrected in the svn repository for DttSP.

Hopefully, I can now make a working transmit version available soon for others to test. I expect the CW transmit code will require a lot of work to get running well.

New versions of sdr-core

2008-01-28T13:05:00.000-08:00

I have updated the version of sdr-core for both mac and linux to reflect the latest changes from Frank to improve the latency problem.

Also fixed a problem where the DIGU and DIGL filters were the same.

I have also deleted the build and dist directories from the repository. This seemed to be causing some problems with updates. You should manually delete these directories (and all sub directories and files) and then an update should work without any problems. A subsequent build will recreate these directories but they are now not in the repository so should not cause any problems on future updates. This is for both command line svn updates and Netbeans svn updates.

Project Wonderland (Sun MPK-20)

2008-01-23T08:40:00.000-08:00

I have been giving a demo of the Java GUI in Sun's virtual office (MPK-20). This is using the open source version of Project Wonderland.

Click on image for large image.

sdr-core rev 162

2008-01-23T02:11:00.000-08:00

I am working with Frank on adding gain controls for the input and output of DttSP. The control of the output gain of DttSP will resolve the problem of no audio output that I am seeing with the latest revision of DttSP.

This should also resolve the problem of controlling the transmit drive as I will now be able to adjust the gain on the I/Q output to the transmitter. More to come later ...

The latest rev 72 contains the updated source code for the gain controls and also the updated binaries for sdr-core (both linux and mac).

HAARP - LWA Moon Bounce Experiment

2008-01-19T23:02:00.000-08:00

I had a short 8 minute window at 06:30 this morning while the moon was above the horizon so I decided to try to hear the echo from the HAARP moon bounce experiment on 6.7925 MHz.

You can see the 2 second carrier on the waterfall just below the red cursor in the center of the display. Click on the image to get the full size image.

Rogue import

2008-01-17T14:54:00.000-08:00

Just noticed that a rogue import got into ConfigureDialog.java which I have now removed and updated on java.net.

Softrock support

2008-01-17T13:28:00.000-08:00

I have updated the code to include the start of softrock support. Currently it is receive only and a single center frequency.

As usual an 'svn update' will get the source code changes and then recompile in NetBeans.

New Quicktime video

2008-01-16T01:18:00.000-08:00

I made a new Quicktime video of the GUI running including audio.

The video was made using iShowU on the Mac. I had to drop the frame rate down fairly low as it does have problems running at 30 fps along with the GUI, sdr-core, Jack and NetBeans. There is some jitter in the video which is caused by the all this running together.

You can download the actual Quicktime video from java.net. Be aware that it is a large file 34MB.

Updated source code and OZY/JANUS info.

2008-01-15T04:45:00.000-08:00

Added an AGC panel and code to be able to control RX AGC - currently just supports OFF,LONG,SLOW,MEDIUM and FAST. I will add an additional mode for CUSTOM.

Frank has offered a loan of an OZY/JANUS board set, which I have accepted, so that I can look at adding support for it. With the work that Bob (VK4XV) has been doing we should be able to get something working fairly quickly.

This all goes goes to prove what a great group of people we have working on all this.

Fixed several problems including

2008-01-14T12:24:00.000-08:00

I have update the source on java.net to fix a few problems found by José F5JD, Roland f8chk, Dana Rawding and Frank Brickle for giving some good advise, especially when I am not around.

An 'svn update' will get the latest source and then compiling and running from NetBeans will get the latest version.

One change was set the IF to 9000 rather than 11025. This value is stored in the radio.xml file, so you will either have to remove it or edit and change the 11025 value to 9000.

java.net announcement

2008-01-06T03:22:00.000-08:00

Have put the announcement on dtts-linux and flexradio of the subversion repository and some documentation on http://java-sdr.dev.java.net.

Had a email from Frank to say he had already found the repository and had checked it out and was running. I knew someone would find it before I made the announcement ;-)

Nearly there ...

2008-01-04T06:36:00.000-08:00

I have built clean Fedora 8 and Ubuntu 7.10 systems and written documentation on how to install the required components and how to checkout the Subversion repository.

I need to build a clean Mac OS X system and write the documentation for that.

This first release is a receive only version. The transmit side still needs some work for which I am getting a lot of help from Frank and Eric. There is code in this version that will transmit, but be aware that it is possible to damage the PA in the SDR-1000 if it is overdriven. The power output is determined by the audio drive from the sound card.

svn repository

2008-01-02T13:34:00.000-08:00

The svn repository has now been setup on java.net and I will publish the details on the relevant lists in a couple of days as soon as I have completed checking it out on both the Mac and Linux.

The tree contains everything that is required to compile and run the application under NetBeans apart from jack (see later). It was developed with NetBeans 5.5.1 and JDK 1.5 because Apple had not released 1.6. 1.6 is now available as a Beta release from the Apple developer site. I have not had any time to check this out yet. I have tried NetBeans 6.0 and JDK 1.6 on Linux and all is OK. However if any GUI forms are developed with this version they are not backward compatible with the previous versions.

The tree also contains a bin directory with 2 sub-directories for linux and mac, which contain the required compiled versions of sdr-core and sdr1000. sdr100 is the hardware code from repos-sdr-linux with a C wrapper around it to use fifos for it's interface.

The Java code will detect which OS it is running on and exec the correct versions as sub-processes.

The only thing that the user needs to install on their machine other than NetBeans and the Java Development Kit is Jack. Most distributions include Jack. I run Fedora Core 8 and it was just a simple matter of running the Package Manager (Add/Remove Software) and searching for jack and then selecting both 'jack-audio-connection-kit' and 'jack-audio-selection-kit-example-clients'. On Mac OS X you can download and install the jack package from jackosx.com.

Note that the startup of jack and the connections are all exec'd from the Java code. There is no requirement for the user to run these manually or use qjackctl (in Linux) to make the connections.

There is a script in the tree to make the fifos. This mus be done before running the application.

java.net

2008-01-02T06:01:00.000-08:00

I have setup a java.net account for the source code repository. Should have this completed in the next couple of days and will then publish how to access it.

YouTube video of SDR-1000 Java GUI

2007-12-29T02:44:00.000-08:00

I have uploaded this video of of the SDR-1000 Java GUI running on the Mac.

The application is started from NetBeans and you can see the Java code starting up the background processes: sdr1000 (hardware interface code),jack, sdr-core (RX), sdr-core (TX) and then the jack-connect commands to connect it all up.

Running on a MacBook Pro

2007-12-27T14:24:00.000-08:00

One of the reasons for writing the GUI in Java was the portability it gives you.

Here are a couple of screenshots (click the image to get full size) of the GUI running on the Mac. It looks and runs just the same on Linux.

I am using an Edirol FA-66 Firewire for the sound card on the Mac. At the time it was running at 96000.

The first image includes the memory utilization from the Activity Monitor, which shows there is still 1.28GB available (the machine has 2GB) even with the Java GUI (radio.Radio) running, 2 copies of sdr-core (DttSP) one for RX and one for TX, jackd, sdr1000 (the sdr1000 hardware interface). On top of all this the Java GUI was run from Netbeans which is used as the IDE for development.

The second image includes the cpu utilization from the Activity Monitor, which shows we are running 70% idle.

Java GUI For DttSP

2007-12-27T14:19:00.000-08:00

Decided to try starting a blog about my development of a Java GUI for DttSP and the SDR-1000.