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.

In part 2 of this series, I described the construction of the HF antenna analyser project I’m building, from Beric Dunn’s schematics and Arduino firmware. In this article, I’ll finish some small items of construction, and look at testing and driving the analyser. All resources, pictures and files for this project are available from the project GitHub repository, with driver software available from the driver GitHub repository.


The Scan LED wasn’t working, and this was because R12 was too large, so I replaced it with a 1K Ohm. Sorted. Also, the SIL headers I’d ordered originally were too small for the pins of the Arduino Micro and DDS module. It took some time to locate suitable replacements, and find a supplier who wasn’t going to charge me £4.95 just for placing an order as a private (hobbyist) customer. Fortunately, I discovered Proto-Pic, a UK supplier that could provide 10-pin and 6-pin SIL headers. I ordered 2×10 pin Stackable Arduino Headers (PPPRT-11376) and 6×6 pin Stackable Arduino Headers (PPPRT-09280) for £4.78 including P&P. When fitting the 6-pin headers for the Arduino Micro (three per side), you may find that they are quite tight together, so sand down the inner edges a little. The Arduino Micro was still quite a tight fit, but it’s far more secure than it was.

Boxing it up

I cut a few more tracks on the veroboard near the mounting holes so that the metal spacers and screws I found in my spares box wouldn’t short anything out, then started fitting the board into the enclosure, cutting holes as appropriate. I added a switch into the power line… the result looks like this:

And when the LetraSet goes on:

Software, Firmware

I’ve made a few changes to Beric’s original firmware (see here), but will keep the commands and output format compatible, so if you’re driving my modified firmware with Beric’s Windows driver, everything should still work.

I use Windows 2000 on an old laptop in the Shack: I couldn’t get it working with the Arduino drivers, so I couldn’t use Beric’s Windows driver software. I needed a Linux or Mac OSX solution, so started writing a Scala GUI driver that would run on Mac, Windows or Linux, and have got this to the point where I need to add serial drivers like RxTx, getting the native libraries packaged, etc., etc.

However, that’s on hold, since I was contacted by Simon Kennedy G0FCU, who reports that he’s built an analyser from my layout which worked first time!! He’s running on Linux, and has passed the transformed scan output into gnuplot to yield a nice graph. I hadn’t considered gnuplot, and the results look far better than I could write quickly.

So, I reused the code I wrote several years ago for serial line/data monitoring, and wrote an analyser driver in C that produces nice graphs via gnuplot. So far it builds on Mac OSX. In the near future I’ll provide downloadable packages for Debian/Ubuntu/Mint, Red Hat/CentOS and hopefully Raspberry Pi.


The analyser as it stands is not without problems – the first frequency set during a scan usually reports a very high SWR – I don’t think the setting of the DDS frequency after a reset is working reliably. From looking at the DDS data sheet timing diagrams, short delays are needed after resetting, and updating the frequency – these are not in the current firmware…

Also repeated scans tend to show quite different plots – however, there are points in these repeated plots that are similar, hopefully indicating the resonant frequencies.

Beric mentioned (on the k6bez_projects Yahoo! group) that “With the low powers being used, and the germanium diodes being used, it makes sense to take the square of the detected voltages before calculating the VSWR.”…

Simon pointed out that “the variable VSWR is defined as a double. This means that when REV >= FWD and VSWR is set to 999 it causes an overflow in the println command that multiplies VSWR by 1000 and turns it into an int. Making VSWR a long should fix this.” He also suggested some other changes to the VSWR calculation…

… these are changes I’m testing, and hope to commit soon.

I’ll add some options to the software/firmware to plot the detector voltages over time for a few seconds – an oscilloscope probing the FWD/REV detector output shows some digital noise. I had added an LED-fading effect to show that the board is active, and this exacerbates the noise. This noise makes it through to the VSWR measurement. I’ll try taking the mode of several measurements… Once the DDS is generating the relevant frequency, I’m expecting these voltages to be perfectly stable.

I’m investigating these issues, and hope to resolve them in software/firmware – I hope no changes are needed to the hardware to fix the problems I’m seeing, but can’t rule out shielding the DDS, and/or using shielded cable for the FWD/REV connections between the op-amp and Arduino Micro.

In the next article, I’ll show how to drive the analyser with the driver software, and hopefully resolve the noise issue.

Will M0CUV actually find the resonant frequency of his loft-based 20m dog-leg dipole made from speaker wire? Will the analyser show the tight bandwidth of the 80m loop? Stay tuned! (groan)

73 de Matt M0CUV