Setting up Direwolf/Xastir on a Raspberry Pi

March 22, 2015

A long time ago I set up Soundmodem for Ubuntu. Recently, I tried setting up an igate using WB2OSZ’s Direwolf instead. Things are much nicer these days.

The Direwolf site includes a very nice guide to setting up a Raspberry Pi as an igate, so I won’t go over it here. Instead, this is just to record the steps I took to set up my Raspberry Pi v2 as an igate server.

1. Set up the Raspberry Pi to run Raspbian
2. Follow along with the setup guide:

sudo apt-get remove --purge pulseaudio # I didn't need to do this since it wasn't installed, but better safe than sorry
sudo apt-get install libasound2-dev xastir # Note that I'm installing xastir at the same time - this is different from the direwolf guide
wget http://home.comcast.net/~wb2osz/Version%201.1/direwolf-1.1-src.zip
unzip direwolf-1.1-src.zip
cd direwolf-1.1
make -f Makefile.linux tocalls-symbols
make -f Makefile.linux
sudo make -f Makefile.linux install
make -f Makefile.linux install-rpi
make -f Makefile.linux install-conf

Next, make sure the sound card is plugged into USB (I used the bottom slot). When I plugged it in, the system rebooted, so it’s probably smart to shut down before plugging the sound card in. For a sound card, I used the Syba SD-CM-UAUD USB Stereo Audio Adapter, C-Media Chipset from Amazon.

From there, run
aplay -l
to see:
card 1: Device [C-Media USB Audio Device], device 0: USB Audio [USB Audio]

Now I know the device is card 1 device 0. We’re almost ready to edit direwolf.conf. First, though – something that wasn’t documented on the Direwolf site. Igates need a secret code so they can log into the tier 2 servers. It’s based on your callsign, and there’s a utility called callpass in Xastir that will compute it for you.

callpass {my-real-call}

This gives you a 5 or 6 digit integer that you should remember. I’ll call it {my-code}.

Now edit direwolf.conf:

  1. uncomment ADEVICE plughw:1,0 – if you got a different number from aplay above, you might have to modify it.
  2. change MYCALL NOCALL to MYCALL {my-real-call}-10. I used -10 because that’s the APRS SSID for igates. (APRS SSIDs are documented here.) In the direwolf.conf that I got, the NOCALL had a ^J after it; I had to take that out
  3. uncomment IGSERVER noam.aprs2.net (maybe use a different server if you’re not in North America)
  4. uncomment IGLOGIN and change it to IGLOGIN {my-real-call} {my code}
  5. direwolf

Yay, you’re igating. But what’s around? Set up Xastir for that:

  1. xastir
  2. In the first menu that comes up, set your callsign to {my-real-call}-10 and (if desired) set your lat/long/position ambiguity
  3. Interface -> Interface Control, Add, Networked AGWPE, Add. Leave Pass-code blank, save and Start. Now you’re getting APRS from over the air displayed on your Xastir maps.
  4. Not enough for you? Interface -> Interface Control, Add, Internet Server, Add. Set Pass-code to {my-code}, save and Start. Now you’re getting APRS from the network as well.
  5. Want to see it on maps? I wasn’t able to get all the maps going, but things worked when I picked Maps -> Map Chooser and selected only Online/osm_tiled_mapnik.geo and worldhi.map.

Adding ATtiny support to Arduino IDE 1.6.1

March 22, 2015

I recently upgrade from the 1.0.5 version of the Arduino IDE to 1.6.1. Things aren’t completely smooth – in particular, I was using Coding Badly’s cores for ATtiny85, ATtiny84 and ATtiny2313.

Unfortunately, those haven’t yet been updated for the new layout specified in the 1.6.x IDE. So instead I switched for now at least to the damellis cores (which support ATtiny85 and ATtiny84, but not ATtiny2313/4313).

Installing this is a matter of unzipping it in the sketchbook/hardware folder (on my Windows box in C:\Users\{my user}\Documents\Arduino).

