In the previous article, I described the features I want in this transceiver, and sketched out some ideas of how its user interface might accomodate these features. In this article, I start the construction.

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

The transceiver is powered from a single 12 (13.8)v source, such as a sealed lead-acid battery, bank of rechargeable cells or power supply. Protection is provided to prevent swapping the input leads, then the power is smoothed and converted into additional 9v and 5v supplies. Several connectors are provided for the various modules that comprise the complete system.

The original Easibuild’s power supply was a little simpler, with 12v being protected by fuse and ‘idiot diode’, and a little smoothing. 5v regulation was only needed by the VFO/buffer, and so was done in that unit. The receiver also converts the 12v into 8v for the NE612 mixer – I’ve retained this scheme.

In this revised power supply, I’ve added 7809 and 7805 regulation with smoothing electrolytics, and changed the idiot diode to a transient voltage suppressor. The use of transient suppression diodes, and idiot diodes generally was covered in an article in Practical Wireless, June 2015, by the Rev. George Dobbs G3RJV. Joe N2CX also has a useful article at his blog in which he recommends using a transient suppressor diode. For more on why series idiot diodes are a bad idea, see this article.

Input to the transceiver is via a Kobiconn 163-4304 power jack, available from Mouser, but Maplin’s JK09K, or Proto-pic’s PPADA610 are suitable. The matching plug for this is a Mouser 1710-2131, or Maplin HH60Q. The positive power then passes through a 1A fuse, in a 5x20mm Schurter fuse holder, and then to the switch on the volume potentiometer. From there it – and the negative from the input socket – are connected to the 12v connection on the power board.

The output power connections are 4-pin 2.54mm pin headers, which I’m using throughout the project for various interconnections.


The schematic for the supply is shown below (click diagram for a larger version):


I’m using prototype board for many of the modules in this project, for no other reason that it’s really cheap. I bought 20pcs of the board below from an Amazon seller in China, called Hielec, for £3.30.

This prototype board is a little thinner than the Veroboard I’m used to, and the solder pads are not perfectly aligned with the holes, but it’s good enough. There are 18×24 holes per board.

The board layout I used is shown below (click diagram for a larger version):

This is the view from the component side; I mirrored the above bitmap horizontally in GIMP and printed it to ensure I got the wiring on the underside right.

It could be smaller: the layout leaves some space around the voltage regulators, so that any heat they generate is away from the nearby smoothing capacitors. Don’t want them drying out! The transient voltage suppressor is quite large, so needs the space allocated. The capacitors are around 6mm diameter. All wiring on the bottom of the board used 1/0.6mm wire, stripped as necessary. Although the circuit only takes up a few columns of a prototype board, I haven’t cut it down yet: I might need some extra board space for patching/fixups later.

Parts list

All parts were obtained from Amazon sellers, Mouser electronics, RS components, Hobbytronics, CPC, or Maplin. Some I had anyway. For detail on cost as of mid-2015, vendor website URLs of each component and where I obtained it, see the Excel parts list spreadsheet [Excel 2011 For Mac .xlsx format].

Part Value
12V_IN 2-pin male 2.54mm header
12V_IN_PLUG 2-pin female 2.54mm plug
D1 1.5KE18A transient voltage suppressor
C1, C2, C3 10μF 50V electrolytic
IC1 LM7805
IC2 LM7809
PWR1-6 4-pin male 2.54mm header
… not shown on this schematic; part of the case/front panel …
VR1 100kΩ log pot & switch
J1 Power socket; Kobiconn 163-4304
F1 1A 5x20mm fuse
FH1 5x20mm Schurter fuse holder


I assembled the board, checked for shorts with a magnifying glass, checked continuity of the main traces to the output pin header cluster, then wired it into my prototype breadboard, connecting the power jack, fuse, and on/off switch. Applying power from a pack of 10 1.2v Ni-Mh rechargeable AA cells, I measured voltages in the correct ranges on all of the pin headers.


This board is general-purpose, and I expect to reuse it for future Arduino Micro-based amateur projects.
In the next article, I’ll describe the Arduino digital control board….


