Freeside Development Environment (day 1)

I'm on the job market again after two wonderful years at Broadbean. Sadly, budget cuts eliminated my position and several others, but enough about that. Anyway, as part of my job search, I came upon Freeside, which is a billing application for ISP's, CLEC's, and similar. They work on an open source, paid support model, so after discussion with Ivan, the CEO and "head geek", I thought I'd do some work "on spec" as a job application of sorts. But to begin with, I need a development environment.

At Broadbean I got used to every package we worked on having its own cpanfile. This meant that, using perlbrew, all I had to do was perlbrew lib create perl-<version>@<package>, and then cpanm --installdeps ., and I was set. Freeside doesn't work like that, so I'll set up a VirtualBox VM for it instead.

I'm going to use Debian 8.9.0 (Jessie), as that is the version where installation instructions are completely documented in the Freeside wiki. So I've downloaded the Debian network install CD image from https://cdimage.debian.org/cdimage/archive/8.9.0/amd64/iso-cd/ and will install it into a VM. I've got Google Fiber, so this shouldn't take long.

Since I intend to interact with this VM via SSH and a browser, I've selected the "web server", "SSH server", and "standard system utilities" collections. A few minutes later, the system is installed, I've rebooted the VM, and installed sudo (I prefer using sudo to simply doing su). I set up a network interface, put in my SSH key for passwordless login, and I'm ready to start setting up my development environment.

First thing to install is vim. This is my preferred editor for code, and I can't abide nano. ;) Next I set up the package repositories as specified in the Freeside installation instructions and install the Freeside packages. I'll note here that aptitude is recommending that I remove the packages exim4, exim4-base, exim4-config, and exim4-daemon-light, and is not installing the recommendation of the Perl EV package. I assume since Freeside is installing Mojolicious, it is going to be running under Mojo::IOLoop (which I was just working with at Broadbean. Freeside++!) No, I was mistaken. Only very minimal usage of Mojolicious in Freeside.

OK, a few minutes later all the packages are installed and I'm setting up the database. Note where the docs say "[ as postgres/pgsql user ]" they mean "user" to be the system user (from /etc/passwd) "postgres". I set up the database role with a crappy password (this box isn't exposed to the internet, after all) and as the "freeside" user, I execute freeside-setup -d example.com. Note that the domain is important - if it's not a valid TLD, freeside-setup will throw an error and you'll have to blow away the freeside database and start over. Anyway, freeside-setup barfs, so now I need to figure out what I did wrong.

Turns out the wiki has things in the wrong order. I need to set up the RT database before I run freeside-setup. With that done, I can move on, install the system users and so on, and I should be up and running. Sure enough, I am able to restart the Freeside daemon successfully.

Since I want to hack on Freeside, I think I need to blow away the Freeside packages and set up a fresh installation via the instructions on installing from source. This might allow me to use perlbrew as well, but I'm not certain of that. But that's a task for another day.

Genuine, Honest-to-Ada, Taleo MTOM/XOP export example

Because this has been vexing me for months.

So the key here is that you have two Document elements. One in the SOAP envelope, and one in the attachment. Your Attributes (gotta have those) go in the Document element in the attachment.
POST https://your-client-id.taleo.net/enterprise/soap?ServiceName=IntegrationManagementService HTTP/1.1 Authorization: Basic XXXXXXXXXXXXXXXXXXXX User-Agent: libwww-perl/6.15 Content-Type: multipart/related; boundary=MIME-boundary-4180; type="application/xop+xml"; start="<xml@localhost>"; start-info="text/xml; charset=utf-8" SOAPAction: "http://www.taleo.com/ws/integration/toolkit/2011/05/management/IntegrationManagementService#submitLargeDocument" X-LWP-Version: 6.15 X-XML-Compile-Cache-Version: 1.04 X-XML-Compile-SOAP-Version: 3.18 X-XML-Compile-Version: 1.52 X-XML-LibXML-Version: 2.0126 --MIME-boundary-4180 Content-Type: application/xop+xml; charset="utf-8"; type="text/xml; charset=utf-8" Content-ID: <xml@localhost> Content-Transfer-Encoding: 8bit <?xml version="1.0"?> <soap11:Envelope xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/"> <soap11:Header> <wsa:MessageID xmlns:wsa="http://www.w3.org/2005/03/addressing">Query-Export-30F84EB0-957D-11E6-BEE2-84322521867A</wsa:MessageID> <wsa:ReplyTo xmlns:wsa="http://www.w3.org/2005/03/addressing"> <wsa:Address>http://www.taleo.com/ws/integration/toolkit/2005/07/addressing/queue</wsa:Address> </wsa:ReplyTo> <wsa:Action xmlns:wsa="http://www.w3.org/2005/03/addressing">http://www.taleo.com/ws/integration/toolkit/2005/07/action/export</wsa:Action> </soap11:Header> <soap11:Body> <tns0:submitLargeDocument xmlns:tns0="http://www.taleo.com/ws/integration/toolkit/2011/05/management" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <tns0:Document xmlns:xmime="http://www.w3.org/2005/05/xmlmime" xmime:contentType="text/xml"> <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:1476827562@localhost"/> </tns0:Document> </tns0:submitLargeDocument> </soap11:Body> </soap11:Envelope> --MIME-boundary-4180 Content-Type: text/xml Content-ID: <1476827562@localhost> Content-Transfer-Encoding: binary <Document xmlns="http://www.taleo.com/ws/integration/toolkit/2011/05"> <Attributes> <Attribute name="version">http://www.taleo.com/ws/tee800/2009/01</Attribute> <Attribute name="mode">T-XML</Attribute> </Attributes> <Content> <ExportQuery xmlns="http://www.taleo.com/ws/integration/toolkit/2005/07/action/export"> <query xmlns="http://www.taleo.com/ws/integration/query" projectedClass="Candidate" alias="Export_30F84EB0-957D-11E6-BEE2-84322521867A_20161018165240" preventDuplicates="false"> <projections> <projection> <field path="EmailAddress" localeFiltering="none"/> </projection> <projection> <field path="Number" localeFiltering="none"/> </projection> </projections> <filterings> <filtering> <equal> <field path="Number"/> <integer>12345</integer> </equal> </filtering> </filterings> </query> </ExportQuery> </Content> </Document> --MIME-boundary-4180--

Freelancing again

I have once again joined the ranks of the freelance developer community. It wasn't by choice, and I've been looking for full-time gigs, but nothing's panned out as of yet. So in the mean time, I'm trying to make the best of my situation, and I'm hoping this new site I've heard about, Toptal, can help.

Why Toptal? A couple of reasons. First, I need the work, and the more sites I'm on where I can get work, the better. But second, and this remains to be seen, is that I'm hoping Toptal can put me in front of clients who can really challenge me as a developer. Where I can solve exciting new problems.

Since I'm primarily a Perl guy, I'm joining Toptal's Perl Developers Network. I don't mind learning the latest shiny new technology - like single page Javascript, for example - but that's not my end goal. I'm not looking to learn the new technologies just to check off a box, or to add a line to my resume. I'm looking to create solutions. If there's a tool I need to learn in the process of creating a solution, that's great. But it's not an end in itself. So I'm joining their Perl network in the hope of finding clients who are less concerned with the latest HR buzzword and more concerned about getting things done.

Auto-generating setters and getters in Perl with Moose

As part of a project for work interfacing with the RDS encoder for the radio station (an Inovonics Model 730) I thought, "wouldn't it be nice to have a Perl object that provides a complete interface to this device?"  The only trouble is that the device takes a lot of different commands, and it would be really tedious to write sub set_foo { ... }; sub get_foo { ... } umpteen million times for every last command / datum the encoder supported, since every set_foo { ... } was going to boil down to:

