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

Multiple Mercury Receivers

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

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

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

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

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

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

Now have the band buttons working correctly.

Sub RX

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

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

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

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 ...

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 ...

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

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

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

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

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

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

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

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

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

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

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

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+

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

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

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

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.