Router hits two years

Today, the Linux machine serving as the router for my home network rolled over the two-year mark for uptime.  That means it has been powered up, booted, and routing my internal network to the rest of the world for 730 days without interruption:

10:10:26 up 730 days, 11:25,  3 users,  load average: 0.03, 0.02, 0.04

In the last two years, we have had several significant power outages, but none longer than the runtime of my Matrix 5000 UPS system.  Since the router would be the last thing to power down during an outage (without an internet connection, what is the point of anything else?), it has been able to ride out those events.  The machine itself is nothing special:

  • Dell  Dimension L566cx
  • 566MHz Celeron CPU with 128KB cache
  • 128MB RAM
  • BIOS date of 8/2/2000
  • 2 Intel e100 PCI NICs
  • 1 3COM 3c59x PIC NIC

This machine provides NAT for my internal machines, port forwarding for service hosting, VPN access, and a special network for the temporary D-STAR repeater I have at my house.  For a surplus machine with commodity hardware, this kind of performance and uptime is pretty awesome.  Go Linux!

Posted in Linux

Programming an RP4000V under Wine

Today, I hooked up the recently-acquired UHF duplexer from TX/RX Systems to our UHF D-STAR repeater.  I needed to program the machine to the new frequencies to match the duplexer and decided to try running the programming tool under Wine (well Crossover Office) instead of hauling out the old Win2k backup machine.  It appeared that the programming interfaces on the repeater were just FTDI USB-to-serial adapters and that the programming tool just talked to it as a serial device.  I figured that would be simple enough for Wine to handle.

The software installed under Wine, but I noticed that when I plugged my Linux machine into the programming port(s), the FTDI driver didn’t load.  If I loaded it manually, it didn’t recognize and take over the USB device.  It appears that the vendor of the FTDI chip in the repeater is non-standard, but that’s the only difference.  I reloaded the ftdi_sio module with the proper parameters to get it to notice the device and it worked.  I was able to program the machine under Wine, by linking dosdevices/com1 to the proper serial device.

To make it easier and more repeatable, I wrote a little script:

#!/bin/bash                                                                    
#                                                                              
# ICOM RPx000V serial helper script                                            
#                                                                              
# Copyright 2008 Dan Smith
# <dsmith.AT.danplanet.DOT.com>                              
#                                                                              
# This script will scan the USB bus on this system and determine               
# the product ID of any attached ICOM repeater modules.  It will               
# unload and then reload the FTDI serial driver with the proper                
# options to detect the device.  After that, it will determine the             
# device name and link /dev/icom to that device for easy access.               
                                                                               
LINK=”icom”                                                                    
VENDOR=”0x0c26″                                                                
DEVICE=$(lsusb -d ${VENDOR}: | cut -d ‘ ‘ -f 6 | cut -d : -f 2)                
                                                                               
if [ -z “$DEVICE” ]; then                                                      
    echo “No devices found”                                                    
    exit 1                                                                     
fi                                                                             
                                                                               
if echo $DEVICE | grep -q ‘ ‘; then                                            
    echo “Multiple devices found:”                                             
    for dev in $DEVICE; do                                                     
        echo $dev                                                              
    done                                                                       
                                                                               
    exit 1                                                                     
fi                                                                             
                                                                               
modprobe -r ftdi_sio || {                                                      
    echo “Unable to unload ftdi_sio”                                           
    exit 1                                                                     
}                                                                              
                                                                               
modprobe ftdi_sio vendor=${VENDOR} product=0x${DEVICE} || {                    
    echo “Failed to load ftdi_sio”                                             
    exit 1                                                                     
}                                                                              
                                                                               