In the previous article, I gave an overview of the transceiver design and construction approach. In this article, I’ll consider the features I want to offer from a user/operator perspective, and how these might be achieved.

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

The controls of the transceiver are minimal: straight key or paddle, single rotary encoder with button, volume and on/off control, and a 16×2 LCD. I initially wanted to add a couple of other buttons to give a fancier user interface, but did not have the digital input pins available – I could extend the Arduino Micro, or use a more powerful Arduino model such as the Mega, but this would increase the cost, and anyway, minimalism and constraints often foster creativity – so, how can I offer a simple set of controls with a system that’s less expressive than early click-wheel iPods?

I am not using the key or paddle for the user interface, that’s just for transmit / keyer control.

I have the following features in mind:
Three main modes of control:

  • Normal operating mode, showing the current band/frequency. (e.g. 14.060.00) The rotary encoder allows the user to tune up/down the band, within the limits set for the band (according to your country’s allocation). One of the digits of the frequency display is underlined. This digit is increased/decreased when tuning. Tap the rotary encoder quickly to change the underline to the next digit, to allow fast tuning. (e.g. 14.060.00, 14.060.00, 14.060.00, 14.060.00, 14.060.00, then back to 14.060.00) If the underline is under the MHz (14.060.00), then the rotary encoder will switch between the configured bands. Operating the key/paddle will switch to transmit, and key the PA directly if a straight key is configured, or cause the keyer to generate the appropriate automatic keying if a paddle is configured. After the last keying signal, and the chosen break-in delay time has passed, the transceiver will switch back to receive.
  • Immediate menu, allowing access to a menu to configure the settings most likely to be used when operating. Press the rotary encoder for 0.5sec to switch to this menu, and again for 0.5sec to return to operating. The menu shows the name of a setting, and its current value. The rotary encoder allows you to scroll through the names of all the settings, showing their value. Tap the button to allow you to change the setting by scrolling through the range of possible values. Tap the button again to set the value, or hold for 0.5sec to cancel changing the value and return to operating mode. After tapping the button, you can continue to scroll through the names of the settings, or hold for 0.5sec to return to operating. This sounds more complex to describe than it actually is – there will be a > symbol next to the name or value that you are changing so show you whether you are choosing a setting, or changing it.
  • Setup menu, same as the immediate menu, but hold button for 2sec to enter this menu. Contains settings you’re likely to change less frequently.

