Setting up a WD Red drive for use in a NAS

April 12, 2015

It’s in bits and pieces all over the net, but I haven’t seen it all in one place yet. Western Digital Red drives have 4k (4096 byte) sectors rather than the old 512 byte sectors. In order to use them optimally, you need to format them aligned on those sectors.

The first trick is to use parted to define the partitions, and a version of 2.2 or higher, as described on this Western Digital support article.

Next, you need to decide what your partition table should look like. For maximum compatibility, use msdos. But if you have drives larger than 2G, you will probably want to use gpt instead.

Assuming you’re using /dev/sdd as your drive:

# parted -a optimal /dev/sdd
(parted) mklabel msdos
(parted) q

Next, you will want to add the partition. In my case, I wanted to create an ext4 partition that took up the whole disk. Here’s how:

# parted -a optimal /dev/sdd
(parted) mkpart primary ext4 0% 100%
(parted) p
Model: ATA WDC WD20EFRX-68A (scsi)
Disk /dev/sdd: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  2000GB  2000GB  primary  ext3
(parted) q

The -a optimal is the magic bit that tells parted to partition on 4k boundaries for a 4k drive. My ext4 partition actually got created as an ext3 partition, since those are the same partition type.

Then you need to create a file system on the partition you just created. I add a label afterwards so I can mount it via label in /etc/fstab. (There’s a way to add a label in the mkfs command, but I can never remember it, so I do it in two steps.)

# mkfs -t ext4 /dev/sdd1
# e2label /dev/sdd1 mynewdrive

Then edit /etc/fstab to add the new drive to it:

LABEL=mynewdrive /newdrivemountpoint ext4 defaults 0 2

The label matches the label I specified on e2label, and the /newdrivemountpoint is the directory in the Unix file system that I want the drive to be mounted on. The last two numbers say “don’t dump” (0) and “do fsck after the root drive” (2). See the man page or the Ubuntu fstab page for more details on that.


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.

Follow

Get every new post delivered to your Inbox.