info=$(lsusb -d ${VENDOR}:0x${DEVICE})                                         
bus=$(echo $info | cut -d ‘ ‘ -f 2 | sed ‘s/^0*//’Smilie: ;)                            
dev=$(echo $info | cut -d ‘ ‘ -f 4 | sed ‘s/^0*//’Smilie: ;)                            
                                                                               
for usbserial in /sys/class/tty/ttyUSB*; do                                    
    driver=$(basename $(readlink -f ${usbserial}/device/driver))               
    device=$(basename $usbserial)                                              
    if [ “$driver” = “ftdi_sio” ]; then                                        
        ln -sf /dev/${device} /dev/${LINK}                                     
        echo “Device is /dev/${device} -> /dev/${LINK}”                        
        break                                                                  
    fi                                                                         
done    

This works for both the TX and RX side of the RP4000V and I’m sure it works for the RP2000V, etc.  Just run the script and, if all goes as planned, it should print out the real device name and link /dev/icom to it for easy access.  If you just link your dosdevices/com1 to /dev/icom, then you don’t have to do much switching around to program the repeater.  Very cool!

Posted in Radio

D-RATS hits 1000 changesets!

Even though I was looking for the counter to roll over 1000 changesets back at about 850, I completely missed the event and kept on going.  On November 4th, 2008 (which also happens to be Election Day in the US), I committed the 1000’th change to the D-RATS tree:

changeset:   1000:39b8e08a1411
user:        Dan Smith
date:        Tue Nov 04 15:25:29 2008 -0800
summary:     Add multiselect form field type

The change added a new form field type that allows the user to pick one or more items out of a list.  This was necessary for the HICS260 form I was adding at the time, and was the first new form field type since forms were added on February 9th, 2008.  Since that commit, there have been 38 additional changes to date.

Just ten months ago, I was sitting at an ARES dinner talking with some D-STAR users about trying to come up with a better way to transfer files over D-STAR radios.  It was literally my second meeting with the local group, so I’m sure they had their doubts that the new guy would be able to do anything significant.  Many months later, D-RATS is used around the world, is available in two languages, and file transfers are only a small part of its feature set.  It’s a little hard to believe, but it’s even harder to imagine where D-RATS will be in another year.

Posted in Codemonkeying

Driving a 4-Bit LCD with an Arduino

I received my Arduino Diecimilia today.  Man, what a cool little device.  I ordered it last weekend with the intent of using it to learn about programming microcontrollers, in hopes of making some neat toys.  One of the first things I wanted to be able to do right away was drive an LCD display.  This is very important because I feel that all devices should have LCD displays.  All of them.  Nowadays, I look down on printers without LCD displays (and network cards for that matter) with utter disgust.

Anyway, I went to SurplusGizmos and found myself a nice and cheap 16×2 backlit LCD display.  It uses the KS0066 controller chip, which is supposedly compatible with the legendary Hitachi HD44780 command set.  Because I couldn’t wait for the Arduino to come, I tested it first with a parallel port and lcdproc.

When the Arduino came today, I was ready to try the LCD with it.  Using the integrated LiquidCrystal library, I was able to drive it in 4- and 8-bit mode.  However, in 4-bit mode, the LCD seemed to have trouble keeping up, as long strings would get garbled pretty badly.  It worked fine in 8-bit mode, so I figured this was likely due to the controller switching upper/lower nibbles too quickly.

So, in a bit of shameful C++ fu, I created a derivative library that just subclasses the existing one and puts a 2ms delay after each write operation.  This seems to completely clear up the problem, and I can happily have four digitial IO lines back as a result.

The code is extremely simple, so I’ll just post it here for the taking.  The header is:

#include “../LiquidCrystal/LiquidCrystal.h”

class Slow4BitLCD : public LiquidCrystal {
  public:
    Slow4BitLCD(uint8_t, uint8_t, uint8_t, uint8_t, uint8_t, uint8_t, uint8_t);
    void write(uint8_t);
};

…and the implementation is:

#include <inttypes.h>
#include “WProgram.h”

#include <Slow4BitLCD.h>
#include “../LiquidCrystal/LiquidCrystal.h”

Slow4BitLCD::Slow4BitLCD(uint8_t rs, uint8_t rw, uint8_t en, uint8_t d0, uint8_t d1, uint8_t d2, uint8_t d3)
  : LiquidCrystal::LiquidCrystal(rs, rw, en, d0, d1, d2, d3)
{}

void Slow4BitLCD::write(uint8_t value) {
  LiquidCrystal::write(value);
  delayMicroseconds(2000);
}

Create an Arduino library called “Slow4BitLCD” and put those two files in (with .h and .cpp extensions, respectively) and you should be in business.

Posted in Hardware

The death of a legend

On Tuesday, I lost a good friend.  Not only was he hard-working, but also extremely dependable in the face of adversity.  He had been with me longer than any of my other friends; some had come and gone, but this guy was in it for the long haul.  I always knew that he wouldn’t be around forever, because he had some pretty serious systemic health issues.  While I tried to prolong the “good times” by looking for quick fixes and even some home-made remedies, neither of us lost sight of the fact that the end was coming and there wasn’t much we could do to stop it.  On Tuesday, we lost our long battle, and my server room will never be the same.

So, in a tribute to his long and distinguished service, I think it’s worth a blog entry to highlight some of the fond memories.  His name was “stein.danplanet.com”.  The “stein” was short for “frankenstein,” and it was a reflection of his roots.  I don’t think he’d mind me saying that he wasn’t likely to win any beauty awards, much like the historical Frankenstein figure.

I’ll start at his core, an EPoX KP6-BS dual slot-1 motherboard.  This board was actually purchased by another friend (Jeff) as part of a computer he was building for college, on my recommendation.  He outfitted the board with two Pentium-II 333MHz processors, of mixed stepping.  When Jeff later upgraded his motherboard sometime in our freshman year, I purchased the board (and processors) from him for some amount that now escapes me.  Until not two years ago, I was still running those processors, overclocked to something weird, like 417MHz each.  I only recently replaced them with a set of matched 733MHz Pentium III’s.

His chassis was probably the most frankenstein-esque of anything.  In a prior life, the case was a small HP LH server, housing a single Pentium 100MHz processor and six 4GB Quantum Fast-SCSI2 drives.  The case had a nice hot-swap SCSI arrangement, so I had replaced four of the 4GB units for 9GB IBM SCA drives (actually rebadged by DEC).

The case was of the “cube” variety, which meant the motherboard was mounted on a plane in the middle of the chassis, separating the board itself and the slot cards from the drives.  The power supply originally in the case was a somewhat-proprietary AT unit, which didn’t work with the newer EPoX motherboard, which required an ATX connector.  So, I removed the HP power supply and installed two older units in its place.  On the motherboard side, I bolted a 145W ATX power supply out of a Gateway P-133 machine to the top of the case (there was plenty of room) which provided power for the motherboard and the front fans.  Since the old HP motherboard had powered the fans with non-standard connectors, I cut them off and put something usable on them.  Other changes to the motherboard side were rewiring the front-panel LEDs and switches for power and reset, as well as cutting out a portion of the back panel to line up with the ATX integrated connectors.

In the disk array side of the case, I now had a gaping, unsquare hole where the large, proprietary power supply used to be.  Since I knew I’d need some real airflow through that area, I opted for a 4″ AC fan from radio shack.  It’s big, quiet, and moves some air.  I cut a plate out of sheet metal that would cover the old PSU’s hole, and mounted the fan in it.  I then used the existing PSU mounting holes to secure the fan plate to the back of the chassis, sealing the old hole.

To power the disks on that side, I used an old CompuAdd power supply (about 200W) from a junk 486 I had laying around.  I had to wire a sniffer pin to +5V to get it to stay on, but it provided plenty of power for the disks (which started in stages, as instructed by the SCSI controller).  I also wired the fan to the main switch in the power supply.  Finally, I mounted a typical power connector that you’d see on a normal computer PSU on the back.  The result was two power ports on the back, one for the motherboard, and another for the disks.  The disk PSU and fan were wired “always on” so the fan would run whenever it was plugged in.  This was okay, though, because the system was literally never turned off.

So, there you have it — a description of “stein” in all his glory.  It is pretty amazing, but that machine has been running almost non-stop since late last century.  Until Tuesday, he had been online and reporting an uptime of greater than 18 months.  Extremely stable and dependable, he was my (and several others’Smilie: ;) external backup MX server and a mailman server.

Sometime Tuesday morning, two of the 9G SCSI drives died simultaneously, providing only an eerie clicking noise while trying to spin up.  The RAID5 array could, of course, not recover from this, and thus he was toast.  Luckily, I had a recent backup, which I quickly restored to a spare machine and set the soul of stein back online.  He’s operating in a netboot fashion off of another machine temporarily until I get something else in place.

Since I have no spare SCA SCSI drives, and don’t plan to buy any, stein will have to move to a normal box, with modern disks and power supplies.  It definitely won’t be the same machine anymore, but I’ll probably wait to change the hostname until it’s convenient, since several other machines know him by name.

Posted in Hardware

D-RATS in Italian!

D-RATS has really become quite a bit more popular than I originally anticipated.  A good indication of that is the fact that I just got my first translation request.  I figure that it’s a pretty strong indicator that you’ve created something worthwhile when people are willing to spend time maintaining a translation file for you.  Thanks to IZ5FSA, you will be able to run the next version of D-RATS in Italian:

Image

I imagine this will open up the door for other people looking to have D-RATS in their own native languages.  This was literally my first experience internationalizing an application, and I still haven’t quite decided how I want to fit it into my standard build process.  However, it’s a good thing to learn and it’s pretty neat to see my application in a language I can’t even begin to read!

Posted in Radio Tagged

Wash. Co. ARES on the news!

Yesterday evening, the PIO for our local ARES group called me and asked about availability for the next couple hours.  It turns out that a KATU news crew was looking for some footage of how hams can offer assistance to disasters from 2500 miles away.  We rushed over there and tried to have something ready before they got there.

The plan was to try to use the new (as in, 48 hours new) D-STAR repeater to talk to someone in Florida, potentially about the hurricane.  Not too surprisingly, 45 minutes isn’t quite enough time to coordinate something like that, and it turned out that the Florida repeater was a little busy at the time with some weather traffic (imagine that?).

So, we pulled up N7IS on the D1 ARES repeater to talk about the floods last winter, and got someone from Arkansas on the IRLP node.  We also had screens up of the D-RATS map showing the last known position of the guy in Florida, but I think they were a little difficult to shoot.

Anyway, as a result, we were on the 11pm news last night.  Only a few short snippets made it through, of course, but they made it look pretty decent.  I was pleased.  You can watch the video below, but be sure to pay attention to the last few words where they mention some locally-written software.  That’s D-RATS!

The people involved were Steve Sanders (KE7JSS), Tom Dixon (KE7FTE), and myself (KK7DS).

Posted in Radio

A PVC sheath for a portable GP-3

At the recent Hillsboro Air Show , I operated a portable station from First Aid Tent 2 out on the airfield.  Although it was completely overkill, we used a Comet GP-3 mounted about ten feet up.  We used a couple of sections of standard TV mast connected to a tripod (which was then zip-tied to a canopy strut).  This worked extremely well and is part of Ed Clark, KC7ZBI’s standard portable setup.

More recent than the air show, I worked a shift on the Hood-To-Coast relay race.  The race is mostly through back roads in the very northern bits of Oregon countryside.  Cell service is spotty in most places, and completely absent in many.  I was in a place where there was no cell coverage, and even the small 2-meter magmount on the car wasn’t getting into the repeater very well.  This gave me the excuse I needed to assemble a ready-to-go portable setup like the one we used at the Air Show.

The GP-3 is an ideal antenna for this, but at $100, it’s definitely something you don’t want to just throw around.  So, I decided to formulate a mechanism for protecting it during transit.  Ed uses a fishing pole holder with tennis balls around the antenna shaft, which works pretty well.  However, I had the idea of using standard PVC pipe parts to make something a little more custom.  The result is pictured here:

The parts involved are:

  • 1″ PVC schedule-40 pipe for the shaft (cut to length)
  • A 1″ PVC cap for the tip
  • A 2″ coupler
  • A 1″x2″ PVC bushing on either side of the coupler
  • A 1″ slide plug for the non-fixed bushing

I assembled all the pieces so that things fit snugly.  The bushing on the free end of the coupler makes a nice removable cap, and the SO-259 on bottom of the antenna slides into the plug in the hole of the bushing.  This means that everything fits snugly and doesn’t move around much.  I think that I will add some felt tape around the opening to the 1″ PVC shaft to keep from rubbing the antenna element too much.  The ground plane radials stay nicely attached to the exterior with some thick rubber bands.

All pieces are glued with PVC cement, except the end bushing that is supposed to remain free.  A few more pictures are available here.

Posted in Radio

Dear Thunderbird, I’m smarter than you

Lately, I’ve been getting a lot of log file attachments from users of D-RATS and CHIRP .  These are small text files, usually with a python stack trace at the end that provides illumination for some issue they’ve been having.  Because most of the world’s users are on Windows and Outlook, a representative portion of these come encoded as application/octet-stream.  I think Windows is the only major OS that uses filename extensions to determine the content type of a file.  As a result, Windows (and Outlook) don’t know what a .log file is, so they default to something unfortunate for text files.

Every time I get one of these in a mail from an Outlook user, Thunderbird tries to be helpful.  By “helpful” I mean “get in my way”.  Since the senders of malicious email content are always diligent about their MIME types, Thunderbird wants to make sure you only save this file, instead of attempting to execute it.  The result is that my desktop is littered with dozens of debug files that people send me, because I have to save them out somewhere.  All I really need to do is pop it open, glance at the stack trace, have my “ah ha” moment and move on.  Instead, it becomes: double-click, save, choose Desktop, save, show desktop, double-click, etc.

A friend (who recently discovered Thunderbird and the countless extensions available) recently pinged me about some new extension at the exact moment I was cursing at the screen because of the silly workflow into which I was being forced.  I came to the realization that some crafty person must have solved this for me already in the form of an extension.  So I went hunting and found the ViewSourceWith extension.  It’s technically for something completely unrelated, but it gives me the ability to define a list of editors that show up in an “Open With” submenu in the context menu of an attachment.  The result is a much less frustrating process of looking at debug logs.

Posted in Linux

GNUS Date Hacks

I’ve used GNUS for a long time…since my sophomore year in undergrad, I think.  I like it a lot, and have only cheated (er, experimented) a couple of times with various other mailers.  Even though I have used it for a long time, I don’t really consider myself a power user.  I mostly use the default configuration, with a few tweaks here and there (my .gnus file is only 177 lines).

Recently, we had some fantastic mail relay delays at work, on the order of days for some desintations.  By default, GNUS shows the date in the article buffer as local to the sender.  This can be nice, because you can see that someone in India was up late working on something, but it usually makes it hard to determine when it actually happened with respect to my local time.

These delays led me to look into getting GNUS to show my local time on messages.  The following in the dotfile fixes it:

(add-hook ‘gnus-part-display-hook ‘gnus-article-date-local)

While I was poking around, I found the date-lapsed option, which you enable with the following:

(add-hook ‘gnus-part-display-hook ‘gnus-article-date-lapsed)
(setq gnus-article-date-lapsed-new-header t)

Be sure to put that before the date-local call, otherwise you won’t get the behavior you expect.  The date-lapsed bit provides a really nice time-since-this-was-sent reading, which looks like this:

Date: Tue, 26 Aug 2008 13:40:43 -0700
X-Sent: 9 minutes, 25 seconds ago

How cool is that?  Now I can keep tabs on how out-of-touch the slow IBM mail servers are keeping me!

Posted in Linux Tagged ,