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

gpredict trsp file for FUNCUBE

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

[FUNCUBE BPSK Telem]
DOWN_LOW=145935000

[FUNCUBE U/V]
UP_LOW=435150000
UP_HIGH=435130000
DOWN_LOW=145950000
DOWN_HIGH=145970000
INVERT=true


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.

Update:
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]
DOWN_LOW=437405000

Here are (or were) the keps.

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.

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

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