In Windows cmd shell:
cd "C:\Users\{my user}\Documents\Arduino"
mkdir hardware
unzip c:\{whatever}\attiny-ide-1.6.x.zip
cd hardware
move ..\attiny-ide-1.6.x\attiny .
cd ..
rmdir attiny-ide-1.6.x

At some point in the future either the Coding Badly cores will support IDE 1.6 (hopefully with the nice variants structure that the damellis cores use) or the damellis cores will do ATtinyX313s.


Setting up Raspbian on a Pi

February 26, 2015

I’ve been working on setting up a Raspberry Pi to do APRS using Dire Wolf and Xastir. That actually works fairly well, and I’ll write something about it later – this post is because I was using a flaky SD card, which decided to croak at an inopportune moment. Consequently, I had to reinstall Raspian again.

Since it’s easier to write it down than to remember, here’s what I did:

Burn the image

  1. Get the Raspbian image from the Raspberry Pi downloads page.
  2. Unzip it on a Linux box (mine saw the SD card as /dev/sdb, use your SD card device and don’t wipe your hard drive)
  3. Pop the card out of the Linux box and into the Pi

The command to write that I used:

sudo dd if=2015-01-31-raspbian.img of=/dev/sdb bs=4M

Configure the Pi

When the Pi boots into raspi-config, do the following:

  1. Expand Filesystem
  2. Change User Password
  3. Internationalisation Options / Change Locale, pick en_US UTF-8
  4. Internationalisation Options / Change timezones, pick yours
  5. Internationalisation Options / Change Keyboard Layout, pick US PC 104, accept defaults

Set up the network

I have my Pi configured with a static IP. The first time I boot I attach a network cable.

  1. Edit /etc/network/interfaces so the wired interface is static
  2. My /etc/resolv.conf was configured automatically by dhcp and was right
  3. Now would be a good time to edit /etc/hostname as well

The iface eth0 stanza in my interfaces file looks like:

iface eth0 inet static
address 192.168.17.15
netmask 255.255.255.0
gateway 192.168.17.1

Update the OS

This takes a while, but you can continue on while this is happening.

sudo aptitude update
sudo aptitude dist-upgrade

Add my user

I don’t like to use the default user, so I add my own.

  1. sudo adduser myuser
  2. edit /etc/group to add my user to all the pi groups (including sudo)
  3. log out, log in – make sure I can sudo with the new user
  4. prevent login as pi

To prevent the pi login, I do:

sudo vipw -s

and replace the password for pi with *.

Update everything else

Once the dist-upgrade has completed and it’s time to reboot:

sudo /sbin/shutdown -r now

Now you can log in again and upgrade the firmware:

sudo rpi-update
sudo /sbin/shutdown -r now

Get things I know I’ll need

I like to have an emacs clone:

sudo aptitude install zile
zile ~/.bash_aliases
alias emacs='zile'

I also like tightvncserver:

sudo aptitude install tightvncserver
tightvncserver
(set password)

That’s about it.


Foot Switch for the Insane

December 28, 2014

I’ve been looking for a foot switch for a while now to act as a PTT for a radio. Yesterday at a thrift store, I came across the Koino KH-8012:
SPST Foot switch with NEMA 1-15 plug

Do you see anything wrong with this picture? That is indeed a SPST foot switch with a NEMA 1-15 plug on the end. I can’t think of any reason that you would want to do that – the switch is rated at 15 A / 125 V AC (as well as 14 V DC), so it’s not like it was meant for a European destination where the corresponding socket wouldn’t be found in the wild.

The label is a lie too – it’s normally open, and conducts when closed. It is not SPDT: there are only two conductors coming out of the switch.

I’ve since rendered it safe and unable to short out household wiring by cutting off the NEMA 1-15 and adding a 1/4 inch jack instead.

All I can find about this switch is that it’s available from China and Vietnam, and costs USD $6.49 each when bought in large lots. Any idea what this was originally used for, or why on earth anyone would want to terminate it in a way that seems designed to blow fuses? Leave a comment.


Using Cygwin git on Samba

December 23, 2014

