I’ve been wanting to try a different aerial for 20m for some time. I currently either use a dipole in the loft, or a temporary SOTAbeams linked dipole on a 7m fibreglass mast. The magnetic loop antenna appeals because it’s compact, and if designed/built for efficiency, gives excellent performance.

They’re also expensive. One well-known UK dealer is selling the Ciro Mazzoni baby loop for £1299; another dealer sells the MFJ-1782X for £439; the Chameleon CHA F-Loop is available from a third dealer for £399. All are far, far outside my budget.

It’s not called amateur radio for nothing, and what I describe in this series of articles is truly amateur. I’m going collate my research sources, and try building a magnetic loop antenna (properly called a small transmitting loop antenna) using bits from my junk box, making good use of the things that I find, things that the everyday folk leave behind. I don’t have all the parts, but whatever I need to buy must not break the bank. Similarly, tools: I’ll need some, but they must be cheap 🙂


Abstract: Oracle is shutting down Kenai and Java.net on April 28, 2017, and as one of the open source projects I’m a member of was formerly hosted there, we needed to move away. This move comprises source code and mailing lists; this post concerns the former, and is a rough note on how I’m migrating svn repositories to git (hosted on github), with the method, and a script that makes it easier.

It’s an ideal time to migrate your subversion repositories to somewhere else, and since git/github are the de facto/fashion standards these days, you may want to consider converting your entire history to git, and hosting it at github. (Disclaimer, I prefer mercurial and bitbucket, and some of the below could be used there too…)

To convert a svn repo to git, and push to github, there are several stages. I did this on OS X – I’d do this on some form of UNIX, but you may get results with Windows too.

I’m going to use svn2git, so let’s get that installed:

Following the installation instructions at https://github.com/nirvdrum/svn2git

I made sure I had ruby, ruby gems, svn, git, and git-svn installed (these package names might not be precise for your system; they’re from memory)
I can do:

$ cd /tmp
$ mkdir foo
$ cd foo
$ git init
$ git svn
git-svn - bidirectional operations between a single Subversion tree and git
usage: git svn [options] [arguments]
… blah blah …


$ sudo gem install svn2git

The conversion from svn to git makes a lot of network access to the svn repo, and so to reduce this, let’s “clone” the svn repo onto the local system.
Mostly following the notes at https://journal.paul.querna.org/articles/2006/09/14/using-svnsync/, first, initialise a local repo:

$ mkdir svnconversion
$ cd svnconversion
$ svnadmin create svnrepo

Note that git’s svn code expects the subversion repo it converts to have a filesystem format version between 1 and 4, that is, up to Subversion 1.6. So if you have a version of the svn client that’s more recent than that, you’ll have to use the command:

$ svnadmin create —compatible-version 1.6 svnrepo

(see http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html for details)

$ ls -l svnrepo
total 16
-rw-r--r-- 1 matt staff 246 1 Sep 22:58 README.txt
drwxr-xr-x 6 matt staff 204 1 Sep 22:58 conf
drwxr-sr-x 15 matt staff 510 1 Sep 22:58 db
-r--r--r-- 1 matt staff 2 1 Sep 22:58 format
drwxr-xr-x 12 matt staff 408 1 Sep 22:58 hooks
drwxr-xr-x 4 matt staff 136 1 Sep 22:58 locks

$ cd svnrepo

Now create the pre-revprop-change hook:

$ echo '#!/bin/sh' > hooks/pre-revprop-change
$ chmod 755 hooks/pre-revprop-change

Let’s prepare to sync the svn repo here:

$ svnsync init file:///tmp/svnconversion/svnrepo https://svn.java.net/svn/name-of-remote-svn-repo

Now let’s do the actual sync. This is what takes the time on large repositories…

$ svnsync --non-interactive sync file:///tmp/svnconversion/svnrepo
# Make tea…

OK, now we have the “clone” of the svn repo, so let’s convert it to git. The first thing you’ll need is an author mapping file. This converts the short author names used in svn commits into the longer “name ” form used by git.

