Skip to content

Getting on HF – Antenna Tuner Design

I recently upgraded my amateur radio license to a General class last month but have yet to get on HF making DX contacts yet. I’m starting from the ground up for HF given that all I currently have is an Icom 706 MK-II G radio and it isn’t even setup at the moment, I decided to go cheap and try to homebrew all the needed parts to get on the air. I have built a basic 20 meter dipole antenna but I have always really wanted an antenna tuner. Plus, the 706 has a max output power of 100W, so I want to get as much forward power into the air as possible.

I reviewed a bunch of designs on the internet and really liked the design by VK5AKL:

I have started modeling my tuner in 3d space for component placement and internal design and I have created the front and back panel designs in adobe illustrator.

Here are some 2d renders of the model I have created in google sketchup:

Posted in Amateur Radio, Design, Tech.

Tagged with , , , , , .


So its been like 3 years since I’ve written on this blog. Its time for a reboot. I have a bunch of technical personal projects in the queue and I think its time to start writing again. I think I will also be making some videos to go along with my posts for most of my projects and turn this into more of technical video blog. We’ll see. :)

Posted in Uncategorized.

Using $LOAD_PATH for better library loading in ruby

Today I discovered the beauty of $LOAD_PATH in ruby.

Here is the problem:

I created a couple of libraries for an app I’m working on and put them in a ./lib directory and they reference each other like this:

require ‘lib-b’
…lib does stuff with classes included in lib-b…

require ‘lib-a’
…lib does stuff with classes included in lib-a…

require ‘./lib/lib-a’
…use lib-a which tries using lib-b…

Well when I’m in the top-level directory and try including one of the libraries it won’t work because lib-a.rb will look for lib-b.rb in the current directory and it doesn’t know to look in ./lib

If I change lib-a.rb to call require ‘./lib/lib-b’ it will work from the main script because it knows how to get to lib-b from the top level directory.

The real problem is that the application is bound by that top level directory now. If I try to make a test in ./tests/test.rb like this:

require ‘../lib/lib-a.rb’

The problem is that lib-a is looking for lib-b in ./tests/lib/ because of the ./lib reference….

The basic problem here is that, even though we are using relative paths, the paths are like absolute paths relative to the current directory. We need to avoid such relative paths as much as absolute paths in our code. How do we do this?

The solution:

The ruby require uses the global variable $LOAD_PATH to figure out where to look for libraries. $LOAD_PATH is an array of directories that you can add to to get your libraries loaded properly without any directory spec in the require statement. Here is an example:

require ‘lib-b’

require ‘lib-a’

$LOAD_PATH << ‘./lib’
require ‘lib-a’

$LOAD_PATH << ‘../lib’
require ‘lib-a’

This will set up the load path to be passed to everything properly so that ruby can just work its magic.

Posted in General, Tech.

rsync saves me again

Thank you rsync for saving my ass again.

I have an Apple Mac G5 that I use for running my DAW’s and music production. About a year ago I reinstalled the OS from scratch and set the partition type as Case-Sensitive. At the time I thought that was clever because I work in linux all day and linux is case-sensitive. Wow was that a mistake. It is amazing how much case-sensitivity causes headaches on a daily basis. Adobe Photoshop (and most other adobe products) will not install. They require case-insenstive operating systems… (case-insensitive is the default for OSX). Protools, although doesn’t require it, doesn’t seem to work correctly under a case-sensitive OS. Even iTunes has it’s share of issues. Which is where rsync saved the day for me.

In my iTunes library I ended up with a bunch of files that named the same, some with capital letters and some without.  For example, I have a two files in a directory named: “Coheed and Cambria – Welcome Home” and “coheed and cambria – Welcome Home”. How it got like that I will never know but it really made things tough.

Last week I bought a 1TB SATA drive from Fry’s and installed it in the G5. I then moved all my project files and audio files and everything important off of the main hard drive to the new one, which I of coarse formatted as case-insensitive preparing for a fresh install of OSX. Well, when I dropped the iTunes folder on the new drive it started copying only to error when it hit the Coheed directory. Because in a case-sensitive environment there were two Welcome Home files (one with capitals and one without) and in a case-insensitive env they are the same file. Needless to say the finder copy failed and I would have had to wade through 19GB of music to find where this happens and clean it up to move everything over.

Welcome rsync to save the day. I opened up my good ‘ol terminal and popped off an rsync instead:

rsync -av –inplace /Users/heijmans/Music/iTunes /Volumes/MusicDrive/

rsync is able to overwrite the files without caring and TADA! all fixed! :) Thank you rsync for being so awesome.

Command expaination:

-av –inplace means:

a = archive: copy over everything. (there is more to it but you will need to go read the manual)

v = verbose: show me what you are doing

–inplace = inplace: don’t copy over to a temp file and then compare the source and dest. Just overwrite the dest file inplace. This is handy if you are running an rsync for the first time and there is nothing to compare. It speeds it up a bit.

Posted in General.

Write tests and save time

I never could understand why developers didn’t write tests. The concept of a test is simple. You write a little extra code now that tests the outcome you want or have so that, in the future, when you add a feature or decide to refactor into something simpler or better, you know that you didn’t break anything without having to walk through all the test cases by hand.

There are two approaches to writing tests and one of them is more conducive to test writing then the other.

The first way is to write your application code first then write the tests to back it up. The first problem with this is a matter of motivation really. After writing all the application code and making it work, I find it very hard to motivate myself to write the little extra bit of tests instead of diving right in to the new feature on the roadmap. Why write the tests after you know it works? Well, again, what if you have to wedge a feature in there or refactor? Then you have to recall all the stuff that you tested by hand while you were building it and then test it again, by hand, or write tests at that point and Murphy’s law says that you will forget at least one critical case the second time around.  That is why the second choice is the better.

The second way to develop with tests is to write the tests for the functionality that you want and then write the code to make the tests pass. This is the Agile approach and, in my opinion, the better. Why? Well, you are writing tests based on requirements. So you will know as soon as your code does what you want. Second, you are writing tests based on what you are encountering while writing the application. This lends itself to more coverage because you will be writing tests for all the little edge cases you will encounter while writing the application. This means that, in the future, when you refactor or go muddling around, you can verify, RIGHT THEN, if you broke anything.

I have heard managers complain about developers spending time on tests and not on features first because users and clients won’t see the tests and time should be spent on user/client features. Well, here is the reality, a little time spent at the beginning of a project writing tests saves a lot of time in the end because you don’t need to spend so much time verifying feature requirements while writing. Plus the QA process is much faster and smoother because you are handing of working code from the beginning. Writing tests at the beginning usually saves me more than 10% time on the same project where I write the application code only with no tests! That is 10% faster to release and ensures better user experience in the long run because I verified that the project is doing what it should and handling errors properly before I even wrote the application!

Posted in Rails, Tech, Web.