31 December 2013


I've just cobbled together a rudimentary scheduler for triggering recording/post-processing of FUNcube-1 (AO-73) telemetry with the fcdec utilities.

It uses a predict server to provide pass predictions, is written in python, has a GPLV3 licence and is available on github here.  It is only a few hours old, and hasn't seen many passes, but it may well work :)

I found details of the predict server's command set here.

Using fcdec on Ubuntu 13.10

After some time away from home over Xmas, I decided to have a go at using Alex's fcdec telemetry decoder for the Funcube satellite.

The source is available on github here.  It is also necessary to get the source for fcdctl from here. I ran the makefiles in the decoder, fcdctl and filter directories. I then edited tools/submit.sh to reflect my credentials stored with the online data warehouse. I then edited the WORK_DIR and PROG_DIR macros in tools/fcd_sequencer.sh to reflect the paths in my home directory.

I then created links in my ~/bin dir to the binaries I'd just built for decode, fcdctl and filter, and also for the tools/submit.sh and tools/fcd_sequencer.sh scripts.

I discovered that I also needed to install the libsox-fmt-pulse package in order for pulse to work properly with sox and also needed to ensure that the fcd-pro was set to the "Analogue Stereo Input" profile in the configuration tab of pavucontrol.

This let me run fcd_sequencer which then waited for a command on tcp port 12345 to start collecting data.  This could be done using telnet.  I used telnet to connect to localhost on port 12345 and then submitted the command "start +600" followed by hitting the enter key and then pressing Ctrl+] then entered "quit" to exit telnet and close the tcp connection.  At that point, the fcd_sequencer script started to collect data.

