QtRadio running on Ubuntu 13.04 with USRP

After a day slaving over a hot compiler, I managed to get QtRadio working with my USRP B100 and BasicRx.  I achieved this using code from the ghpsdr3-alex repo.

It looks good on a 27 inch  WQHD monitor with a 2560 by 1440 pixels screen.  I have it resampling from the default 250kHz rate down to 192kHz.  It does seem fairly CPU intensive though, hitting a load of 5.0 to 6.0 on my new Haswell I7 machine, with a modest bunch of other applications running that don't reach a load of 1.0 between them.  I built using the alex-conf.sh script instead of using configure itself, so I've hopefully got an optimised build.  I built QtRadio for release in QtCreator.

Here's a screenshot of some 30m activity.

To get this working I had to bodge the usrp_server to detect my B100, which it didn't do initially. It turns out that it was hard-coded to expect a USRP1 device.  The following patch shows the simple change required to make it work with the B100.

diff --git a/trunk/src/usrp/usrp.c b/trunk/src/usrp/usrp.c
index a36e93c..c8e0f91 100644
--- a/trunk/src/usrp/usrp.c
+++ b/trunk/src/usrp/usrp.c
@@ -141,7 +141,7 @@ void setup_rx_queue(void) {
 bool usrp_init (const char *rx_subdev_par, const char *tx_subdev_par)
 {
     uhd::device_addr_t hint;
-    hint["type"] = "usrp1";
+    hint["type"] = "b100"; // "usrp1";

     //discover the usrps and print the results
     uhd::device_addrs_t device_addrs = uhd::device::find(hint);

Once I'd built everything, I had to run two server processes before launching QtRadio.  I invoked them like so:

$ usrp_server  -r "A:A" --samplerate 192000

and

$ dspserver --lo 0

Testing the AX.25 CL for DTN2

I received an email suggesting that I might like to test the AX.25 Connected Mode Convergence Layer for the DTN2 reference implementation, as some tweaks had been made to it upstream.

I updated the DTN2 source code on the two Linux machines that I use for testing the AXCM-CL with and rebuilt it.  The shack PC (upstairs) is hooked up to an FT-817 transceiver using an SCS Tracker/DSP-TNC.  The FT-817 uses it's rubber duck antenna and operates at the lowest power setting. Meanwhile, downstairs, my Lenovo laptop is hooked up to a Kenwood D72 (a hand-held radio with a built in TNC), also operating at its lowest transmitter power setting and using a short stubby dual-band antenna.

For monitoring the traffic, I decided to use my USRP & WBX daughter-board combo, using the Software Defined Radio program gqrx to demodulate the narrow-band FM signals and decode the 1200 baud AX.25.  This also runs on my Lenovo laptop downstairs, leaving me free to avoid entering the messy shack.

Here's a screen-shot of some AX.25 shifting a 35kB adif format log file on 70cm using the dtncp utility.

I pushed the adif file from the laptop to the machine upstairs and then onto the node at delaytolerant.net by means of a TCP convergence layer connection, where it was received by the dtncpd utility.  I confirmed that the md5sum of the file payload matched that determined at the sender manually.

Here's the result of probing the test network using dtntraceroute to a wildcard address:

darren@len:~/dtnrf$ dtntraceroute -e 3000 -w 6000 dtn://*/ping
source_eid [dtn://g0hww-6.dtn/traceroute.14414]
using default replyto
dtn_register succeeded, regid 25
dtn://g0hww-6.dtn/traceroute.14414: sent at Fri Feb 15 16:44:07 2013 UTC
dtn://g0hww-6.dtn/ping: echo reply at Fri Feb 15 16:44:07 2013 UTC (342 ms rtt)
dtn://g0hww-6.dtn: delivered at Fri Feb 15 16:44:07 2013 UTC (386 ms rtt)
dtn://g0hww-6.dtn: forwarded at Fri Feb 15 16:45:42 2013 UTC (95138 ms rtt)
dtn://g0hww-7.dtn: received at Fri Feb 15 16:45:33 2013 UTC (97749 ms rtt)
dtn://g0hww-7.dtn/ping: echo reply at Fri Feb 15 16:45:33 2013 UTC (99882 ms rtt)
dtn://g0hww-7.dtn: delivered at Fri Feb 15 16:45:33 2013 UTC (106687 ms rtt)
dtn://g0hww-7.dtn: forwarded at Fri Feb 15 16:45:33 2013 UTC (113715 ms rtt)
dtn://hambone.delaytolerant.net: received at Fri Feb 15 16:45:34 2013 UTC (116127 ms rtt)
dtn://hambone.delaytolerant.net/ping: echo reply at Fri Feb 15 16:45:34 2013 UTC (118282 ms rtt)
dtn://hambone.delaytolerant.net: delivered at Fri Feb 15 16:45:34 2013 UTC (125148 ms rtt)
dtn://g0hww-7.dtn: received at Fri Feb 15 16:45:39 2013 UTC (135215 ms rtt)
dtn://hambone.delaytolerant.net: forwarded at Fri Feb 15 16:45:39 2013 UTC (142659 ms rtt)

This overlapped with the file transfer using dtncp, resulting in some head of line blocking and an RTT of about 2 minutes.

No testing of the DTN would be complete without firing up what might be called a killer app for this specific domain, my awful dtnchat application, available here.

It looks like the screenshot below (which is the nicest view, the Preferences tab is even worse).  It does work though. It uses wxPython and the DTN2 Python bindings.

  
This is me talking to myself through the DTN over AX.25. The hideous notification at the bottom is probably due to it coming via a remote X session over SSH, along with the application instance on the right.

UHF Satcom - something on 252.299MHz

I'm wondering what this is:

L-band SARSAT doppler tracks in gqrx

High Altitude Balloon tracking

This might be a kind of live-blog. Perhaps. We'll see what happens.

Project info: http://ukhas.org.uk/

Tracking online: http://track.spacenear.us/

I'm using a discone in the loft and a preamp at the wrong end of the coax.  With this arrangement, I can here (but not well) some priates on UHF-SATCOM,  quite a few 70cm sat transponders and faint signals from L-Band SARSATS, so it works okish.

A screenshot of gqrx, using a USRP B100 & wbx daughterboard.

 One of dl-fldigi, using an AOR8600mk2 and a Signalink-USB.

Apparently that's PROM i can see.

Bob too now:

Now, I'm decoding Bob, but with bad checksums:

There's a bunch of loons going up, so I thought I'd monitor a whole MHz of spectrum in gqrx and look for them all at the same time, then tune in the strongest for decoding.  This is the playing field, below.  Bob is where the receiver is tuned to, and PROM is up at 434.167, faintly visible.

I popped up to listen to FO-29 and when i came back, there was another signal:

Apparently, it was TRUSS:

A little while later, I spotted ROLL in the waterfall:

 

But the decodes weren't so good as it was in a noisier part of the band:

I continued to monitor, alternating between TRUSS and ROLL depending on which seemed stronger at the time.  I didn't get many good decodes.

Advanced tuning for UHD in gqrx

Before (well, I cheated and took this picture after the other):

And after:

The patch supporting UHD advanced tuning is in git for gr-osmosdr now.

GQRX running nicely on HF with a USRP B100 and BasicRx

Tonight I've been using GQRX with my USRP B100, this time with the BasicRx daughterboard fitted, and a direct connection to my HF wire antenna.

It seems pretty good so far.  I've just been listening to some UK stations on 40m.