For inspiration on the ranges of the various settings, I’ve used the same ranges I find on my Yaesu FT-857D.
The available features are (I => Immediate menu; S => Setup menu):

  • Bandpass filter 1 (S): from { RECEIVE, 160m/1.8MHz, 80m/3.5MHz, 60m/5MHz, 40m/7MHz, 30m/10MHz, 20m/14MHz, 17m/18MHz, 15m/21MHz, 12m/24MHz, 10m/28MHz } – this tells the transceiver which filters you have installed, in which socket, so the appropriate one is enabled when you switch band. RECEIVE is general HF coverage, possibly a ‘straight through’ with no filter components, with transmit disabled.
  • Bandpass filter 2 (S): as for 1
  • Bandpass filter 3 (S): as for 1
  • CW delay (S) from FULL, 0.03-3.0 seconds. This is the delay after the last keying signal that the transceiver will stay in transmit mode for, before switching back to receive.
  • CW filter frequency (S) from 400-800Hz – this is set to the fixed frequency chosen for the Hi-Per-Mite filter’s passband, and is used as the receive offset frequency. When operating, the display shows the frequency you are transmitting on, but the receiver will actually be tuned to the TX frequency +/- this CW filter frequency. It’ll be TX+ on bands > 10MHz, and TX- on bands <= 10MHz, as per convention. You don't need to do anything to switch between +/-. (Not sure what I can do about reducing confusion of listening to an image on the opposite sideband…)
  • CW input (S): straight key/single padddle/iambic A/iambic B (I have no idea about iambic modes, double paddles: I’m a straight/single paddle guy!)
  • CW Farnsworth speed (S): from 4-60wpm
  • CW keyer speed (S) from 4-60wpm. (Dit/Dah ratio is fixed: I see no need to change from the standard.)
  • CW paddle reversal (S): normal/reversed
  • Frequency lock (I): on/off (since you’ll be using the rotary encoder’s button to enter menus, change settings, etc., you may want to lock the TX/RX frequency.) Lock status will be shown on the screen when operating.
  • Macro 1 edit (S): use rotary encoder and button to edit text. Current character is underlined. Button to change it; button again to return to character choice. Choice of typical CW characters and prosigns {A-Z, 0-9, ‘.’, ‘,’, ‘+’, ‘?’, ‘/’, ‘=’, AR, AS, BT, HH, KA, KN, NR, SK, VE, ENDOFMACRO/DEL/INS}… not really sure how I’ll edit macros with only one button and a dial…I need to research 80’s video game high score table editing…
  • Macro 2 edit (S): as for 1
  • Macro 3 edit (S): as for 1
  • Macro 4 edit (S): as for 1
  • Macro 5 edit (S): as for 1
  • Macro 1 send (I): keys the text of macro 1
  • Macro 2 send (I): keys the text of macro 2
  • Macro 3 send (I): keys the text of macro 3
  • Macro 4 send (I): keys the text of macro 4
  • Macro 5 send (I): keys the text of macro 5
  • Receiver Incremental Tuning (RIT) (I): from -9.99kHz to -9.99kHz that’s added to the receive frequency (in addition to the CW filter frequency above), relative to your transmit frequency. Any nonzero RIT frequency will be shown in operating mode.
  • Reset (S): reset to default settings, with confirmation
  • Sidetone pitch (S) from 400-800Hz
  • Sidetone volume (S) from 1-10
  • Tune (I): transmit continuously until rotary encoder button pressed, for adjusting an antenna matcher (don’t overstress your PA!) – with a 20 sec timeout?
  • Version (S) shows the firmware version
  • In the menus, the key/paddle and transmit is disabled (except when setting the speed and sidetone pitch/volume, when keying will generate a sidetone and mute the receiver, with no transmit.)

    A tall order, given the limited facilities of the Arduino. I’ll have to recall all the space-saving techniques I used back in the 80s as an assembler programmer!

    In the next article, I start on the construction, one module at a time.

Some interesting features of cifs-utils in CentOS 7 that make mounting Windows shares harder than I’d like, that need documenting next time I (or you) run into them…. I had to read the source for mount.cifs to uncover this, and examine the entrails of mount.cifs with strace… so hope this helps….

The actual problem I’m having is that I’m trying to mount CIFS shares as non-root users: this appears to be impossible very hard in CentOS 7, but worked fine was really easy in earlier versions. Along the way to discovering this, I found many suboptimalities that I thought might be useful to fellow travellers….

You can add an entry to /etc/fstab for the default settings for the mount point, or, specify them on the command line. It’s not mandatory.

Normally you’d need to give the username, password, and (windows) domain to the mount command, and these are delegated to mount.cifs. However, supplying the password on the command line is not wise from a security perspective, since it’ll be visible via ps. So, you can store the credentials in a file, with appropriate permissions, then give this to mount.cifs. Except that it doesn’t quite work as I expected….

With the credentials.txt file containing:

(Note, I’ve seen some posts suggesting that the windows domain be prepended to the username as above, and as I’ll show below, this causes problems…)

I used the command:

mount -t cifs //SERVER/SHARE /mount/point -v -o credentials.txt,uid=1002,gid=1002

With appropriate Linux UID/GID that should be the owner of the files thusly mounted. (this is my ‘backupuser’ user) It didn’t work. The first problem was the error:

Credential formatted incorrectly: (null)

… which is code for ‘you have a blank line in your credentials.txt file’. Removing the blank lines, I then got:

mount error(13): Permission denied

I checked permissions on the credentials.txt (0440), the mount point, etc., etc… no, it’s not that. It’s parsing the credentials.txt, and seems to not get the username from it.. if you give it a gentle hint with:

mount -t cifs //SERVER/SHARE /mount/point -v -o credentials.txt,uid=1002,gid=1002,username=windowsusername