There was a pass at 1108z this morning (31st Dec 2013) and it seemed that I was able to decode 40 telemetry packets.  This was with my original fcd-pro (not the pro-plus, for some reason I've not been able to get fcdctl to work with the pro-plus yet) and using my 2m turnstile-with-reflectors in the loft for the antenna.

20131231_110203: --------------------------------------------------------------
20131231_110204: Waiting for new command on port 12345
20131231_110713: Received start command: start
20131231_110713: Will capture IQ for 780 seconds
Freq set to 145.924000 MHz.
LNA gain set to 10 dB.
  nr   USB path       firmware   frequency         LNA gain   audio device
  0    0003:0014:02   18.10       145.924000 MHz     10 dB     card6
20131231_110713: Using audio input: alsa_input.usb-Hanlincrest_Ltd._FUNcube_Dongle_V1.0-00-V10.analog-stereo
20131231_110713: Start capture to /home/darren/funcube-data/out/20131231_110713/fcd_iq_sc_20131231_110713_96_145924.raw
20131231_112013: Filter and decode (G=100) /home/darren/funcube-data/out/20131231_110713/fcd_iq_sc_20131231_110713_96_145924.raw:40
20131231_112022: Filter and decode (G=200) /home/darren/funcube-data/out/20131231_110713/fcd_iq_sc_20131231_110713_96_145924.raw:40
20131231_112030: G=100 gave 40 packets; G=200 gave 40 packets
20131231_112030:  Submitting packets from /home/darren/funcube-data/out/20131231_110713/data-200.txt
20131231_112030: --------------------------------------------------------------

Having a look at the raw file with a modified tools/fcd_replay.grc file, I observed the following with the fosphor display.

In order to get this all working, I found it useful to temporarily instrument the fcd_sequencer.sh script by adding the -x option on the first line, as below:

#!/bin/bash -x
This let me determine exactly what was happening as the script ran.  I did actually make a mistake when creating the symbolic link to submit.sh (missing the .sh extension on the link name).  This caused the invocation of submit.sh by fcd_sequencer.sh to fail, but the use of the -x option in fcd_sequencer.sh allowed me to see the correct invocation of submit.sh and to manually invoke it once the symbolic link had been fixed, culminating in the appearance of a line in the upload rankings table here crediting G0HWW with 40 packets.

Update 1st Jan 2014: I've written fcsched to schedule fcdec according to passes reported by a predict server.

21 November 2013

gpredict trsp file for FUNCUBE

Add a file to the ~/.config/Gpredict/trsp directory, with the following contents:



Depending on where or when you got your keps, you may have a different Catalogue Number for FUNCUBE-1.  Create a file called CAT_NUM.trsp. where CAT_NUM is the catalogue number for FUNCUBE-1.  I have two trsp files, one called 39417.trsp and the other 312.trsp, as I have two sets of keps for FUNCUBE-1 right now. UPDATE 1st Jan 2014: The latest recommended keps (referenced here) are for catalogue number 39444. In gpredict, this is known as 2013-066AE.
With the keps for FUNCUBE added to gpredict and with the really cool recently added support for hamlib compatible remote control of gqrx it's easy enough to find FUNCUBE with a Funcube Dongle Pro+ as a receiver.  I'm using a homebrew 2m Turnstile-With-Reflectors in the loft as an antenna.

I'm going to have a listen for ChargerSat-1 (more) too.  The trsp file for that is called 99912.trsp and has the following contents.

[ChargeSat-1 Telem]

Here are (or were) the keps.

17 November 2013

Circled by a HAB whilst sleeping.

It seems that the balloon, B-30, came to play last night whilst I was asleep.  I started tracking B-30 earlier in the evening and the signal was getting stronger as it moved eastwards towards me when I fell asleep.  It was quite surprising that I could still hear B-30's signal when I woke up this morning, but nowhere near as much of a surprise as when I realised that B-30 had flown right around me then changed to a northerly course.

3 November 2013

Using null-sinks with pulseaudio

I've been running multiple instances of gqrx recently. Up until now, I have used an unconnected soundcard output as a sink for a gqrx receiver audio that I've no interest in listening to myself, then selecting that same output's monitor channel in Pulse Audio Volume Controller as an input for fldigi or multimon-ng, for example.

Then I ran out of unused soundcard outputs to use, but fortunately discovered pulseaudio's null-sink facility.  Now I can create a null sink specifically for each SDR receiver that I have and hook them all up to different modem programmes.

To create a null sink with a meaningful name, use a command like this:

$ pactl load-module module-null-sink sink_name=fcdv1op \ sink_properties=device.description="fcdv1op"

To monitor the audio stream that is being routed to the null sink, create a loop-back:

$ pactl load-module module-loopback latency_msec=1
I let gqrx send audio to the default output in its configuration, then use Pulse Audio Volume Controller (pavucontrol) to reassign it to the null sink.  I can then set, for example multimon-ng, to listen to the monitor of the null-sink (on the Recording tab of pavucontrol) and set up a loopback monitor to my default output (on the Playback tab of pavucontrol).

This lets me control the audio levels fed to each audio 'decoder' and the level coming out of my speakers independently. You can add a named null sink for each SDR device you have and a separate loopback device for each of them also, which you can mute and mix accordingly and route to different audio outputs if you so desire.

Edit: If you are paying attention, you may notice that the null sink name in the screen-shots is different to the one used in the command line. Oh, well, let's call that a continuity error and move on :)

13 October 2013

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
$ dspserver --lo 0

26 August 2013

OnSense - it's not nonsense!

I've just pushed the first version of OnSense up to github. OnSense is a hacktastic hybrid spectrum sensing scanner, using a combination of SDR and analogue receivers.  I've been using a HackRF Jawbreaker and an AOR-8600mk2 receiver.

OnSense uses osmocom_spectrum_sense as a spectrum sensing front end, and tunes the conventional receiver using hamlib's rigctl.

OnSense can scan the entire UHF military airband in less than a second (or the VHF air band).  There are 7000 channels with 25kHz spacing between 225MHz and 400Mhz.  When I assessed the scanning speed it was roughly 666ms, that's over 10k channels per second which isn't too shabby.  OnSense is not a great piece of software yet, but its not nonsense.

I'm hoping to improve OnSense with a QT GUI and an SQLite database.

Here's a screenshot of some onsense action:

The green stuff in the terminal itself is OnSense. It spews forth notifications so you can tell at a glance what you're listening to.  I like to keep an eye on things (bugs?) by keeping grig in view and having both OnSense and grig talking to the AOR receiver via rigctld.

21 July 2013


Getting a good strong signal from MONTY this morning.

And CHEAPO too.

6 July 2013

PICO HAB on HackRF with GQRX and dl-fldigi

I awoke this morning to find myself surrounded by low flying High Altitude Balloons. NANU and PICO were up.

I plugged in my HackRF and fired up two instances of dl-fldigi. The first used an analogue path from the AOR-8600mk2 reciever and the second took an audio feed from gqrx.  I found both signals in gqrx's waterfall  and managed to decode both signals at the same time.  NANU hit dirt before I got the digital path working, so I then tracked PICO with both receiver chains. I had to set the sampling rate for the HackRF to 10MS/s.  Initially I tried 8MS/s but dl-fldigi wouldn't decode anything - I noted that the RTTY scope hung quite often until I increased the sample rate.

The HackRF seems to be better than the USRP B100 for narrow bandwidth modes as it doesn't suffer from the discrete stepping TCXO that the USRP B100 manifests.

30 June 2013


Today I've been receiving the HABANERO balloon from Holland, with my AOR-8600mk2 and a discone antenna in the loft.

29 June 2013

Kingsley HAB

I've been seeing if I can decode the Kingsley HAB with the HackRF SDR and gqrx feeding fldigi-HAB.

The HackRF is connected to a AR-8600mk2 discone via a UHF bandpass filter and a preamp (at the wrong end of the coax).  Both the HackRF and AOR-8600mk2 share this feed by means of a 2-way combiner.

I'm not getting any good decodes yet with the HackRF, but the AOR is doing OK.

28 June 2013

HackRF hatchet job

The HackRF Jawbreaker kindly sent to me by Michael Ossman arrived on my desk at work on Monday morning. I have been very lucky as there were only 500 beta boards made and I applied for one after he tweeted that there were some left over after the coupon codes he'd handed out at Toorcon had been redeemed.

Shortly before leaving work I remembered that I needed to disconnect the on-board 900MHz band PCB antenna enabling the use of an external antenna connected to the board mounted SMA socket.  The procedure for doing this (described here) involves cutting a PCB track, wisely marked on the board with an arrow.

It has been a long time since I attempted delicate surgery on a PCB, so long in fact that every has shrunk considerably and I could barely see the trace.  I hoped to find some in the lab who had the skill to do the job for me, but I had no such luck.  Most of the guys whom I would have asked have been laid off and those that remain had been dispatched to assist on other sites.

In the lab I found two microscopes that looked useful and a scalpel. After rummaging around looking for some anti-static straps I had a good look at the board with the microscope that seemed to provide the best illumination and view.  Unfortunately, the scope didn't seem to provide enough clearance to work on the board, so I had to move to a different workstation in order to actually wield some tools.  This other scope was much trickier to set up and I couldn't get a proper binocular view so I settled for just using my good eye.  This gave me a somewhat oblique view of the target area but at least gave me access to work on the board.

I decided that I'd try and wick off the solder before going in for the kill with the scalpel.  I was somewhat perturbed by the unsteadiness of the soldering iron tip and  gave up almost immediately with that idea.  Most of the solder remained on the trace but seemed to have balled up a bit at the ends, leaving me fairly confident that the track shouldn't take much cutting.

I spent a couple of minutes lightly scraping at the track with the scalpel before I caught a glimpse of some shiney copper in a place where I had not previously seen a reflection.  I panicked at that point, as I wondered how many layers the PCB had, and if I'd dug all the way through to an internal trace and damaged that.

I moved the board back to the other work station, but found it impossible to judge whether I had:

1) Failed to cut the track
2) Cut the trace and caused collateral damage to a mid-layer track
3) Cut the track with surgical precision.