sub set_foo {
    my ($self, $value) = @_;
    return _set('foo', $value);
}

sub get_foo {
    my $self = shift;
    return _get('foo');
}

Where _set() and _get() took care of the actual business of communicating with the encoder.

Now, I could have done this in Vim with regular expressions - just copy/paste and use the regex to change the appropriate things. Still tedious, though. I also could have done something like this:

sub set_property {
    my ($self, $property, $value) = @_;
    return _set($property, $value);
}

sub get_property {
    my ($self, $property) = @_;
    return _get($property);
}

And that would have worked fine. I could have put some code in there to throw an exception on an invalid property, maybe something to validate the values based on the property name, all that sort of thing. But Moose gives us a nifty trick to avoid having to validate the property name:

    package MooseSketch;
    use Moose;

    my $meta = __PACKAGE__->meta;
    foreach my $prop (qw/foo bar baz bak/) {
        $meta->add_method(qq/set_$prop/, sub { 
                my $self = shift;
                my $value = shift;
                return $self->_set($prop, $value);
            }
        );
        $meta->add_method(qq/get_$prop/, sub { 
                my $self = shift;
                return $self->_get($prop);
            }
        );
    }

This $meta business comes from Class::MOP::Class, which allows us to do introspection and manipulation of Perl 5 objects. So with Class::MOP::Class, I can add or remove methods programatically at runtime, or even create entire classes. Neat, huh?

Hope you find this useful. I know I sure will. Many thanks to the good people over at Stack Overflow who helped me figure this out. My original question: How to auto-generate a bunch of setters/getters tied to a network service in Moose?

Generating a Word document with Perl and Win32::OLE

I'm about to have to throw this particular bit of code away, as I'm not able to get this to work from Scheduled Tasks on Windows 7.  Before I sent it to the bit bucket, however, I thought I'd post it here with the hope that someone will find it useful.

# Expects arguments as a hashref with the keys:
# # log_date: Date of the log
# # data: an arrayref of arrayrefs.  First line is treated as column headings, following lines are treated as data.
#
# A double horizontal rule will be added between the column headings and the data.
#
# NB: The reason that everything gets its own object (e.g. "my $tables = $doc->Tables; my $table = $tables->Add(...);")
# is not (neccessarily) for "Law of Demeter" reasons, but rather MS recommended practice when
# automating Office applications from Visual Studio (and by extension, OLE): http://support.microsoft.com/kb/317109
# Experimentally, I have noticed instances of the Word executable remaining in memory after program exit;
# refactoring the code in this way is an attempt to deal with that issue.
# 11 Feb 2013 KP
sub _print_with_word {
    my $args = shift;

    if ( ref $args ne q/HASH/ ) {
        croak(
            sprintf q/Usage: %s /,
            ( caller 0 )[$FUNCTION_NAME_POSITION]
        );
    }
    foreach my $required_key (qw/log_date data/) {
        if ( !$args->{$required_key} ) {
            croak(qq/Missing required key '$required_key' in args/);
        }
    }

    my $header = _slurp_file( $CONFIG->{'_'}{'header_file'} );
    my $footer = _slurp_file( $CONFIG->{'_'}{'footer_file'} );

    my @rows = @{ $args->{'data'} };

    my $word   = Win32::OLE->new( 'Word.Application', 'Quit' );
    _debug(q/Created new Word object/);

    my $doc    = $word->Documents->Add();
    _debug(q/Added new document/);

    my $selection = $word->Selection;
    _debug(q/Got Selection instance/);    

    
    my $selection_paragraph_format = $selection->ParagraphFormat;
    _debug(q/Got ParagraphFormat instance for selection/);
    
    $selection_paragraph_format->{'SpaceAfter'} = 0;
    _debug(q/Set paragraph spacing for header/);
    
    $selection->TypeText( { 'Text' => qq/$header\n\n/, } );
    _debug(q/Typing header into selection/);
    
    $selection->BoldRun();
    _debug(q/started bold run/);
    
    $selection_paragraph_format->{'Alignment'} = wdAlignParagraphRight;
    _debug(q/Set date paragraph format to right/);
    
    $selection->TypeText(
        {
            'Text' => Time::Piece->strptime(
                $args->{'log_date'}, q|%m/%d/%Y %H:%M:%S|
              )->strftime(qq/%A %B %d %Y\n\n/)
        }
    );
    _debug(q/Typing date header into selection/);
    
    $selection->BoldRun();
    _debug(q/End bold run/);

    my $range  = $selection->Range;
    _debug(q/Got Range instance from selection/);
    
    my $tables = $doc->Tables;
    _debug(q/Got Tables collection from document/);
    
    my $table  = $tables->Add( $range, scalar @rows, scalar @{ $rows[0] } );
    _debug(q/Added new table to document/);
    
    for my $rownum ( 0 .. $#rows ) {
        my $cols = $rows[$rownum];
        for my $colnum ( 0 .. $#{ $rows[$rownum] } ) {
            my @cellpos    = ( $rownum + 1, $colnum + 1 );
            my $cell       = $table->Cell(@cellpos);
            _debug(qq/Got cell at ($cellpos[0], $cellpos[1]) /);
            
            my $cell_range = $cell->Range;
            _debug(qq/Got Range instance for cell at ($cellpos[0], $cellpos[1])/);
            
            $cell_range->{'Text'} = $cols->[$colnum];
            _debug(qq/Set text of Range for cell at ($cellpos[0], $cellpos[1]) to "$cols->[$colnum]"/);
        }
    }
    my $rows                 = $table->Rows;
    _debug(q/Got Rows collection from table/);
    
    my $first_row            = $rows->First;
    _debug(q/Got first Row object (header row) from Rows collection/);
    
    my $first_row_range      = $rows->First->Range;
    _debug(q/Got Range instance for header row/);
    
    my $first_row_range_font = $first_row_range->Font;
    _debug(q/Got Font instance for header row Range/);
    
    $first_row_range_font->{'Bold'} = 1;
    _debug(q/Set header row Range Font to bold/);
    
    my $first_row_range_paragraph_format = $first_row_range->ParagraphFormat;
    _debug(q/Got ParagraphFormat instance for header row/);
    
    $first_row_range_paragraph_format->{'Alignment'} = wdAlignParagraphCenter;
    _debug(q/Set alignment for table headers to center/);
    
    my $first_row_bottom_border = $first_row->Borders(wdBorderBottom);
    _debug(q/Got Border instance for bottom of header row/);
    
    @{$first_row_bottom_border}{qw/LineStyle LineWidth/} =
      ( wdLineStyleDouble, wdLineWidth100pt );
    _debug(q/Set bottom border of header row to 10 pt double line/);
      
    my $paragraphs            = $doc->Paragraphs;
    _debug(q/Got Paragraphs collection from document/);
    
    my $last_paragraph        = $paragraphs->Last;
    _debug(q/Got last paragraph from document/);
    
    my $last_paragraph_format = $last_paragraph->Format;
    _debug(q/Got Format instance for last paragraph/);
    
    $last_paragraph_format->{'Alignment'}  = wdAlignParagraphLeft;
    _debug(q/Set last paragraph alignment to left/);
    
    $last_paragraph_format->{'SpaceAfter'} = 0;
    _debug(q/Set spacing on last paragraph/);
    
    my $last_paragraph_range = $last_paragraph->Range;
    _debug(q/Got Range instance for last paragraph/);
    
    $last_paragraph_range->InsertAfter( { 'Text' => qq/\n$footer/ } );
    _debug(q/Inserting footer after last paragraph range/);
    
    #$doc->SaveAs( { 'Filename' => Cwd::getcwd . '/test.doc' } );
    
    $doc->PrintOut();
    _debug(q/Printed document/);
    
    $doc->Close( { 'SaveChanges' => wdDoNotSaveChanges } );
    _debug(q/Close document without saving/);
    
    $word->Quit();
    _debug(q/Quit Word/);
    
    return 1;
}

