21 November 2013

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.

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