It works!

Now, if your credentials.txt has the username without the domain, like:


You do not need to give the username when calling mount, so this works:
mount -t cifs //SERVER/SHARE /mount/point -v -o credentials.txt,uid=1002,gid=1002

So, the rules for credentials files are:

  • No blank lines
  • Don’t add the domain to the username

But as for enabling non-root/suid/user mounts of CIFS shares… setting the suid bit (chmod u+s /sbin/mount.cifs), adding ‘user’ to an /etc/fstab entry, and running it gives the very helpful “mount error(22): invalid argument”. I’ve tried everything I can think of, but it just appears to be something that is no longer possible in CentOS 7.

To get this working requires adding an entry to the /etc/sudoers, like this:

backupuser ALL=NOPASSWD: /sbin/mount.cifs *, /bin/mount *, /bin/umount

Then mounting using sudo mount…. not happy about having to jump through these hoops, but there you go…

The full list of articles I’ve written on the EasiBuild Mk 2 are:

Previously I described the original project, and how I’m hoping to improve on it.

In this article, I’ll present an overview of the transceiver from a high level.

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

My aim is to build a useful QRP CW multiband transceiver, with a simple user interface, that can be built from a well-stocked parts store, or obtained from current component sellers at a reasonable cost. It should be buildable by relatively inexperienced constructors – like the original, it is possibly too hard for a beginner, but I’ll try to provide explanations for everything, from the theory of operation to the construction.

The block diagram of the transceiver is shown below (click diagram for larger version):

The receiver is a direct conversion circuit, as a superheterodyne would be too complex. It’s CW, because CW is awesome 🙂

It also makes for an easy design that doesn’t require complex setup/test/alignment.
Rather than using a capacitor-tuned variable frequency oscillator as in the original single-band transceiver, I’ve opted to use one of the cheap AD9850 direct digital synthesis modules available from eBay at low cost. The module I’m using is shown below:

This needs to be driven by a microcontroller, and I’ve chosen the Arduino Micro, as I’ve used it before, it has just enough I/O/Timer capability, is readily available and it’s small. I want the transceiver to be compact, but not built directly from surface-mount components: it should be constructable by those with not-so-perfect eyesight! The only surface-mount work is in pre-assembled boards (Arduino, DDS, LCD).

To control the transceiver, I’ll display the current frequency on a cheap 16×2 LCD display, and allow tuning and other control with a rotary encoder plus single button. I’ll have more to say on the Arduino / control / user interface in the next article.

I’ll add receiver incremental tuning (RIT) by providing a changeable offset when receiving, and sidetone generation when transmitting as an audio output from the Arduino.

In the original circuit, a bandpass filter (built from hard-to-obtain TOKO coils; now available as Spectrum coils from Spectrum Communications) was used before the mixer to filter out strong out-of-band/broadcast signals, with a separate low-pass filter (built from readily-available T50 toroids) after the transmitter power amplifier to reduce harmonics, restricting transmission to the amateur 80m band. In this version, rather than switching pairs of different bandpass and low-pass filters into the receive and transmit circuits, I’m using the same bandpass filter for transmit and receive, switching the selected filter in just before the aerial.

The bandpass filters (constructed with T50 toroids) are pluggable via SIL headers – there are three slots for filters, and you can swap in new ones. The transceiver needs to know which filter is installed, configuring this via the setup menu so that the appropriate relays can be switched in when the bands are changed. I chose three bands; you could build for fewer – or more if you use the three band-select digital output wires to drive a shift register.

The filtered input signal, plus the buffered DDS oscillator frequency is presented to the receiver’s NE612 mixer, with audio output being filtered by a narrow-band audio filter (the Hi-Per-Mite filter, with changes to select my preferred CW audio frequency), then passed to an audio amplifier. The receiver and audio filter are only powered during receive.