"Wire-to-wire" emulation with Proxy ARP

In my previous post, I stated a goal of mimicing the connectivity provided by the microwave T-1 connecting the studio and TV transmitter at my work.  I'm pleased to say that I've accomplished that... mostly.  There are still a few peculiar kinks to work out.

It all works through the magic of Proxy ARP.  Basically, what Proxy ARP does is allow one machine to answer ARP queries on behalf of another machine, saying, in effect "I'll take that packet; I know how to get to that machine".  The answering machine then forwards the packet on to the appropriate machine.  This differs from packet routing in that it happens in Layer 2 of IP, rather than Layer 3 (routing).

In practice, what you have to do is set up static routes on the host (which is acting in this case as a bridge) doing Proxy ARP for all hosts the bridge is providing the connection for, then turn on IP forwarding in the kernel, and turn on Proxy ARP for the appropriate interfaces.  Since I have an IPsec / L2TP VPN set up, the interfaces are going to be ppp0 for the VPN (since it's L2TP and IPsec, PPP is involved, where with straight IPsec it wouldn't be) and eth0 for the local network. I'm also going to have to do the same thing on the firewall out at the transmitter.

So, first of all, the studio.  This is based on Using Linux as an L2TP/IPsec VPN client by Jacco de Leeuw.

The xl2tpd configuration file at the studio:

; File: /etc/xl2tpd/xl2tpd.conf at STUDIO
[lac Transmitter]
; transmitter public IP obfuscated for security reasons
  lns = X.X.X.10 
  require chap = yes
  refuse pap = yes
  require authentication = yes
  ; Name should be the same as the username in the PPP authentication!
  name = bridge
  ppp debug = yes
  pppoptfile = /etc/ppp/options.l2tpd.client
  length bit = yes

Note that I'm not using the l2tp-secrets file as it really doesn't provide any additional security, as far as I can tell.

The PPP options file at the studio:

# /etc/ppp/options.l2tpd.client at STUDIO

ipcp-accept-local
ipcp-accept-remote
refuse-eap
noccp
noauth
crtscts
mtu 1410
mru 1410
nodefaultroute
debug
lock
connect-delay 5000

PPP authentication is done in /etc/ppp/chap-secrets:

# File: /etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client        server          secret                  IP addresses
bridge          *               "supersecret"
*               bridge          "supersecret"

To set up the static routes, I have set up two scripts in /etc/ppp/ip-up.d. Scripts in this directory are executed by pppd as ip-up scripts - scripts that are executed when the PPP interface is brought up. These set up static routing and turn on Proxy ARP.

#!/bin/bash

# File: /etc/ppp/ip-up.d/0001routes

PPP_INTERFACE=$1
LOCAL_ADDR=$4
REMOTE_ADDR=$5

# These are all the hosts that should be accessible both via the VPN
HOSTS=(
10.1.1.10
10.1.1.11
10.1.1.12
10.1.1.13
)

for HOST in ${HOSTS[*]}
do
        route add -host $HOST $PPP_INTERFACE
done

#!/bin/bash

# File: /etc/ppp/ip-up.d/0002proxyarp

for INTERFACE in ppp0 eth0 ; do
        /sbin/sysctl -w net.ipv4.conf.${INTERFACE}.proxy_arp=1
done

The ipsec (openswan) configuration file at the studio:

# File: /etc/ipsec.conf
# 
config setup
        protostack=netkey
conn Transmitter
        #
        # ----------------------------------------------------------
        # Use a Preshared Key. Disable Perfect Forward Secrecy.
        # Initiate rekeying.
        # Connection type _must_ be Transport Mode.
        #
        authby=secret
        pfs=no
        rekey=yes
        keyingtries=3
        type=transport
        #
        # ----------------------------------------------------------
        # The local Linux machine that connects as a client.
        #
        # The external network interface is used to connect to the server.
        # If you want to use a different interface or if there is no
        # defaultroute, you can use:   left=your.ip.addr.ess
        left=%defaultroute
        #
        leftprotoport=17/1701
        #
        # ----------------------------------------------------------
        # The remote server.
        #
        # Connect to the server at this IP address. (obfuscated for security)
        right=X.X.X.10
        #
        rightprotoport=17/1701
        # ----------------------------------------------------------
        #
        # Change 'ignore' to 'add' to enable this configuration.
        #
        auto=add
        DPDACTion=restart_by_peer
        dpdtimeout=30
        dpddelay=3

Next, the transmitter side.  Again, starting with xl2tpd:

; File: /etc/xl2tpd/xl2tpd.conf

[global]
        ipsec saref = no
        listen-addr = X.X.X.10

[lns default]
        ip range = 10.1.1.100 - 10.1.1.255
        local ip = 10.1.1.1
        assign ip = yes
        require chap = yes
        refuse pap = yes
        require authentication = yes
        name = Transmitter
        ppp debug = no
        pppoptfile = /etc/ppp/options.xl2tpd
        length bit = yes

And now PPP:

# File: /etc/ppp/options.xl2tpd

refuse-mschap-v2
refuse-mschap
ms-dns 8.8.8.8
asyncmap 0
auth
lock
hide-password
local
#debug
name l2tpd
#proxyarp
lcp-echo-interval 30
lcp-echo-failure 4

# File: /etc/ppp/chap-secrets

# Secrets for authentication using CHAP
# client                server                  secret                  IP addresses
user1                   *                       "secret1"               10.1.1.0/24
*                       user1                   "secret1"               10.1.1.0/24
user2                   *                       "secret2"               10.1.1.0/24
*                       user2                   "secret2"               10.1.1.0/24
bridge                  *                       "supersecret"           10.1.1.2
*                       bridge                  "supersecret"           10.1.1.2

Here I want to pause and note something. I have my regular "road warrior" users set up to get any address in 10.1.1.0/24, and in my xl2tpd config, I have that further restricted to addresses in the range of .100 - .255. The "bridge" user is restricted to 10.1.1.2, which is how I allow my "road warriors" and the bridge at the studio to coexist. The appropriate scripts in /etc/ppp/ip-up.d at the transmitter:

#!/bin/bash

# File: /etc/ppp/ip-up.d/0001routes
# The hosts here are made accessible to the transmitter network via the firewall, which is acting as a bridge similar to the one at the studio

PPP_INTERFACE=$1
LOCAL_ADDR=$4
REMOTE_ADDR=$5


# only set up the routes for the VPN bridge
case $REMOTE_ADDR in
10.1.1.2)
        for HOST in     10.1.1.20 \
                        10.1.1.21 \
                        10.1.1.22 \
                        10.1.1.23 ; do
                route add -host $HOST $1
        done
esac

#!/bin/bash
PPP_INTERFACE=$1
LOCAL_ADDR=$4
REMOTE_ADDR=$5

# File: /etc/ppp/ip-up.d/0002proxyarp
# only set up Proxy ARP for the VPN bridge
case $REMOTE_ADDR in
10.1.1.2)
        for INTERFACE in $PPP_INTERFACE eth0 ; do
                /sbin/sysctl -w net.ipv4.conf.${INTERFACE}.proxy_arp=1
        done
esac

And finally the ipsec (openswan) configuration, based on Configure L2TP/IPSec VPN on Ubuntu by Riobard Zhan:

