Uncategorized


It’s fun to take a minimum of equipment out to a high place, lob a half-wave long wire antenna up into a tree, or support it with a fibreglass pole, and off you go – but such a long wire typically has a high (2.5kΩ to 3kΩ) impedance. To make it work, this needs transforming down to match the 50Ω output of a typical transceiver. This is done using a 49:1 autotransformer, built on a small toroid.

This post details my construction of the end-fed half-wave autotransformer and antenna for the 10m, 20m and 40m bands.

The antenna is very effective, can be erected in a variety of ways, exhibits low noise, doesn’t cause any RFI in the shack (use a choke balun in addition), places the feedpoint very near to your transceiver and it’s pretty easy to build.

Acknowledgements

There are many other articles out there on this subject:

There are also several other pictures of builds I’ve used to assist in this project, particularly from Ian MW0IAN and Michael G0POT. Thanks!

Introduction

I hope to add some detail and pictures for the terrified constructor in this article, but the above are my source materials. This antenna and its autotransformer are a great project for those new to construction – the toroid winding isn’t hard.

One problem I find in many projects is that they go from diagram to finished construction very quickly with insufficient detail. It’s a bit like “How to Draw an Owl”….

How To Draw An Owl

So I wanted to document what I’d done, in the hope it might be useful to others, especially if you’ve not wound toroids before. The key point is that the count of ‘turns’ relates to the number of times the wire goes through the inside of the toroid.

Parts and materials

I’m building this autotransformer on a FT-140-43 toroid, purchased as a pack of two on eBay from Spectrum Communications, for £9.50 incl P&P.

I first wrapped this in plumber’s PTFE joint sealing tape.

I’m using Maplin 0.9mm 20SWG enamelled copper wire, code YN82D. £8.49 for a small reel (the picture on their page is misleading; it’s not as small as indicated). The source articles used 1.0mm wire; this will allow higher power to be transmitted – I’m mostly QRP, and without calculating it, 0.9mm will be fine for this.

For connectors, I’m using a BNC socket, £2.49 for Maplin’s code HH18U, and a small terminal post, again £2.49 for Maplin’s code FD69A. A small black plastic box, for £3.39 code KC91Y houses the completed autotransformer. This box is a bit ‘tight’, but it does all fit. You’ll also need a 100pF 3kV ceramic capacitor, available for £0.131 each (min order, pack of 10) from RS Components.

Building the Autotransformer

Wire lengths for the toroid winding given here come from reading other articles which describe builds on the larger FT-240-43 toroid. After I’d wound on the smaller toroid as shown here, I had some waste wire that required trimming – you could start with shorter pieces of wire, and I’ve estimated possible lengths for this [in square brackets]. However please note I haven’t tested those lengths.

Measure two lengths of wire, 1.0m, and 22cm. [For the FT-140-43 toroid, and a small box as given above, you could probably use lengths of 80cm and 18cm.] Strip the enamel from the ends for about 2-3mm, clean with sandpaper and tin with solder. Solder the two right-hand ends together.

Solder the right-hand ends together

Holding the soldered end in pliers, twist the two lengths tightly together for 13cm [for the FT-140-43, 9cm may suffice], to form the bifilar winding. ‘Bifilar’ meaning ‘two filaments’, I presume. The remaining length of the shorter piece of wire (at the end of the bifilar winding) being about 6-7cm long. Let’s call this length ‘the tail’.

Now to wind the bifilar part onto the toroid.

Pass the bifilar part through the toroid from the back, so that the ‘tail’ passes under the bottom edge, and the start of the bifilar part is entirely running through the inner of the toroid.

Starting the Windings

Wind the bifilar part back round the top and outer edge of the toroid, and back through the hole. Bend it again over the top. You should have two bifilar passes through the toroid. The end of the bifilar winding (that’s the soldered-together end) will be connected to the outer/shield/chassis connector of the BNC socket. The end of the tail will be connected to the inner/centre connector of the BNC. I’ll get back to the connections later.

The Bifilar Winding

Now, there’s the rest of the toroid to wind.

Wind the long single strand of wire through the toroid so that you have six passes on the inside.

