Configuring rtl_fm and Direwolf for decoding Amateur Radio Packet on the Raspberry Pi

rtl_fm is one of the utilities from the rtl_sdr package for using a TV dongle as an SDR. Head over here if you need more info on this.

Direwolf is a soundcard based packet modem.

According to the Direwolf docs, it supports using rtl_fm as an input, so I thought I would take a look at look at getting these running together.

I’ve used rtl_sdr and rtl_tcp on my Pi before, but not rtl_fm, so first to get this working.

To playback the stream from rtl_fm you need to pipe into into some audio app. This is the same way that direwolf is going to read the stream too. Following the suggestion here on the rtl_sdr page, this command works fine for a local broadcast radio station on 96.9MHz:

rtl_fm -f 96.9M -M wbfm -s 200000 -r 48000 | play -r 48000 -t s16 -L -c 1  -

I’m not sure what all these options are, but the key options seem to be -s for the sample rate, and -r for the resolution. The -r value needs to match on the rtl_fm side and on the play side.

Now to get direwolf installed on Raspbian:

– per the userguide, first install libasound-dev:

[code]sudo apt-get install libasound-dev[/code]

– download the source zip from: https://home.comcast.net/~wb2osz/site/?/page/Download/

– unzip and cd into the direwolf folder

– make with:

[code]make -f Makefile.linux

make install-conf

make install_rpi[/code]

At this point I have rtl_fm on the Pi working as it should, and direwolf working great when decoding audio input from a 2m radio input via a USB soundcard. Combining the two though is giving me issues.

I don’t thing I’m able to get a strong enough received signal on 2m on the RTL stick even with an external 1/4wave 2m antenna.

This is the combination of commands, rtl_fm, piping into Direwolf:


[code]rtl_fm -f 145048467 -M fm -s 200000 -r 32000 -g 35 | direwolf -n 1 -r 32000 -b 16 -t 0 -[/code]

I’ve allowed for the tuning offset ppm on this RTL card, but maybe I’ve calculated this wrong?

Anyway, since Direwolf by itself on the Pi is working well and what I needed for a small packet project was to be able to decode packet on the Pi, I’ll be putting rtl_fm on hold for the time being and playing with Direwolf by itself.

Amateur Radio Packet – Using Outpost with a software modem

My current packet setup is using the UZ7HO modem software – it seems to work pretty well, and as a software based packet modem it seems to work better than AGWPE since that seems to be a bit temperamental.

I’ve been experimenting using Outpost as a message client via UZ7HO. In the settings (Setup/TNC) on the AGW tab, you can enter an IP address of where your AGW software is running. This is an easy option to connect Outpost with UZ7HO since it can run in network mode. I also typically run a laptop running UZ7HO in my office where my radio is, and then I can connect to it from elsewhere in the house on another laptop.

The first issue I’ve noticed is that if I already have a terminal connected to UZ7HO remotely using my regular call, I can’t connect with Outpost using the same call. I guess this makes sense, and this is where the use of the ‘-number’ suffixes comes in that you commonly see on packet. This is what the error in Outpost looks like if you try and use the same call with no unique suffix:

3/4/2015 10:21:18 PM -- (N2) AGWPE Registration failed. Check for: 1. missing or invalid remote logon/password 2. station ID already in use by another AGWPE application

Ok, so to fix this you could put a number suffix on your call, but then when you connect to a local packet BBS to pick up messages, this doesn’t work as it appears to look for message sent to that matching call+suffix, so I’m guessing the callsign you configure in Outpost really does have to be your real callsign. This means you have to close any other connected terminal apps that you are running at the same time, or, configure the terminal to use a suffix on your call (maybe that makes more sense).

The next issue I’ve run into is that when I connect to a BBS using a terminal app directly, I have the ‘OP’ setting (‘output pause’, I think) set to some sensible number, like 10 lines, so I get the continue/cancel prompt when reading messages, or listing the messages on the BBS. It seems Outpost doesn’t know how to handle this, and will pause forever on message download, eventually timing out and disconnecting. There might be another way to configure this, but the only way I’ve found so far is to connect to the BBS directly, set ‘op 0’ and disconnect. Now when Outpost next connects, it downloads all your messages without interruptions.

 

Success! Packet Radio via the International Space Station

I think this was my third or fourth attempt, but I just successfully bounced a packet off of the ISS as it passed over this evening – if I understand this right, the red highlighted message is my message as I received it coming back from RS0SS (the callsign for the packet digipeater on the ISS):

2014 12 07 iss packet - 1st contact

Amateur Radio Packet via the International Space Station (update 2)

On yesterday’s pass I realized too late that the AGWTerminal software doesn’t send unproto packets needed to send packets via the ISS. I’ve now downloaded UISS, got it sent up and checked into the Sacramento Valley Sunday evening packet net, so looks like everything is good to go.

On this evening’s pass, I started sending my cq unproto packets, but looks like I wasn’t heard. I’m wondering after reading around that my ‘via’ value should be ARISS and not RS0ISS that I was using. Apparently your via should be ARISS, but the packets recevied from the digipeater on the ISS will come from RS0ISS. So, will give it another try on the next pass at a good time.

Here’s the packets I received this evening:

Fm K7LWV-6 To APRS Via RS0ISS* <UI pid=F0 Len=47 >[21:08:50]
=4454.96N/12319.98W`Dallas, OR Via ISS {UISS53}
Fm K7LWV-6 To APRS Via RS0ISS* <UI pid=F0 Len=33 >[21:08:59]
:NWS      :Hello from Dallas, OR!
Fm N7HQB To CQ Via RS0ISS* <UI pid=F0 Len=45 >[21:09:04]
=40.637569n/111.931580w/Hello From SLC Utah!