#
# File: /etc/ipsec.conf
#

# Transmitter Firewall Side

config setup
    oe=off
    protostack=netkey
    nat_traversal=yes

conn L2TP-PSK-NAT
    rightsubnet=vhost:%no
    also=L2TP-PSK-noNAT

conn L2TP-PSK-noNAT
    authby=secret
    pfs=no
    auto=add
    keyingtries=3
    rekey=no
    ikelifetime=8h
    keylife=1h
    type=transport
        left=X.X.X.10
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any
    dpdaction=restart_by_peer
    dpdtimeout=30
    dpddelay=3

So the way to accomplish this "wire-to-wire" emulation is with two bridges, one for each network to be bridged. If you want to try something like this, I wish you the best of luck, and I hope my experiences help.

Setting up an IPsec VPN

Posted here mostly for my own reference, but mayhap this will prove useful for someone else.

The setup: a remote network at the TV transmitter, with Internet access both through a commercial provider and a dedicated, but increasingly unreliable, microwave T-1 link to the studio.

The goal: mimic the behavior of the microwave T-1 (though not the unreliability, of course) using the commercial provider's service.  Set up a "virtual wire" between the network at the transmitter and the transmitter at the studio.

I've chosen an IPsec VPN to do this, and I've set things up largely as in Ch. 35 of Linux Home Networking. At the present time I've managed to achieve bidirectional communication between hosts (but not the routers/firewalls) on each network, but to do that I had to set up a private test network as shown below.

So as you can see here, I have a couple of virtual machines set up on the 172.16.1.0/24 network, which is accessible only to those VM's.  The IPsec tunnel is established between Router VM and Transmitter Firewall.  Note that I have replaced Transmitter Firewall's public IP address with "X.X.X.10" for security.

With this setup, I can achieve bidrectional communication between both networks.  Host A can reach Client VM, and Client VM can reach Host A.

Here is the relevant ipsec.conf on Router VM:

#
# File: /etc/ipsec.conf
#
# VPN Test Router VM side
config setup
        protostack=netkey
        oe=off
        nat_traversal=yes

# LEFT: Studio
# RIGHT: Transmitter
conn nettonet
  left=192.168.152.188            # Public Internet IP address of the
                                  # LEFT VPN device
  leftsubnet=172.16.1.0/24        # Subnet protected by the LEFT VPN device
  leftrsasigkey=*removed*

  right=X.X.X.10                  # Public Internet IP address of
                                  # the RIGHT VPN device
  rightsubnet=10.1.1.0/24         # Subnet protected by the RIGHT VPN device
  rightrsasigkey=*removed*
  rightnexthop=%defaultroute
  auto=start

Note here that I'm using RSA keys, rather than PSK's.  The key signatures have been removed for security.

The ipsec.conf on Transmitter Firewall is slightly different:

#
# File: /etc/ipsec.conf
#

# Transmitter Firewall Side

config setup
    oe=off
    protostack=netkey
    nat_traversal=yes

# LEFT: Studio
# RIGHT: Transmitter
conn nettonet
  left=10.1.0.2                   # Public Internet IP address of the
                                  # LEFT VPN device
  leftsubnet=172.16.1.0/24        # Subnet protected by the LEFT VPN device
  leftid=192.168.152.188
  leftrsasigkey=*removed*
  right=X.X.X.10                  # Public Internet IP address of
                                  # the RIGHT VPN device
  rightsubnet=10.1.1.0/24         # Subnet protected by the RIGHT VPN device
  rightrsasigkey=*removed*
  auto=start                      # authorizes and starts this connection
                                  # on booting

Here you'll notice that the argument to left= is 10.1.0.2, which is the public (again, these IP's have been obfuscated for security's sake) address of Studio Firewall. This is because Router VM's ultimate path to the Internet is through Studio Firewall via NAT.

Speaking of NAT, I should point out that there is no NAT of any kind being performed (currently) on Router VM or Transmitter Firewall.  Instead, the entire 172.16.1.0/24 network is visible to the 10.1.1.0/24 network at the transmitter, just as any other public network would be.

I'll note that this does not accomplish the stated goal at the beginning of this post: set up a "virtual wire" between the 10.1.1.0/24 network at the studio and the 10.1.1.0/24 network at the transmitter.  It may turn out to be the case that this "virtual wire" is extremely complicated with regard to routing and suchlike (since we would be using the same IP block on both ends) .  What this does give us, however, is a place to work from.

Making a homebrew HDTV antenna

Since I work for a TV station now, and we're web-casting a lot of University sports, it behooves me to get more familiar with sports broadcasting, and one of the ways I'm doing that is to watch sports on TV.  Now, I'm still too cheap to pay for cable TV, I'm on my holiday break, and most importantly I haven't built an antenna since my J-pole, so I figured I ought to build myself a TV antenna. 

I'm basing this antenna on plans I found for a UHF bowtie antenna here.  Now, being the sort of guy I am, I can't just blindly follow the recipe. :)  I need to screw around with it a bit, and see if I can improve on the design based on my own particular situation. 

I went to TV Fool's signal locator and put in my address.  It gave me a handy list of all the TV broadcast stations in the area, along with their channel assignments (if you're following along at home, note that you need the actual channel assignment, not the virtual channel.  Sometimes these two things are different).  Next, I consulted Wikipedia for a list of TV channels and associated frequencies.  This told me that all the TV stations in town were in the range of 494 MHz to 698 MHz. 

I think it's safe to assume that the original design is tuned for a broader frequency range than I need.  If I tune the design for my narrower range, maybe I can get another dB or two of gain, which will improve my signal quality.  Also, it's more fun that way. :)

Now for the parts.  I went to the hardware store and bought some deck screws, some washers, and a 2 x 4.  They didn't have any 1 x 3's or 2 x 3's, and I didn't much feel like going somewhere else to see what they had.  I also bought a 75Ω to 300Ω balun, as called for in the design (this design has a 300Ω characteristic impedance).  For the antenna bays, I've got some old wire hangers laying around that need to be put to a good use.  I've also got wire laying around that I can use to interconnect the bays.

In the design, each antenna bay is a pair of 14" wires, folded into a "V" whose ends are 3" apart (so an angle of about 25°).  This is a bowtie antenna, so each side of the bay is a dipole 1/2 wavelength long.  14" gives a wavelength of about 420 MHz, well below the minimum frequency I'm looking for. 

Let me pause a moment to detail how I'm calculating the length of the dipole.  Wavelength (λ) is equal to the speed of light (c) divided by the frequency (f).  So:

λ = c/f

An important thing to note here is that c isn't always c, if you take my meaning.  Generally speaking, if someone mentions c in the context of the speed of light, they mean the speed of light (or other electromagnetic radiation) in a vacuum.  In (e.g.) a metal, however, electromagnetic radiation moves more slowly.  So we introduce a velocity factor, a number that describes just how much slower electromagnetic radiation is going to move in the material than in free space.  If we call the velocity factor v, then we get:

λ = cv/f

This is good.  By introducing the velocity factor into the equation, we can more precisely model how electromagnetic radiation (e.g. radio waves) is going to behave in the wire of the dipole.  But I don't have a velocity factor for steel wire (which is what they make wire hangers out of), so I'm just going to use a value of 1 for v. 

So, back to the antenna, if I want a minimum frequency of 494 MHz, I want to start with a dipole about 12" long.  I can always trim it down later if I need to.

Now, let's get to building!  To start with, I'm going to cut my wire hangers into 8 12" pieces.  And this is tougher than it sounds.  A pair of dikes (diagonal cutters) won't cut it.  Tin snips won't do it.  A stout pair of side-cutters (or "Kleins", electrician's pliers) might do it, but I don't have a pair of those.  What I'm doing instead is taking a big pair of dikes and gripping the wire where I want it to break, then just wiggling the hanger back and forth until it breaks.  Metal fatigue FTW!

