Amateur Radio – Page 19 – Kev's Development Toolbox

July 26, 2015

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.

June 19, 2015

Re-flashing a WRT54GL running HSMM Ham Mesh firmware

I recently flashed the firmware on a spare Linksys WRT54GL to take a look at ham radio mesh networking on 2.4GHz re-using WiFi routers like the WRT54. I wanted to flash the router back to regular WiFi router firmware, and turned out this was more difficult than it should have been. For future reference, here’s a few notes.

The HSMM-Mesh firmware (3.0) has an admin page to either upload a new firmware to flash, or download an existing firmware from a list of available firmware versions. Neither of these worked for me – uploading a firmware gave an error that it wasn’t recognized, and then the router was connected to my network for internet access, it didn’t give any firmware options other than later versions of the HSMM firmware.

Elsewhere there are instructions for using the tftp approach to ftp a new firmware to the router as it boots. This seemed like an easy option, but I could not get it to work despite trying multiple times.

Instructions for OpenWrt here give steps for ensuring the tftp feature is enabled… this apparently is key, as before following the steps I could not get it to work, but after setting this options it worked first time.

ssh to the router using:

ssh root@10.72.105.9 -p 2222

this is the ip that my HSMM had on starting up, and sshd on the HSMM firmware is enabled by default and listening on 2222.

From thr OpenWrt page above, enter these commands to setup tftp:

nvram set boot_wait=on
nvram set boot_time=10
nvram set wait_time=10 #important for some models
nvram commit && reboot

Before the reboot step, set your ip address on laptop connected to router as:

192.168.1.2
netmask 255.255.255.0
router/gateway 192.168.1.1

Reboot router, start following the tftp procedure to upload the firmware:

http://www.dd-wrt.com/wiki/index.php/Recover_from_a_Bad_Flash

If you are seeing WRQ messages with tftp trace turned on, the router is responding, but not yet accepting the tftp upload. You need to wait until you see messages like this to indicate the transfer is occurring:

sent DATA <block=6562, 512 bytes>
received ACK <block=6562>

These will repeat several times a second until the upload is complete, then they will stop, tftp will disconnect, and you’ll see the router power light flashing, indicating it is rebooting. Wait a couple of minutes until the lights are back to their normal state, and then try hitting the admin page for the new flashed firmware at 192.168.1.1

March 5, 2015

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.

December 7, 2014

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