I took the board home figuring that I'd get it running and hope it worked.  It did. I was able to receive broadcast FM stereo at around 104MHz (although those signals are so strong It's hard not receive them).  To try out the sensitivity a little better I tuned into a military satcom transponder downlink on 255.55MHz and was able to faintly hear a spanish speaking south american pirate station on FM.  This is one of the signals I routinely use to check that my SDR receivers are functioning well.  With a good setup, I expect to be able to distinguish the increased noise floor of the transponder downlink when no signals are being relayed.  The active stations meant that the transponder's receive gain was reduced and that the downlink noise floor was indistinguishable from the background noise, which seemed to be quite high.  I had the hackrf sampling at 1MHz and this is a higher sampling rate than I would normally use for receiving weak signals.

It seemed that the board was working well enough for reception, but that didn't convince me that the hatchet job had worked out OK, so I decided that I wouldn't attempt to transmit at all until I'd confirmed that the track was properly cut.  I figured I'd take the board back to work when I could get a second opinion from someone who was familiar with the inspection gear in the lab and more importantly, could perhaps sort out any mess I may have made.

I did that today and they confirmed that I'd pulled of the job with Ninja precision.  The force must have been strong with me on Monday as it seemed to me to be like trying to circumcise a flea with a bulldozer.

The following photo was taken through the inspection scope and shows my handy-work.