8 12" dipoles

As you can see, some of these aren't exactly straight.  A number of wire hangers came from the dry cleaner, and they only have metal on top - the bottom is just thick paper.  So I straightened those as best I could.  I also sanded the center of each dipole because  I'm going to short all the dipoles along each side together at the center.

Dipoles bent so that the distance between each leg is roughly 3"

Here are the bent dipoles.  I've tried to keep the spacing between the two legs to about 3 inches.









Now comes the fun part: drilling the holes and mounting the dipoles.  I got a cordless drill as an early Christmas present; time to put it through its paces!

As per the plans, I drew a line across the board at 2" from one end, then 3 more lines at 5 1/4" intervals (so marks at 2", 7.25", 12.5", and 17.75").  These lines are where the two dipoles in each antenna bay will be placed.




Next, I made two perpendicular marks on each line, 1" apart.  I like things to be even, so I centered the marks, placing them 1.25" from each edge (a 2 x 4 is actually 3.5" wide).  I then drilled pilot holes at each mark for the deck screws.

Here you can see the board with the deck screws already part of the way in.  This makes it easier to place the elements and the connection wire.  I also have two small steel washers on each screw.  The lower holds the dipole element to the board.  The upper will pinch the connection wire between it and the lower washer, providing electrical connectivity.

Next, I added the connection wires between each element. I used insulated wire, and I only stripped those parts of the wire that were going to be in electrical contact with an antenna element.  I've also stripped a place in the center of the antenna to connect the balun.

Here you can see the deck screws where the balun will connect.  Like the other screws, these have washers on them to improve the electrical connection between the wire and the balun.

And this is the antenna with the balun attached.  This is a usable antenna right now, but it's omnidirectional.  Adding a reflector, as recommended in the original plans, will increase the gain of the antenna, but you might want to try this antenna as-is and see how well it works for you. 



I mounted the antenna, sans reflector, in my basement and attached it to my TV.  I'm able to pull in all the stations that TV Fool says are available in my area, including the two analog low-power stations.  But none of those transmitters are more than 30 miles from me, and I don't have any channels from further away.  Once I get the antenna mounted outside, and the reflector attached, I'll report back.

"What news from Plymouth?"

Well, so far as I am aware, Plymouth continues to be in Massachusetts. If this situation should change, I hope one of you, Dear Readers, will be so good as to tell me.

News in my neck of the woods has nothing to do with Plymouth at all. However, if you're stuck on Plymouth, I suggest this brief riveting look at the court of Elizabeth I (Plymouth was an English colony during her reign).

Now, the news of your humble polymath-in-the-making. To begin with, Dear Reader, you might be wondering why the promised posts from NAB never materialized. This is because I did not go to NAB, and I will not be going to the Radio Ink Convergence Conference either. In fact, I have been disqualified altogether from the Technology Apprenticeship Program, and that's because I got a job at KTBG and KMOS, the public broadcasting service of the University of Central Missouri. I'm an engineer! This is a very exciting time for me - so much to learn! Interning at KCUR taught me a bit about radio (though here we have to worry about a thing called "short-spacing" which means we have to have a cardioid antenna pattern - more on that as I learn about it) but I know nothing (yet) about TV.

One of the things I'll be doing at KTBG/KMOS is applying my IT experience and knowledge to our setup in broadcasting. So there will be some software development for various projects in between my regular engineering duties. For example, a short-term project I have is to take the output from KTBG's automation system and feed it into our new Inovonics RDS encoder. The encoder isn't installed yet - maybe John (the chief engineer for KMOS/KTBG) will let me do that too. If this encoder is anything like the unit at KCUR (also an Inovonics) I don't foresee a lot of difficulty; Inovonics uses RS-232 to feed data to the encoder, and the command syntax should be documented in the manual. So it's just a matter of parsing out the data from the automation system and presenting it in the proper format to the RDS encoder. No sweat.

This past Thursday, I made a presentation to the local SBE chapter on IP security. You can view it here, and maybe I'll make a blog post that elaborates on these points a little more.

Today, at the Ararat Hambash, I took the test to upgrade my amateur radio operator's license from General to Extra (I had previously upgraded from Technician to General at the end of March) and passed! This means I now have authorization to operate on all bands and modes available to the Amateur Radio Service (certain bands and modes are reserved for operators with a given license class). Of course, I still don't have any equipment, but that will come in time.

I'm going to the NAB show!

I recently heard about the NAB's Technology Apprenticeship Program. Basically, this is a program for people starting out in broadcast engineering, or people with skills in other technical disciplines - "IT, digital technologies, ... or other related areas", as the website puts it - to get some hands-on experience in the field. Since that's the line of work I'm trying to get into, I applied, and I was accepted! So here's how my next few months are going to go:

April 9 - 14: I'll be flying out to Las Vegas (on NAB's dime, no less) to the NAB show. There are going to be several activities geared specifically for the apprenticeship program participants, (you know what? I'm going to say "apprentices" from now on. "apprenticeship program participants" is a mouthful) and we apprentices will be meeting with leaders in broadcast technology.

May 18 - 19: I'll be flying out to Silicon Valley for the http://www.radioink.com/ Convergence Conference.

June - July: I complete a two month paid internship at a TV or radio station. No idea what station yet.

Finally, in August, I go to DC for a week to work with NAB's Science and Technology Department to develop a presentation to be delivered via webcast at the end of my visit. If I'm permitted, I'll publish a link or something here.

I'm very excited about all of this. Not only is this going to be a really interesting and unique experience, but this is going to be a great start to my broadcast engineering career.

So stay tuned, Dear Reader, for more thrilling tales of broadcast engineering! ;)

Constructing a dummy load

A useful thing to have around is a dummy load. This allows you to tune a new radio (or modifications to an existing radio) without potentially damaging your radio (transmitting without a load connected can damage a transmitter) or causing interference.

Now, I could have bought myself a dummy load for thirty bucks or so. But where's the fun in that? I decided to build one instead, and I found a set of plans for one. Thanks to Ken Kemski, K4EAA for the plans.

To begin with, I went to Westlake Hardware to pick up a 1 qt. paint can and a sheet of aluminum. The original plans recommended brass, but aluminum was cheaper, so I went with that. Little did I know that aluminum is fiendishly difficult to solder with the 60/40 Sn/Pb stuff I have. After I discovered this, I went back to the hardware store and picked up some brass, which turned out to be much nicer to solder.

I then ordered a couple of banana plug posts, 20 3W (Watts)1 k&Omega (1 kΩ = 1000 Ohms); resistors, a 0.01 uF ceramic capacitor, and some BAV21 diodes from Mouser, per K4EAA's part list. For resistors, I went with Vishay metal film resistors. Of the resistors I examined, these had the flattest frequency response curve¹.

So what's the point of all these bits? The can, obviously, is to hold everything. The resistors are to absorb the RF energy and turn it into heat. They'll be submerged in oil (some canola oil that I had laying around) to help dissipate that heat. The brass is to make a couple of plates that hold the resistors. The banana plugs, diodes, and capacitor are all for measuring your transmit power.

So to begin with, let's look at a schematic of this dummy load.

There are 20 1 kΩ resistors in parallel. This provides a total resistance of 50 Ω. As each resistor is rated for 3W of power, these resistors can safely dissipate 60 W of power without becoming damaged. Submerged in oil, they will be able to dissipate at least 100W, I expect, and probably a bit more.