When I last updated the Cygwin git, it stopped working on my Samba drive. Normally running git on a network drive is not recommended, but I do it anyway. After a git upgrade, I started seeing:

error: invalid object 
error: Error building trees

when I did a commit. After a little searching, I discovered this Stack Overflow post which suggested one answer:

git config --add "core.createobject" rename

This appears to have solved the problem for me.


Repairing a MFJ-259B Antenna Analyzer

November 29, 2014

I’ve had an MFJ-259B antenna analyzer for a while, and for the most part it’s been pretty good. However, in the last few months I’ve seen it intermittently give me really high SWR as opposed to normal SWR.

Usually, that means there’s a break in a transmission line somewhere, but I kept seeing it on different lines. Curiously, it usually went away when I touched the antenna connector.

I wondered if I was adding capacitance or something to the system, but finally I realized it happened when the feedline cable pulled down on the analyzer. It was just a break between the antenna connector and the analyzer.

I took the analyzer apart, re-soldered the SO-239 and I was back in business.

Here’s what I learned when I took the antenna analyzer apart:

  1. Take the battery cover off first (two screws on the bottom)
  2. Next, unscrew both sides (four screws on each side)
  3. At this point, you’ll have access to the battery compartment. Take out the two top batteries and the two bottom batteries (don’t need to take out the rest).
  4. You’ll see four screws that hold the battery compartment to the analyzer. Actually, that’s a lie – only the two right-side screws hold the battery compartment to the analyzer. The left screws are screwed into Delrin insulators. Don’t unscrew the left screws or the insulators will drop off and you’ll have to look under the table for them. Just unscrew the right screws (top and bottom).
  5. At this point you can move the battery compartment to the side, and get easy access to the SO-239 connector. Don’t lose the lock washers that are under the screws.
  6. I suspect they used lead-free solder to solder the connector, which is more prone to cracking than 60/40. I upped the heat a little and mixed in some 60/40 solder to make it more durable.
  7. At this point you can put the 4 batteries back in and test with a dummy load and a good cable. I did this and verified my problems with mystery SWR were gone.
  8. Put things back together in the reverse order that you took them apart.

Signal out of range on Soyo Topaz S

November 25, 2014

I recently upgraded my monitor from an old Sharp 12″ to a Soyo Topaz S. Things seemed to be going well with the new monitor until I rebooted my Ubuntu Server (which was on 12.04 LTS). When I did that, I got the message “Signal Out of Range” from the monitor, and I couldn’t see what was being displayed.

According to a number of sources, this was because my monitor was being detected incorrectly and choosing the wrong resolution or colour depth. Lots of articles explained that you can change the mode in the config file /etc/default/grub.

To start with, I booted SysRescCD with the option gfxpayload=640×480. This got me to the point where I could see the file system, do an fsck (I’d gone 327 days without one) and mount my root drive in /mnt.

Naturally, when I did that, I discovered the file /mnt/etc/default/grub didn’t exist. That’s because I had upgraded originally from 8.04 LTS and that had never upgraded my grub to grub2.

But at least now I could ssh into my server again. I updated, then upgraded to 14.04.1 LTS because hey, the server needed it anyway. Immediately after doing that, I saw an error with every command, “no talloc stackframe at ../source3/param/loadparm.c, leaking memory”. The quick fix for that (as described in this ubuntuforums thread) was to run pam-auth-update and remove “SMB password synchronization”. As far as I can tell, that hasn’t changed anything with respect to what passwords are used for my shares.

Then I followed the instructions to upgrade from grub to grub2.

After that, I still couldn’t see my screen when I booted… but I had an /etc/default/grub. So I edited it, uncommented the line:

GRUB_GFXMODE=640x480

and had a booting system again. Yay! Eventually I figured out that I could go up to 1024×768 with no problems.

After that I realized I couldn’t do anything with the grub menu. I booted into the system, but couldn’t choose the OS to load with my USB keyboard.

So the next time I booted, I had to switch “USB Keyboard Support” in my BIOS from “OS” to “BIOS”. That fixed the grub menu problem.


Follow

Get every new post delivered to your Inbox.