Finally, here's an image of the Jawbreaker installed in its temporary home.  This isn't the first radio of mine that has been housed in a cardboard box.

17 June 2013


Having (re)installed (due to idiocy) Ubuntu on my shack machine, I fired up the build-gnuradio script and built gr-airmodes. Some time later, I noticed the following WTF. 

(-48 0.0000000000) Type 20 TCAS report from 9d529e: threat ID: 13e71ba advised:  DON'T DESCEND DON'T DESCEND >500FPM DON'T DESCEND >1000FPM DESCEND DON'T CLIMB DON'T CLIMB >2000FPM TURN RIGHT DON'T TURN LEFT DON'T TURN RIGHT complement:  DON'T CLIMB DON'T TURN LEFT at 33725ft

I hope that this is some quirk in the message decoding.  I wouldn't fancy trying to understand that if my life depended on it!

16 June 2013


 More HABs launched today from Cambridge, UK. Receiving on 70cm ISM band.

8 June 2013


It might sound like Mork calling Orson, but its another HAB.  This one launched from Cambridge, just to the west of me, so it is coming in nice and strong.

A while later I spotted NANU's signal. ANU is on the left, NANU is on the right.
NANU's not got much to say for itself:

2 June 2013


I've been receiving RTTY from the balloon BALCAN-ONE-A, with my AOR-8600Mk2 this afternoon.

27 May 2013

Trackpad RFI

Having spent the long weekend at my Mum's place, I threw up a random wire and counterpoise so I could have a listen with my KX3. 

Even at such modest QRP levels, there were a couple of incidents of transmitted RFI.  Transmitting on most of the HF bands apparently turned her bedside lamp on and off, and would bring her PVR in the living room (where I had deployed the rig) out of standby.

It wasn't all a one way thing though.  As soon as I connected up the rig, I remembered that I'd been obliged to procure a pair of  Powerline Networking adapters for her, so she could watch VOD on her TV.  I also remember the caveat I made at the time of purchase, which was that those things would probably always be disconnected if I came to visit with radios, so they got unplugged without any disagreement from Mum.  However, the broadband hash from her Panasonic TV was unexpected and very harsh on 20m and below.  This limited my listening to the late evening after Mum went to bed, which was also not a problem.