You'll notice two sets of terminals in the schematic. One set has the capacitor between them, and is connected to one of the plates by two diodes. These terminals are meant for measuring the peak voltage (remember that radio frequency (RF) energy is alternating current (AC), and in AC, the voltage is always changing in both magnitude and direction) the connected transmitter puts out. The diodes ensure that only the positive side of the AC comes to the capacitor, and the capacitor charges up to your peak voltage. You can then determine your transmit power from your peak voltage ².

The other set of terminals is where you connect the transmitter. You can use any connector you like for this - K4EAA uses a BNC; I use an SO-239. Next time I might use a BNC, though.

Now that we've got our schematic squared away, let's build the thing. I started out by making the brass plates that I was going to solder the resistors to. K4EAA (you'll notice a lot of hams will refer to each other by call sign, rather than given name. It's a thing.) cut his out with tin snips. That seems like an excellent idea, but I lack tin snips, and I didn't want to shell out for a pair, so I decided to repeatedly bend the metal back and forth until the metal at the bend fatigued and broke. It's not nearly as elegant, and it's not as pretty, but it works. To make the octagon shape (so that the plates would fit in the paint can) I cut off the corners using diagonal wire cutters.

Next, I divided each plate into twenty sections using a Sharpie, and made an "X" near the edge of each section. I was going for a point that was as far as possible from the center of the plate while maintaining maximum separation from its neighboring points. This was fairly inexact, and I'm sure that if I had taken the time to model this mathematically, I could have found a more optimum resistor spacing. But that level of precision is not really called for here - it's a dummy load, and it's meant to absorb RF. If one resistor gets slightly hotter than its neighbors, the oil is going to go a long way towards mitigating that fact.

Now that I had my "X"'s marked, it was time to start poking holes. I did this with a circular (well, tapered cylinder) needle file I had laying around, and it was pretty easy. Just put some pressure on the file and once it's punctured the metal, rotate it a little bit to widen the hole.

Once the holes were poked, it was time to start attaching resistors. And here I may have made a mistake. Figuring that I wanted the maximum spacing between the plates, to allow for maximum heat dissipation, I only put each resistor through its hole a little bit, i.e., I left long leads on the resistors. I figured that since this was a dummy load, any stray reactance wouldn't matter. I may have incorrect in that assumption, as I'll explain later. At any rate, I soldered all twenty resistors to the bottom plate. To maximize conductivity between the resistor lead and plate, I soldered to both the top and bottom of the plate.

K4EAA recommends, when attaching the top plate, that you cut one resistor lead down to your minimum lead length, then cut the rest progressively longer. That way you can insert the leads a few at a time into the top plate. Still operating under the assumption that I wanted maximum spacing between the plates, and feeling like a bit of a mechanical challenge, I decided against that, and instead managed to get all twenty resistors into the holes. It took quite a bit of fiddling. :) After I got all twenty resistors in, I soldered them to the plate, again top and bottom.

I also needed a hole in the top plate for the back of the SO-239 to go into. My original plan was to push the SO-239 through the hole you see here and attach it via the included mounting nut. This did not prove feasible, however, as the banana plugs got in the way. So instead I widened the hole a bit to maintain a space for the center conductor to go through.

Here you see the hole that the center conductor from the SO-239 will connect to.

I wanted the dummy load to be grounded to the chassis - in this case the paint can. It seemed the simplest way to ensure that both the shield of the SO-239 and the black banana post were at the same ground potential. And when I poked holes (again with the needle file and, in the case of the SO-239, my small wire clippers) in the top of the can, the black banana post had an excellent connection to the can lid. The SO-239, however, didn't have as good of a connection, so I sanded away the coating on the bottom of the lid under the hole for the SO-239. That worked much better. The twisted copper wire you see here attached to the shield of the SO-239 ended up connected to the top brass plate. This ensured both a good mechanical connection from the plates to the can, and also a good electrical connection between the top plate and the can (and thus the shield of the SO-239 and the black banana plug).

You'll notice a piece of insulation under the top left bolt in this picture. That's the red banana plug. Just as the black banana plug had a great electrical connection to the paint can lid, so did the red banana plug. So I widened the mounting hole for the red plug, put some bathroom caulk in it to provide a little lateral stability, then took a piece of insulation from some ladder line I had laying around and attached the red plug to that. This ensured that the red plug was electrically isolated from the can.

Here are the banana plugs and the SO-239 attached to the can lid. The white stuff you see is bathroom caulk. Apart from insulating the red banana plug, it serves to fill in any tiny openings where oil might seep through the lid if the dummy load were to be turned on its side or upside down.

Once the banana plugs and the SO-239 were attached to the can lid, the next step was to connect the SO-239 to the plates. I already mentioned the wire connected to the shield. I also needed a wire connected to the center conductor of the SO-239. I had some scrap ladder line laying around, so I stripped part of the conductor from that to for this purpose.

Once I had everything in place on the lid, it was time to mate the lid assembly and the resistor assembly. I bent the shield wire and attached it to the top plate. I attached the center conductor to the bottom plate and made certain it wasn't going to hit the top plate. I then attached the diodes between the red banana jack and the bottom plate.