Note there are many possible structures for svn repos, with the ‘standard’ layout having branches/tags/trunk. This page assumes that your svn repo looks like that. If it doesn’t, then see https://github.com/nirvdrum/svn2git where there are many possibilities documented to aid your conversion.

See the svn2git github page for details of how to create this authors.txt file.

Converting to git is as simple as:

$ cd /tmp/svnconversion
$ mkdir gitrepo
$ cd gitrepo
$ svn2git —authors ../authors.txt file:///tmp/svnconversion/svnrepo

Then create a new repository using the GitHub web UI, add it as a remote, and push, mirroring all branches to the remote:

$ git remote add origin https://github.com/your-repo-name.git
$ git push --mirror origin

The following is a script I wrote to make it easier to perform the above steps repeatedly, as I had several repositories to convert. It assumes you have exported the GITORGANISATION environment variable.


usage() {
	echo "svn-to-git-conversion [syncsetup|sync|convert|push] http://url/of/svn/repository local-repo-dir-prefix ~/path/to/authors"
	exit 1

# syncsetup, sync, convert or push

# https://svn.java.net/svn/jxta-c~svn

# prefix of relative folder (eg jxta-c) where repository will be svnsynced to eg jxta-c-svn
# and of relative folder where repository will be converted eg jxta-c-git

# path to author mapping file

if [ "$PHASE" != "syncsetup" -a "$PHASE" != "sync" -a "$PHASE" != "convert" -a "$PHASE" != "push" ]

echo local svn repository url is $SVNREPOFILEURL

if [ "$PHASE" = "syncsetup" ]
	svnadmin create --compatible-version 1.6 $SVNREPONAME
	echo '#!/bin/sh' > $SVNREPONAME/hooks/pre-revprop-change
	chmod 755 $SVNREPONAME/hooks/pre-revprop-change

if [ "$PHASE" = "sync" ]
	svn propdel svn:sync-lock --revprop -r 0 $SVNREPOFILEURL
	svnsync --non-interactive sync $SVNREPOFILEURL
	echo Users in the SVN repository to be added to the $AUTHORS file:
	svn log --quiet $SVNREPOFILEURL | grep -E "r[0-9]+ \| .+ \|" | cut -d'|' -f2 | sed 's/ //g' | sort | uniq
	echo Top-level structure of the SVN repository: 

if [ "$PHASE" = "convert" ]
	svn2git --authors $AUTHORS $SVNREPOFILEURL

if [ "$PHASE" = "push" ]
	git remote add origin https://github.com/$GITORGANISATION/$GITREPONAME.git
	git push --mirror origin

In the previous article, I covered the Arduino controller for the transceiver, and in this one, I was hoping to describe the direct digital synthesis and buffer board – but since I shorted the DDS board, and the buffer wasn’t working quite as I’d hoped, I’ll need to revisit that…. Undeterred, this article focuses on the bandpass filters of the transceiver, and how I’m going to test them.

[See the full list of articles in this series HERE]

In the original circuit, the receiver was fed by a bandpass filter, constructed from two Toko KANK3333R coils. (Note: these are no longer manufactured, but compatible coils are available from Spectrum Communications). The transmitter output led into a low pass filter made from two T50-2 toroidal inductors.

The receiver input is filtered to attenuate strong out-of-band signals that might desensitize the receiver, making it harder to receive the in-band signals. Considering the noisy, unfiltered spectrum around the 20 metre band at M0CUV, shown below, there is a definite need to reject anything loud! The peak at 13.557 MHz is some local QRM.

The transmitter is filtered to attenuate harmonics generated by the VFO/buffer/PA.

In this revised project, since I’m replacing the VFO with a DDS module which generates harmonics – see page 9 of the AD9850 data sheet – there’s an even greater need for output filtering. I mustn’t transmit out-of-band, but also don’t want harmonics appearing in other amateur bands.

To simplify the design a little, rather than having separate receive and transmit filters, I chose to have a single bandpass filter just after the antenna input. This is switched between receive and transmit by opto-isolated relays. Since this is a three-band transceiver, I will also be switching the appropriate filter in, also by opto-isolated relays. The three filters are to be built as swappable boards, so I can explore the whole amateur HF spectrum.

This article doesn’t cover the detail of the filters, or the switching arrangement: it’s about testing the filters, to ensure that their passband covers the amateur band, and that the filter drops off as sharply as possible out of that band.

The approach I’m taking is to generate a broadband noise signal, and inject this into my “spectrum analyser” … Assuming that this shows a nice noisy signal across the band in question, and a little off the ends of the band, I will compare the noise with the filter in- and out-of-line, and adjust the filter to ensure good coverage of the band, and rejection outside it.

Since I can’t justify an expensive spectrum analyser, I’m using a somewhat cheaper solution – an RTL-SDR R820 dongle, preamplifier, and upconverter kit from CosyCave – which cost around £26 if I recall.

The noise source is is connected to the dummy load port of my KP4MD Dummy Load/40 dB Attenuator, and its attenuator port connected to the Preamplifier-Upconverter-Dongle chain.

Note: I was initially thinking of building the switchable attenuator from Hans Summers’ spectrum analyser project, but the 40dB from the KP4MD project was sufficient, cheaper and easier to build.

I read N5ESE’s article on using a noise source in this way, which led to this part of the project.

The noise source is a circuit by Tom N0SS, now sadly SK. His page on the project may be found in his Elecraft Kits page, with build instructions in PDF here. I have a cached copy of this file here.

The circuit of the noise source is shown below:


I built this on good old prototype board, using the rough layout shown below, and mounted it in an Altoids-style tin, with switched 9v battery power and a BNC socket output connector:


Measuring the noise on my old oscilloscope, I saw:

I’m using the excellent RTLSDR-Scanner software on Mac OS X to use the RTL dongle as a poor man’s spectrum analyser. The necessary pyrtlsdr wrapper software needed by it is cloned from its GitHub repository, and for the Python 2.7 I have installed on my OS X Lion system, I had to checkout this commit (if memory serves – I think the authors are trying for mixed Python 2.7/3.0 compatibility, and the HEAD commit isn’t working on 2.7 for me… so, wind back a bit.) This program is cross-platform, so should work well on all platforms, given the right dependency setup.

If you’re using Linux, you may also find Claudio Giuliani’s RTL-SDR Wide Spectrum Analyser project worth investigating.

The noise measured from 1 to 30 MHz (with noise source connected directly to SDR chain, and output level reduced) looks like:

The blue trace is what’s received with the SDR terminated with a 50Ω dummy load; the green is the noise signal.


I’m hoping this will provide a low-cost method of testing filter response.



I’ll either be rebuilding the DDS/Buffer amplifier board, or winding toroidal inductors for the filter construction.

Note: this post was written some time ago, but wasn’t published then – the figures for lines of Java are now: 59416 (main: 31737; test: 27759), 649 tests with 70.1% coverage – the first ‘0.1.0’ release.

One of the tenets of Open Source development is “Release early, release often” (see The Cathedral and the Bazaar); another is “If you build it, they will come” (not sure where this came from – it’s in Field of Dreams…).

I work from slightly different versions of these: Release quality first, then release it often. If you build the code, then you have to build the community, then they come.

I could have created a public repository somewhere (SourceForge? BitBucket? GitHub?) and committed the very first lines of code, allowing developers to keep up with the early progress of the application, but I chose not to. Instead, I’ve spend a year and a half developing on my own, not making the code available. It still isn’t available, nor will it be, until it’s ready. Until it has reached some level of maturity and works as I intend; until it’s sufficiently complete, and until it has ‘quality’ (whatever that is; I’m trying to define it in another post). I’ve seen way too many Open Source projects falter after releasing too early: I want to ensure that the project is viable for myself before I expect others to judge it or use it.

An analogy might help me defend this position: I play guitar and keyboards (occasionally), but I don’t like others listening to me practice. I’d rather perfect my technique and give a performance when I’m good enough. Some players don’t mind others listening to their duff notes and bad timing; I’d rather not inflict that on others.

Likewise, with the code, I think it’s better to let me refactor it into the cleanest, highest-quality, most understandable, tested and testable design that does what it was intended to do first, before letting others loose on it.

Sure, I miss out on early feedback, and now, there’s a lot of code for people to work with and give feedback on (which could be grossly negative, however, I think I’ve got a good design, so that this won’t be the case). The codebase is currently standing at 47,464 lines of Java code in total, that’s 25,207 LOC main code, 22,257 LOC unit/integration test code – 580 tests in all.

However, I’d rather spend the time completing the architecture; I’ve got ideas to express that I need to get down in tests and code – then, I’ll take it all public. I definitely don’t want design by committee at this early stage. I might release a few “technology preview” versions though, if only to get the release mechanism in place – Paul Graham said it best:

In the desktop software business, doing a release is a huge trauma, in which the whole company sweats and strains to push out a single, giant piece of code. Obvious comparisons suggest themselves, both to the process and the resulting product.

— “Hackers and Painters, p62”

He’s talking about the difference between installed software and web-based, server-deployed software, but his point about releases of desktop software is valid: it takes a lot of infrastructure buildup, testing and polish.

One working definition of quality for this project is that the code should be free from internal contradictions (Christopher Alexander, quoted in Richard Gabriel, Patterns of Software, p35, – and having one developer define the architecture helps in this – there’s a single vision; I don’t have to work against several different aspects of the system at once, or mentor others who may be working in different areas (perhaps this is a trust / delegation issue?) thereby allowing me the time to get things to the state I want them in. Fred Brooks’ suggests, for the size of the team and the creative force:

Ten people, seven of them professionals, are at work on the problem, but the system is the product of one mind – or at most two, acting uno animo.

(The Mythical Man-Month, 20th Anniversary Ed, p35)

A view against my stance was recently posted by chromatic in his excellent “Modern Perl Books” blog:

I’ve written before that rapid, feedback-aware iteration is an effective way to understand a problem and find working solutions. Feedback from real users with real uses is invaluable (see also why Pugs and, later, Rakudo multiplied the velocity of Perl 6). You won’t understand the problem fully until you’ve had to balance multiple, sometimes contradictory, constraints. Just as no battle plan survives contact with the enemy, no software design survives contact with users unscathed. You may find that you’re painting yourself into a corner.
There’s a balance: you don’t want to cause users unnecessary pain by rapid, arbitrary change, but legacy code and features can hamstring a project.

– from Designing for the Unanticipated

So I could be “painting myself into a corner” by not releasing until it’s ready. However, perhaps even with the amount of code I have already, it’s still to early to release – it doesn’t do what it’s intended to do, yet.

Once I cut that first release, then I’ll release often. I prefer “Release quality, release often”. Then I’ll see whether they’ll come after something usable’s built.

After almost 2 years of development work, I have decided to release my Java-based OSS database app framework “early” – it’s going to be very alpha for a while. I was hoping to continue polishing it until “done” – but that could take some time.

I’ll be having a regular release schedule – and have decided on the following dates for the forthcoming releases:

  • Spring Equinox – March 20th
  • Beltane – April 30th
  • Midsummer – June 21st
  • Lughnasadh / Lammas – August 1st
  • Autumn Equinox – September 20th
  • Samhain (Halloween) – October 31st
  • Yule / Winter Solstice – December 20th
  • Imbolc – February 1st

They’re the dates of Pagan festivals, in case you were wondering.

The website for this project, and several other larger ones is DevZendo.org, which I’ll be livening up a little over the course of the month leading to Release 0.1.

There are pages to write, mailing lists to set up, copyleft headers to strew hither and yon, BitBucket repositories to populate.

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

Actually this isn’t my first post – just moved all my earlier posts over from a custom installation of WordPress since my hosting provider was unable to provide a satisfactory level of service. No ssh access to the server would have left the installation unupgradable, thankfully WordPress has a great import/export facility.

Do not be disturbed. I got so tired of cretins trying to advertise their dross on my blog, I had to do something…

Next Page »