However, the most profound RFI issue seemed to be self-inflicted.  My Lenovo Z570 laptop's trackpad went batshit crazy when I tried to beacon on 30m with PSKmail and didn't recover when transmission ceased.  I was able to exert control over the UI with the USB mouse and eventually found the solution, namely reloading the drivers.  The commands to do this are below.  The main reason for writing this post is so that I can remember them ;)

sudo rmmod psmouse

sudo modprobe psmouse

23 May 2013

Intriguing quirk in gqrx

I was experimenting with using my USRP B100 and a BasicRx daughterboard tapping the IF output of my AOR 8600Mk2 reciever in order to monitor the transmission quality of my Elecraft KX3 the other day.

I became concerned that my KX3 was misbehaving when I saw some fairly horrible signals in the waterfall, for example, the CW transmission below.

Horrible isn't it!

I noticed similar nastiness for SSB transmissions too.  Then, by a stroke of luck I retuned gqrx's demodulator away from the signal and much to my surprise, the nastiness went away.

I then resorted to using a gnuradio-companion flowgraph instead and the KX3's transmissions looked clean

I'm not sure what is going on in gqrx that such a quirk can exist and I haven't had a look at the code yet.  I wonder if there might be a recursive filter operating on the same data that is being used in the waterfall and PSD plot, or similar.

Update 1
I've added another screenshot below. When this was taken, I'd been scrolling the modem back and forth across the CW signal.  This time I used a modem with a wider bandwidth.

Update 2:
It seems to be related to the squelch somehow. In the following screenshot, I alternated the squelch between fully open (previous setting) and fully closed.  The spurii seemed to go away  when the squelch was closed.

Update 3:
Turning AGC off gets rid of it.

19 May 2013

Approaching digital mode nirvana

Today I found myself running two instances of fldigi alongside WSPR and WSJT, all happily using the same SignalinkUSB soundcard interface to my KX3 and sharing access to the rig via Hamlib's rigctld.  Well, all but WSJT which doesn't have hamlib support in this build.

First signals received on 6m

I've just received my first signals on 6m with my KX3 and an indoor NORCAL doublet. I heard ES5RY calling CQ in CW on 50.0856Mhz.

15 February 2013

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.

2 February 2013

First night of the shadow-beacon experiment.

I've submitted the first nights logs for the shadow beacon experiment. I was initially confused about the desired format but on careful reading of the FAQ, it became apparent that 'arbitrary' formats are acceptable, so went for a filtered dataset from the aprx-rf.log file that showed only receptions from my satgate, G0HWW-4 containing the string RS0ISS. The full logs, with time stamps are here.

At first I didn't notice anything unusual, and then I realised that there were two digipeaters active.  The first clue was in a beacon from Nigel, G4DCQ:
G4DCQ-2>CQ,RS0ISS-4*::G4HBI    : Both Radio's running - RS0ISS & dash 4
 I wasn't really sure what Nigel meant, but then I noticed subsequent messages were being relayed by different digipeaters and some were coming via 3 hops:
IK3ZGB-2>CQ,RS0ISS*:=4542.75N/01142.00E`73' Via ISS de Cris {UISS53}
IK3ZGB-2>CQ,RS0ISS-4*:=4542.75N/01142.00E`73' Via ISS de Cris {UISS53}
G4DCQ-8>CQ,RS0ISS-4*,RS0ISS::G4HBI    : Double Digi
G4DCQ-8>CQ,RS0ISS-4*,RS0ISS*::G4HBI    : Double Digi
If you look at the telemetry report for G0HWW-4 you can see an increase in activity the day before the experiment started, and another increase for the first day.  If you are viewing this page some time in the future, look for telemetry for the week starting 2013-01-28.

Update: Some time ago I received a QSL card.

27 January 2013

PSKmail with the KX3

I've been dabbling with PSKmail over the past few weeks, using my KX3 and a variety of antennas, operating on 10.148MHz as G0HWW-5.