In the original project, switching between transmit and receive was achieved manually with a switch. This revision controls transmit/receive switching, keying, and break-in with the Arduino. In transmit mode (as controlled by the Arduino when the key/paddle is used) the receiver is off, and the Arduino’s sidetone output goes to the audio amplifier. When switching to transmit mode, the RX/TX relay switches the selected bandpass filter and aerial to the transmitter. At the same time as the sidetone audio is being produced, the Arduino is also generating a keying signal that keys the class C power amplifier (PA). This RF – hopefully in excess of 1W – goes into the bandpass filter to reduce harmonics, then into the aerial. The transmitter always produces a driven version of the buffered DDS output; this is amplified on demand by the keyed PA. Break-in is controlled by the Arduino; shortly after the final keying ends, the RX/TX relay returns the bandpass filter and aerial to the receiver and supplies power to the receiver.

All Arduino band-switching, RX/TX switching and keying signals are opto-isolated, to prevent RF getting into the digital side of the system.

I intend to build the transceiver as a series of separate modules, rather than building it all on one board. This should aid testing – and presentation – as each module can be built and tested separately, then integrated. Note that in the schematics and parts lists shown in future articles, each circuit will be stand-alone in terms of component numbering, so there will be an R1, C1, etc. on each circuit module.

I’ll be using a mixture of stripboard / matrixboard / prototype board and copper-clad Manhattan-style construction for the various modules. Interconnects are all 0.1″ 2.54mm single in-line headers, with ribbon cable, shielded audio or RG174 coax RF cable.

Stay tuned for the next article, where I consider the user interface….

The ‘Easi Build 80m Transceiver’ was designed by Bruce Edwards G3WCE and published as a series of ‘Down to Earth’ articles in RadCom in July-Nov 1999 and Jan 2000.

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

It is a CW QRP direct conversion receiver based on an NE612, with VFO and RIT, and a transmitter capable of around a couple of watts, with a sidetone oscillator. The design as presented is a single band transceiver, with manual switching between transmit and receive. It is, as its name suggests, easy to build.

I built one around April 2000 with assistance and parts from members of the Maidstone YMCA Amateur Radio Society. Some parts were quite hard to find, with many being supplied by Sycom, now sadly closed down due to the owner’s health. This was my first substantial construction project from published articles, and I tried to follow the construction guide to the letter – not knowing that long component leads are problematic…. Here’s the inside of the large case:

The inside view of my EasiBuild Mk 1

The inside view of my EasiBuild Mk 1

It works, although my current aerial system is a loft-based 20m dipole (which barely tunes to 80m) and an 80m compact loop which just does not radiate. I’m hopeful of constructing a proper 80m aerial one day… but my EasiBuild has not yet yielded a QSO 😦