The first part of the rest of the winding

Then pass the wire over the top, and over to the other side, going under the far edge. Loop over the top, and go back through the toroid so that on the far side, you have seven passes, with the remaining end (‘the antenna end’) going under and out.

Ensure that the windings are spaced as evenly as you can.

The final winding

Now tin the connections of the BNC socket and terminal post, and fit them in the box.

Carefully trim the three wires coming from the toroid to fit; scrape off enamel (might need to unwind the end of the bifilar winding a couple of mm to do this properly), clean and tin the ends.

The toroid, trimmed, with box

Solder the bifilar winding to the outer of the BNC; the ‘tail’ at the end of the bifilar winding to the centre pin of the BNC; the ‘antenna end’ to the terminal post.

Solder a 100pF 3kV ceramic capacitor between outer and centre connections of the BNC. Use a hot glue gun to fix the toroid to the inside of the box (not shown).

The assembled autotransformer

Put the top on the box, and there you have it.

The completed autotransformer

Building the antenna

There’s a long antenna wire attached to the autotransformer terminal post, followed by a coil and a further bit of wire. I used fairly rugged plastic-insulated wire; the outer diameter is 2mm, bought years ago on a 100m reel, probably from Maplin.

-----+                                                           
auto |         Length L1           Coil in uH    Length L2  (fibre-
xfor-|=----------------------------|\\\\\\\\\|------------|  glass
mer  |                                                    |   pole)
-----+                                                    |

For 80m+40m+20m+15m+10m, L1 is 20.35m, the coil impedance is 110μH, and L2 is 2.39m.

For 40m+20m+10m, L1 is 10.1m, the coil is 34μH, and L2 is 1.85m. I built this variant.

These lengths are taken from the diagrams in the PD7MAA article. Also see PA3FRP’s notes.

I had a length of plastic tube with an outer diameter of 15mm; I wound 141 turns of the Maplin 0.9mm 20SWG copper wire on this, and measured 34μH. This was very much a trial and error exercise; I had no idea how many turns it would take, so the initial length was extended by soldering more on, several times.

Testing

I attached the far end of the wire to the top of my 7m SOTABeams fibreglass pole, and fed the wire out so that the autotransformer was on the ground – imagine a right-angled triangle with a bowed hypotenuse; I also lifted the autotransformer up onto a small table.

Measurements with an antenna analyser show very favourable SWR readings for the three bands I’m interested in:

  • At 7.305MHz, SWR is 1.21:1
  • At 14.318MHz, SWR is 1.14:1
  • At 27.780MHz, SWR is 1.15:1

With a bit of adjustment, and appropriate positioning – it does seem sensitive to its location above ground (this is explained in the test article by John Huggins) – I think it’d be fine to transmit into this. I’d ideally like to tune it a little more, so I can use it on the exact frequencies I frequent without an ATU.

Advertisements

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 🙂

(more…)

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 …

So,

$ 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.

#!/bin/bash


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

PHASE="$1"
# syncsetup, sync, convert or push

SVNURL="$2"
# https://svn.java.net/svn/jxta-c~svn

LOCALREPODIRPREFIX="$3"
SVNREPONAME=${LOCALREPODIRPREFIX}-svn
GITREPONAME=${LOCALREPODIRPREFIX}-git
# 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

AUTHORS="$4"
# path to author mapping file

if [ "$PHASE" != "syncsetup" -a "$PHASE" != "sync" -a "$PHASE" != "convert" -a "$PHASE" != "push" ]
then
	usage
	exit
fi

SVNREPOFILEURL="file://`pwd`/$SVNREPONAME"
echo local svn repository url is $SVNREPOFILEURL

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

if [ "$PHASE" = "sync" ]
then
	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: 
	svn ls $SVNREPOFILEURL
fi

if [ "$PHASE" = "convert" ]
then
	mkdir $GITREPONAME
	cd $GITREPONAME
	svn2git --authors $AUTHORS $SVNREPOFILEURL
fi

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

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:

Construction

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:

Testing

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.

Conclusion

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

Acknowledgements

Next…

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.

Next Page »