The new jPSKmail client 2.0.x has an embedded modem, but I like to run fldigi in waterfall only mode too, as I get better awareness of what is going on around the PSKmail frequency and how the rigs filters are set up.  I'm also using Xastir to plot stations heard.

So far I've managed to add mail records to 4 servers, DL4OAH-8, SM0RWO, OE5RTL and DL9YCS-3.

This map shows the PSKmail servers that I've connected to and configured my mail settings with.

I've been using an indoor Alex Loop Walkham mag loop and more recently an indoor NORCAL doublet, with the KX3 running at a massive 8W.

This map shows all/most/some of the PSKmail server's and clients that have gated my beacons to the APRS-IS, and of course PA0R, Rein's last reported position.

26 January 2013

Strange filter artifact in KX3

I've just discovered a strange filter artifact in my KX3's filtering.  Whilst fiddling with freedv, and adjusting the PBT high cut frequency with the rig in LSB mode (not DATA-A), as I adjust the PBT-II function downwards, a notch appears at 1500Hz, as soon as FL2 activates.  I have the optional roofing filters fitted, as shipped from Waters and Stanton, and have performed no calibrations myself, yet.

Just to prove that its no artifact of freedv, the same effect can be seen in fldigi.

Has anyone noticed this?

Update: Yes they have. It is explained here.

25 January 2013

FreeDV with pulse audio

I downloaded  the source for freedv yesterday and built it without issues on Ubuntu 12.10 x86_64.  It took a little while to get the sound cards configured to my liking; I wanted both radio I/O and headset I/O to use the pulse audio device, so that I could continue to run fldigi from the with radio whilst running freedv.

There were two minor issues I had to overcome to get this configuration as I wanted.  The first was that I couldn't configure both ins and both outs to use the pulse device, as freedv insisted that the same device couldn't be used for both the radio and headset connections.  I worked around this by choosing the default device for the headset in and out, and the pulse device for the radio in and out.

Two issues remain. The first is that I have to reassign all ins and outs in pavucontrol when i restart freedv, as pulse isn't able to distinguish between the radio and headset streams.

The final issue is that I have yet to find someone to talk to on air.  I'll be using my KX3 at, I guess, 5W power.

There's a QSO Finder for FreeDV here.

2 January 2013

Cheap and nasty USB Soundcards for SDR work

This post is a work in progress.

This pic is the spectrum of the Griffin iMic with no input source connected.

This pic has a stereo pair from the  KX3's I/Q output connected to the Griffin iMic, but with no antenna connected to the radio. The iMic is in line input mode.
In this pic the iMic is in Mic input mode.
Note that in the latter two scenarios with the receiver connected to the soundcard, I'm using a cheap stereo line isolator to ensure there are no ground loops, as I also have a serial connection between the laptop and the radio which gave major problems without the isolation in the I/Q path.


So, I've received the Behringer UCA202 I ordered the other day.  This gave very poor image rejection when immediately hooked up to my KX3's I/Q output.  After some dabbling in gnuradio-cmpanion (grc), I used the UCA202 line output to feed a complex signal into its line input with a 5kHz tone.  I'm only getting about 35dB image rejection when asking the UCA202 to eat its own dog food.
The image rejection gets worse, as expected, when the I and Q signals are independently disconnected or swapped.  This confirms that the signals are wired correctly. In the screen shot above, the peak hold value shows the image peak with only one of the I/Q pair connected.

Some comparitive tests between the Griffin iMic (white model) and the Behringer UCA202, whereby both are forced to consume their own dog food.

The  first test uses a loopback cable to feed the line in from the line out.  No signal is sent to the line out of the soundcard.

Here is the Griffin iMic
and here is the UCA202
Now for test 2. In this test, a 5kHz sinewave at (-20dB full scale) is fed as a complex I/Q signal into the soundcard's line output, via the loopback cable and into its line input.

Here's the Griffin iMic (white)
 and here is the UCA202.