After a long hiatus, I’ve returned to ham radio and CW, getting up to a CW speed of 12/14 WPM, and constructing an Arduino-based Antenna Analyser (moderately successful, could be improved) and a RockMite ][ kit for 20m. I’ve been re-studying my RAE electronics, and QRP construction articles, but am not yet at the stage where I could completely design a transceiver from scratch.

Hence this project – a revised version of the EasiBuild, using much of the original, adding some digital control:

  • The original was a single band transceiver, whereas I want to be able to switch between a small number of bands. I’ve chosen 40m, 30m and 20m as the ones I’ll build for, but the filters will be pluggable, and I’ll provide design/construction notes for all the UK amateur HF bands.
  • The single VFO of the original will be replaced by an Arduino Micro-controlled AD9850 Direct Digital Synthesis module, as used previously in my build of Beric Dunn’s antenna analyser. This, with a buffer, will hopefully yield all HF bands. I’ll control the switching of filters via relays, driven by the Arduino.
  • Manual switching between transmit and receive is also going to be controlled by the Arduino, with the addition of a keyer, and support for paddles as well as straight keys.
  • The RIT and sidetone generation will also be handled by the Arduino.
  • The audio output stage will be replaced with a narrow CW filter and amplifier, using the NM0S Hi-Per-Mite circuit.
  • User interface controls will be a 16×2 LCD, and a rotary encoder with a button. The rotary encoder and button will be used to tune, and select items from lists in the UI. A single button limits the UI somewhat, but I like minimalism 🙂

I plan to document the project via this blog, in a series of articles, each on a separate aspect of the transceiver. I hope each article will be of ‘magazine quality’ – I don’t want to waste your time with failed experiments, although I am a very amateur amateur, so it’s likely there will be some reworking… as I proceed, I’ll be writing a construction guide that can be taken as a stand-alone guide to building your own EasiBuild Mk 2. I’ll provide design notes, schematics, parts lists, test instructions along the way.

You don’t need to have the original articles at hand – I’ll quote Bruce (and others) along the way.

One final – but vital – point…
This project could not be undertaken without the assistance and encouragement of others in the ham radio construction and operation community, and I’d like to acknowledge and thank everyone who has helped with the project. So, to start:

Without Bruce Edwards G3WCE’s original articles, this project would not exist (or would be very different) – in his conclusion, he writes “With a reasonable antenna (e.g. a G5RV) you shouldn’t have any shortage of QSO’s.” Let’s see! Thanks to Maidstone YMCA Amateur Radio Society for advice and components.

Two online communities have been very supportive and helpful: The Facebook “Ham Radio Homebrew Corner” group for much advice on the project. The Twitter @lids_cw “Less Involved Data Society”, for encouraging QRP and QRS – especially Michael G0POT and David G7AGI for advice; David introduced me to the Hi-Per-Mite filter – many thanks! Also Dennis Anderson of Kanga Products, for advice on components, and supplying the excellent RockMite and K14 keyer kits.

Stay tuned for the next exciting article!

I’ve recently been trying to connect to a Microsoft SQL Server from a CentOS 6.5 system, using my tool of choice, Perl 5.10.

I chose to use unixODBC, and Microsoft’s own closed-source driver.

There are a few excellent articles out there on using unixODBC, such as EasySoft’s tutorial. The authors of that article, EasySoft, sell their own ODBC driver, which I didn’t try but probably should have. Or, perhaps FreeTDS would have been easier.

This has been moderately problematic, due to Microsoft’s driver requiring unixODBC 2.3.0, which does not exist in the standard package repositories. They expect you to build from source. So, I tried to build it as a .rpm, but this didn’t work quite perfectly. I looked on rpmfind, and found that there’s a unixODBC 2.3.1 available in Fedora Core 17, of course, building that on CentOS didn’t help because the MS driver checks for the existence of unixODBC 2.3.0 exactly, during its installation script. Gee, thanks MS!

Now I could go off on a lengthy rant here about MS being a bit NIH and not understanding package management (well Windows still has no such concept)… but no. Here’s how I got round this – it’s incomplete, but due to other committments I had to drop this work, so if this is of use to others, great…

So, I took the 2.3.1 .spec file, and added a patch that renamed all the .so files to .so.2, as required by perl-DBD-ODBC and built 2.3.0 with it… it didn’t quite work, as the MS driver is linked against! So, one quick ln -s later, I have the combination of unixODBC 2.3.0, perl-DBD-ODBC 1.48-1 and MS’ working together. A bug report about similar problems with unixODBC and the Oracle driver was filed here – it looks like the MS driver could never work with unixODBC out of the box; a new MS driver linked against the correct libraries is what’s required.

Perhaps I should have built unixODBC from source as the MS page suggests, but I thought I’d be better off taking the same packaging instructions as similar RPM-based distros do. Anyway, I’ve got it working.

My .odbc.ini file looks like (data source name and hostname modified):

Driver = ODBC Driver 11 for SQL Server
Server =

The perl script I used to test it:

use strict;
use warnings;
use DBI;
use DBD::ODBC;
my $server = "";
my $db_user = "myuser";
my $db_pass = 'secret';
my $dbh = DBI->connect("DBI:ODBC:MyDataSource", $db_user, $db_pass) or die "$DBI::errstr\n";
print "Connected\n";
my $query = "Select count(*) from [mytable].dbo (NOLOCK)";
my $sth = $dbh->prepare($query) or die "$DBI::errstr\n";
$sth->execute or die "$DBI::errstr\n";
# go do stuff!
# Close the database

You can find my modified unixODBC.spec here, and the small patch to rename the .so’2 can be found here.