Finally, it was time to put the lid on the can. I filled up the can with some canola oil I had laying around (I don't cook with canola any more), gently lowered the resistors into the oil, and tapped the lid shut.

Now it was time to measure the performance of my dummy load.

Having borrowed an MFJ-269 from a friend, it was a simple matter to attach it and measure the SWR for various frequency bands. And up through about 30MHz, it was great - nearly 1:1.  And here's the potential mistake I mentioned earlier: what I really wanted this for was 2 meters - 144 - 148 MHz, and there the SWR wasn't so great - between 1.5 and 2 to 1.

Why, you may, ask, did the SWR change as I increased the frequency? It's not as if I'd put any capacitors or inductors in there, just resistors. But a resistor isn't just a resistor. Let's look at a more accurate schematic for the dummy load:

As I said in footnote 1 (you do read the footnotes, don't you?) an actual resistor has some amount of parasitic reactance due to its physical construction. That reactance is made up of both capacitance (as a resistor has two conductive plates separated by some distance) and inductance (due to Lenz's Law). Those values are relatively small³, but they become significant at higher frequencies.

Basically, I had neglected to account for the effects of reactance for 2 meter frequencies.

So what to do? I could shorten the leads. That would reduce, to some degree, the inductance generated by the resistor leads at the cost of increasing the capacitance between the top and bottom plates (because, again, any two conductive plates have some capacitance between them. This might be a good idea, because capacitive reactance is inversely proportional to applied frequency. When I measured the total impedance with the MFJ-269, I got ~23+10j Ω at 146 MHz, and as I increased the frequency, Xs (the reactive part of the impedance) decreased. That indicates that the primary component of the reactance is capacitive. However, the resistive portion of the impedance was 23 Ω Even if I was able to cut the capacitance to zero, I would still have a resistance of 23 Ω when I want 50.

For now, I'm going to stick with the dummy load the way it is. It won't be perfect for tuning a radio on the 2 meter band, but it will do until I can buy or build something better. And if I get some 10 meter gear, this will be perfect.

Here are a few other approaches to building a dummy load:

• Thread on Worldwide DX with a couple of homebrew dummy loads.  "Captain Kilowatt" in that thread makes an excellent point regarding hot air and a potential need for venting.
• UHF Dummy Load by SV1BSX.  He neutralizes the capacitive reactance in his load with an inductor.
• Saltwater Dummy Load by K5LXP.  I'm not sure how well this would work on 2 meters, though, as the electrodes need to remain under a "significant fraction" of a wavelength, but shorter electrodes are going to get hotter faster.

If you've tried any (or all) of these, let me know!

Footnotes

¹ While an ideal resistor has the same resistance no matter what frequency of AC you put through it, real resistors have some amount of parasitic reactance that varies with applied frequency.

² P = V²/R (Power = Voltage² / Resistance). We can measure peak voltage (less an 0.4 V drop from the diodes) across these terminals. If we take the peak voltage, however, that will give us peak power, when what we really want is average power. So we take the voltage - remembering to add the 0.4V drop back in - divide it by the square root of two to obtain RMS (root-mean-square, or average) voltage, square it, and divide it by 50 Ω to obtain power.

The total inductance in the circuit will be smaller still because the total inductance of a number of inductors in parallel is less than the inductance of any one inductor. However, the total capacitance of a number of capacitors in parallel is the sum of all the individual capacitances.

Constructing a programming interface

A little while ago, I was given a pair of EF Johnson UHF mobile radios. These put out 35 Watts of power, which is nice, but like most radios not specifically designed for amateur use (and several that are, as I understand it) you can't set the operating frequency directly from the radio. Instead, one must use a special programming cable to store a number of frequencies (in this case, about 100, in banks of 16) in the radio. And these cables aren't free - aftermarket versions run about $40 a pop. And as my motto with ham stuff has lately been "why buy a thing when you can build it?", I decided to make one of my own.

There are a couple of schematics out there for this cable, all based around a MAX232 IC (integrated circuit). I used one designed by Kyle Yoksh, K0KN.

Basically, what the MAX232 does is convert RS-232 signal voltage levels to TTL signal levels. So a lot of the work has already been done in the IC. All I had to do was solder the IC to a circuit board, attach some capacitors, attach a female DB9, and attach an appropriate connector to interface with the radio.

I was able to obtain all the necessary parts from Electronics Supply Company here in town. I probably paid a little more than I would have if I'd bought from, say, Mouser Electronics, but I like supporting local businesses.

Soldering the entire circuit together was a bit of a learning experience, which I won't recount here as it's extremely boring in the telling. I know that if I built this circuit again, I'd do it slightly differently, but I'm still pleased with the way I did it.

Remember how I said "appropriate connector" above? This whole "appropriate connector" business is easier said than done. It's an 8-pin connector that looks like an RJ45, but it's more narrow. I wasn't able to find one online, so I decided to adapt a bit of Cat 5 that I had laying around instead. This also had the advantage of not requiring me to find a crimper for that weird connector. So, instead of using the Johnson connector, I'm filing down (sloooowly) the RJ45 on the end of the aforementioned Cat 5 stub. Once I've done that, I just need to secure the board and try it out.

For a project box, I decided to use an old Altoids tin that I had laying around. I drilled a hole in it for the Cat 5 stub, but for the DB9, I ended up poking a hole in it with my needle nose pliers and then just working at it with a metal file and clippers for a while. I made the holes for the screws to secure the DB9 to the box using a sheet metal screw I had laying around. A bit of pressure and it poked right through the tin.

OK, now for some pictures. :)

Here's the project board inside the Altoids tin. As you can see, it's really not that complicated of a circuit - a few capacitors, a voltage regulator, and the appropriate connectors on either side, and that's it.

Close-up of the project board.

And this is what the thing will look like once it's finished.

Kansas City Dilettante is now Kansas City Polymath!

Please update your bookmarks to reference http://kcpolymath.blogspot.com/

Changing my name

It occurs to me that "Kansas City Dilettante" does not exactly convey the impression that I want to convey. I originally chose "Dilettante" to reflect the fact that I was interested in a great many things (despite the fact that most of the blog content, lately, has been about radio in one form or another, I am interested in a great many things). But "dilettante" also conveys someone who only toys with things briefly, then moves on. I'm not that person.

I have often said that when I grew up, I wanted to be Benjamin Franklin. I've always admired Franklin's wide range of skills and knowledge. And a word for someone with a wide range of skills and knowledge, like Franklin, is "polymath", and that's something I aspire to be. So, effective as soon as I can figure out how to make Blogger do it, I'm changing the blog's name to "Kansas City Polymath".

Adventures in J-pole construction

So when I said that the J-pole was soldered together, I neglected to mention that the coax - the thing that I connect my radio to - had not been connected to the antenna.

To begin with, I used a borrowed antenna analyzer (a MFJ-259) to find the point on the antenna where I got the lowest SWR. I then marked those points (there's a point on the 3/4 wave section, and a point on the 1/4 wave stub, and in theory they should be at equal height) on the antenna with a Sharpie. Then I screwed a chassis mount SO-239 connector (photo) into the 1/4 wave matching stub, and added some copper wire wrapped around the base of the connector. This was intended to improve the electrical connection between the 1/4 wave stub and the side of the connector that connects to the shield of the coax. I'm not sure it was strictly necessary, though. :)

I had previously soldered a piece of solid core copper wire that I had laying around to the center conductor of the SO-239. After I got the connector screwed into the 1/4 wave stub, I tried soldering the end of the wire to the 3/4 wave section of the antenna at the low SWR point I had previously marked. My soldering iron wouldn't get the copper pipe hot enough for the solder to stick - not surprising, since copper is an excellent conductor of heat - so I ended up using the blowtorch I had used to solder the antenna together to begin with. This worked much better, and when all was said and done, I had an SWR of between 1.1 and 1.2 at 146 MHz.

Today I covered the wire and everything but the threads on the SO-239 with electrical tape to protect them from the elements, and to make sure that nothing could short the matching stub and the 3/4 wave section (apart from the bottom of the "J"). I then (with my upstairs neighbor's permisssion) attached a couple of U-bolts to the railing of the back staircase. They will hold the mast that the j-pole is mounted on to the railing. I might fabricate another mast out of something or other later to get some additional height - I haven't decided yet. I didn't connect any feed line to it, as I don't have a UHF -> F adapter.

Soon, I will have a working outdoor antenna!

The J-pole is soldered together!

Tonight I soldered together the J-pole I mentioned in my last post.

Conditions were less than ideal for this. Not having a garage, and it being awfully cold outside, I had to work in a basement. On the plus side, the basement was relatively warm. On the minus side, it was awfully dirty down there. I kept things as clean as I could, though.

Another less than ideal thing was the flux I used. I purchased a kit from the hardware store that came with a small roll of solder and a small tube of flux. The tube of flux had a thick plastic lid, and I didn't have anything to puncture it with, so I ended up heating up a piece of scrap copper wire and using that to puncture the tube. I only managed this once, however, so the flux came out in a thin ribbon.

But, all problems and less than ideal conditions aside, the j-pole is together! Now all I need to do is find the 75 Ohm match point and I'll be good to go. Now, experienced hams might have noticed that I said 75 Ohms in my last sentence and be a bit confused. After all, most ham equipment is designed for 50 Ohm loads, and you generally want the best impedance match you can get, so as to maximize your power output. But as it happens, I have a bunch of leftover 75 Ohm RG6 that various cable installers have left with me, and I don't want it to go to waste. So I'm going to try and use that as feedline, and try and set something up to match that impedance as best I can. It was suggested in this thread on QRZ that if I make sure my 75 Ohm line is a multiple of 1/2 a wavelength, I can then connect a bit of 50 Ohm line at the radio end. We'll see how that goes. :)

Adventures in ham radio

In my quest to become a broadcast engineer and general polymath, I've started getting into ham radio.¹. I got my Technician-class license in August of last year, and started operating on EchoLink, which provides VoIP connections to other ham operators and those repeaters connected to EchoLink. I made a couple of "Slim Jim"-type antennas, one out of twin-lead, the other out of ladder-line, but didn't actually get a radio until fairly recently.

My current radios are a Midland 13-505 that I bought at the last hamfest, and a pair of EF Johnson 9800 series radios that were given to me by a fellow ham. The Midland radio operates on the 2 meter band, which covers (for hams) 144 - 148 MHz. The Johnson radios operate on the 70 cm band, 420 - 450 MHz.

Neither of these radios is exactly ideal. The Midland is locked (unless I can find or build a synthesizer) to those frequencies for which it has crystals installed. As the Midland dates to the early 1970s, crystals to fit it are fairly rare. The Johnson covers the entire 70 cm band, but requires a special programming cable which I do not currently possess. I have, however, found two sets of plans on the Internet for building such a cable (here and here), so I think that I shall soon have that problem sorted.

As of yet, I have not been able to make a QSL (a contact) with either radio. Several times I have heard traffic on the Midland radio, but I have yet to be heard. I have heard nothing on the Johnson. I'm hoping all that will change soon, though, as I'm building a new antenna. It's another J-Pole (note that the "Slim Jim" is a special case of the J-Pole), but this time, I'm making it out of 1/2" copper tubing.

I used plans by G.E. "Buck" Rogers, K4ABT to get the proper lengths of copper tubing. I went to Westlake Hardware in Westport to buy the tubing, caps, tee, and elbow, and they were kind enough to cut the pipe in the lengths I needed at no charge. I haven't assembled it yet, as I don't know how to solder copper pipe together, but once I have, I plan to mount it on the railing to the stairs at the back of my house. That will give me a reasonable amount of height, especially compared to where I have my antenna now - hanging on the wall above a window in the rear of my house.

That's all for now, Dear Readers. I'll keep you posted (sporadically, of course) on my further adventures in ham radio. And I've still got all manner of things to talk about at KCUR. :)

¹Before you ask, Dear Reader, no, I still haven't learned where the "ham" in "ham radio" comes from. I'm sure it's on the Internet somewhere.

Recently at KCUR

Even though I haven't been posting as much of late, I'm still active at KCUR. Two weeks ago Robin and I installed a fix to the HD transmitter to prevent RF interference from the power supply. I'll note that Robin never mentioned noticing any kind of RF interference coming from the HD transmitter, but it's still a good precautionary measure to take.

This fix involved putting a ferrite choke around an internal power cable¹. The linked article discusses chokes in depth, but basically the point of a choke is to present a high impedance to RF currents. Any such currents that are generated along the cable will either be reflected up the cable or will be absorbed by the ferrite choke and dissipated as a negligible amount of heat. Also, we attached a grounding strap (a braided strip of wire) to the outside of the crossover pipe (rigid coax - where the generated RF signal comes out). Since the outside of the crossover pipe acts as a shield, I think this means that any stray currents on the outside of the pipe will be shorted to ground and won't get outside the transmitter cabinet.

This whole business took something like 15 - 20 minutes. The rest of the day was spent helping Robin out with various things around the station, including installing a T-1 surge protector in the TOC. Last week I did the same thing at the transmitter.

¹ Looking at the manual, the purpose of the cable is "current share", and I'm not sure what that means. If there's the potential for RF interference, I think it must have AC on it.

Setting up a little SMTP server to interface to another

I'd say, "Look, a non-radio post!", but this post is an elaboration of a reply I made to someone on Pubtech, so... :)

By way of background, someone on Pubtech was asking a Nautel rep when their VS Series transmitters would support SMTP servers that require login. I replied that until such a time, you could set up your own little SMTP server and use the server that requires login as a smarthost. Here's how you do it:

Step 1: get yourself a Linux box of some sort. Since this is (presumably) going to live at a transmitter site, and it would sure be nice if you could just "set it and forget it", as it were, I would recommend something like EMAC's Server-in-a-Box (SiB). With the SiB, It's not clear from their website whether or not it an SMTP server included in the Linux distribution it ships with, so contact the manufacturer to make sure. If it doesn't, I'm certain they can install the requisite software.

Step 2: configure the SiB's SMTP server to log in to your other SMTP server. There are a variety of SMTP server software packages out there, and I can't cover them all. I'm going to use Postfix for this example; if you need another example, comment on this post and I'll see what I can do.

This example is based heavily on the example posted here. Whenever you see mail.myserver.com, you should replace it with the host name of the mail server that requires login. Replace myusername with the username to log in to the SMTP server, and myPassword with the password associated with that username.

Create a text file on your server called "/etc/postfix/password". This file should look like so:


# server username:password
mail.myisp.com myusername:myPassword


Now, execute the following commands (note the '#' is used to indicate a command prompt):


# chown root:root /etc/postfix/password
# chmod 0600 /etc/postfix/password
# postmap hash:/etc/postfix/password


Then append the following lines to /etc/postfix/main.cf:


relayhost = mail.myserver.com
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/password
smtp_sasl_security_options =


Finally, restart postfix:


# /etc/init.d/postfix reload


Give the SiB a static IP address (how this is done is outside the scope of this post), connect it to the network, rack it up, and give the Nautel the SiB's IP address for a mail server.

EDIT: The original poster on Pubtech replied that he couldn't have an open SMTP relay floating around. I'm not sure that I'd have my transmitter with a publicly (or semi-publicly) accessible IP, but then again, I'm not sure that I wouldn't. There are benefits and drawbacks to each, but that's a topic for another post. In his situation, I would lock down Postfix to only relay from the Nautel's IP. To do this, add these line to /etc/postfix/main.cf:


mynetworks = 127.0.0.0/8 192.168.1.23
smtpd_client_restrictions = permit_mynetworks, reject


Substitute 192.168.1.23 with the IP of the Nautel, of course. Reload Postfix again when you've added those lines.


And then

Trail of Tears Broadcast Dry Run

Through KCUR, I have been retained to engineer KKFI's broadcast of the Trail of Tears discussion panel at the United Minority Media Association's Midwest/Southeast Regional Conference. As the barnraising was the first time I had engineered any live broadcast, I thought it prudent to do a dry run today. Especially since I was using unfamiliar equipment (a TieLine Commander G1).

Earlier in the week, I collected the equipment from KCUR. Today was the first chance I had to actually set up the equipment. I thought I might need a second pair of hands for this, so I asked my friend Aubry to help. To begin with, we went over to KKFI to hook up the studio unit (the TieLine equipment is a pair of codecs, a studio unit and a field unit) in the studio. This was very straightforward - all we had to do was hook up an analog phone line and run it into the board.

We then went over to the Bruce R. Watkins Cultural Center to set up there. This was a bit more complicated as we weren't exactly sure where the event was going to be held. So we set up in the Great Hall, figuring that to be the most likely place (we later found out that we should have set up in their "broadcast room" at the Cultural Center. ah well.) We connected up the loaner mics from KKFI and I got a feel for how loud they were. Then we found an analog phone line and tried dialing in to the studio unit at KKFI. Unfortunately, while the field unit said we were connected, the studio unit said we weren't, and there was no sound on the board at KKFI. So it was pretty clear that we weren't connected. I went back to KKFI to try and diagnose things there (leaving Aubry to watch the equipment) but had no luck.

To test KKFI's lines, I dialed the TieLine test number with the studio unit. I connected successfully at 21.6 kbps and got some cheery music. I then took the studio unit back over to the Cultural Center and was able to connect there at a slightly faster speed. So KKFI's lines and the Cultural Center's lines both appeared to be good, and yet I wasn't able to get the two units to connect. I called the studio unit from my cell phone, and the unit picked up, so it was certainly answering calls. So I'm a little perplexed, but I have a plan for further testing. The next step is to take both units to KKFI and see if the one unit will connect to the other there (KKFI has multiple analog telephone lines).