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.

In the previous article, I started the construction of the EasiBuild Mk 2 with the power regulation and supply board. In this article, I detail the digital controller of the transceiver.

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

In the original circuit, switching between receive and transmit was done manually with a switch (and was frequently forgotten!). The transceiver was a VFO-based (variable frequency oscillator) single-band design with a front panel scale around the tuning capacitor indicating frequency. RIT (receiver incremental tuning) was a front panel potentiometer, and the sidetone was generated by its own circuit and injected into the audio amplifier.

In this revised version, RX/TX switching is performed automatically when the key is pressed. A paddle is also supported with proper keying signals and timing being generated. Three bands are available, with swappable filter blocks: you can configure which filter is in which socket via the menu. The VFO/buffer is replaced by an AD9850 DDS (direct digital synthesis) module and buffer amplifier. Tuning and band switching is done automatically via a front panel rotary encoder and its pushbutton. Frequency display and other information is via a front panel 16×2 LCD display. The sidetone is generated when the keying signal is sent, as a shaped PWM (pulse width modulation) signal, converted to audio by an RC network, and injected into the audio amplifier. All the above is orchestrated by a microcontroller. Connections to the other modules in the transceiver are via 2.54mm pin headers.


The schematic for the control board is shown below (click diagram for a slightly larger version):


The purpose of this module is to hold the microcontroller (mounted on 2.54mm female headers), and to connect its various pins to groups of 2.54mm male pin headers that lead off to other modules in the system, for neatness. There’s no extra logic, driving, buffering or opto-isolation circuitry in this module, everything connecting in here is TTL, and the audio sidetone output. This makes it easy to test in isolation from the rest of the system.

I chose the Arduino Micro as it had just enough I/O capacity for this project, and I’d used it before in my antenna analyser project. Other members of the Arduino family would give more flexibility.

Thanks to Bouni for the diagram of the Arduino Micro pinout above (click diagram for a much larger version).

Please note that there are several errors on the diagram, I’ve notified Bouni and will update this post when a corrected diagram is available. The errors affecting this board (there are other errors) are:

  • A0 is D18, not 14.
  • A1 is D19, not 15,
  • A2 is D20, not 16,
  • A3 is D21, not 17,
  • A4 is D22, not 18,
  • A5 is D23, not 19,

The discussion below will refer to the corrected micro’s pins by the coloured names in the diagram.

Digital input pins are mapped to their functions in the transceiver as follows:

  • 12/DAH from paddle or DOWN from straight key
  • 11/DIT from paddle or DOWN from straight key
  • 10/ENCR, the right quadrature signal from the rotary encoder
  • 9/ENCL, the left quadrature signal from the rotary encoder
  • 8/BTN, the pushbutton on the rotary encoder

The Arduino’s internal, software-controllable pull-up resistors are enabled for all these input pins. This group of pins are used for digital inputs, since all their states can be discovered by a read of the PINx locations in an interrupt handler, which I’m doing in the sidetone generator’s timer ISR. I considered using the AVR’s pin change interrupt: one interrupt occurs when any of the pins change state. Pins 8-11 use the “PIN B” interrupt, and pin 12 uses the “PIN D” interrupt. Since the USB RX/TX (specifically, RX) are likely to generate interrupts on USB traffic, and I intend to provide a back-panel USB connector, possibly for diagnostics or even CAT control, I’ve not used the pin change interrupt, so this led me to a simple read of PIN B and D under a regular timer interrupt. Debouncing is done in software.

It remains to be seen whether I skimped a bit on control push buttons – I have pin 13 available that I might make use of.

I’ll go into the software design in a later article, so no more on that now.

Digital outputs are mapped to their functions in the transceiver as follows:

  • 18/DDS_RESET for AD9850 control (14 is erroneous on the diagram)
  • 19/DDS_DATA for AD9850 control (15 is erroneous)
  • 20/DDS_UPDATE for AD9850 control (17 is erroneous)
  • 21/DDS_CLOCK for AD9850 control (16 is erroneous)
  • 22/BAND3 for switching the third bandpass filter in circuit (18 is erroneous)
  • 23/BAND2 second bandpass filter (19 is erroneous)
  • 7/BAND1 first bandpass filter
  • 6/RX/TX for switching between receive and transmit
  • 5/TONE, PWM output for the sidetone, via an RC network
  • 4/KEY for switching the PA on, in transmit mode
  • 3/SCL connection to the LCD via I2C-to-parallel adapter
  • 2/SDA          ”        ”

Although the power module provides a 5v supply, which could be used to supply the LCD I2C module, I’ve chosen to power the I2C module with the 5v supply generated by the Arduino.

The RC network on pin 5’s PWM output converts the PWM signal to audio, as described in the MicroChip application note Using PWM to Generate Analog Output.
From the application note, I want an upper frequency for the low pass filter of 1.5kHz, and choosing K=5, and the -3dB point at 1.5kHz:

  • RC= 1/(2 π f)
  • RC= 1/(3000 π)
  • With C as a 0.01μF, R would be about 10kOhm.

Use a polyester capacitor for C, as per Dave Richard’s advice in the hi-per-mite forum.


Again, I’m using prototype board for this module.

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.

I’m using Eagle to design these schematic and board diagrams. Eagle is an excellent CAD system available in a freeware version for non-profit use. However, it is intended to aid design of “proper” printed circuit boards: it has no built-in knowledge/rules for working with prototype board or stripboard. I’ve adopted some conventions for using it with these boards.

Blue lines are wires on the underside. The holes of the prototype board coincide with the intersections of the grid lines. I’m supplying a screen grab of the board layout, as Eagle’s normal export-to-bitmap omits the grid: I can’t lay out prototype board without it!

The board layout is somewhat idealised: Looking at the left-hand side of the board layout, Arduino pin 22/BAND3 (A4 on the Arduino component) is broken out to a connecting wire that isn’t exactly on a grid intersection. In the actual build, it is, but the wire is bent a bit at the end – you’ll see in the photos at the end. Also, the top-right digital inputs on the Arduino look bent at right angles, and also not on grid intersections – they’re actually completely straight on the board. This is so I can fit all the wiring and pin headers on the 18×24 prototype board. Note that all wiring on this board uses insulated 1/0.6 wire – apart from the GND connection on the right hand of the Arduino: there are two junctions there.

Solder all pin headers in place first, then do the wiring. The Arduino sockets are made from four 10-pin female 2.54mm headers, two of which are cut down to 7 pin, and sanded to fit alongside the 10-pin header.

The picture below shows the wiring about half-complete.

I should have taken a picture earlier than this (sorry), as the white (band select) and red (+5v to panel) wires obscure the connections between the power header and Arduino (row 6 and 7 on the right hand side of the Arduino). The ground connections, sidetone RC network, and TX key header are tricky (rows 9 to 12 on the left hand side of the Arduino). They get obscured in the next pictures….

Of course, it’s only after spending a few weeks’ spare time designing the board in Eagle and several hours building it, then looking at these photos that you realise that you could have routed these wires underneath the Arduino, inside its pins rather than outside. Thinking outside the box requires you to realise that there is, actually, a box. Or not, in this case. You also realise after the construction that the RC network’s capacitor should have been polyester, not ceramic, as ceramics tend to introduce microphony into audio circuits. It’s what I had on the bench when building… and it was a 0.1μF I used, not a 0.01μF, as per the schematic. I’ll change it later. As the philosopher Homer exclaimed on more than one occasion: “D’oh!”. Hopefully this won’t be a big problem.

Here you can see the rest of the panel input connections.

The finished board.

Without an Arduino you can make out the sets of 10-pin headers.


I haven’t chosen a case in which to mount the modules yet; one point to note is that there will need to be about 3cm clearance at the top of this board to take the USB adapter cable that will be mounted on the back panel.

The components for the front panel (rotary encoder, paddle 3.5mm jack connector, and LCD I2C board) should all be connected to the panel connector.

Parts List

Part Value
C1 0.01μF polystyrene
R1 10k
FROM_PWR 2-pin male 2.54mm header
BAND_SELECT_TO_FILTERS, TO_DDS 5-pin male 2.54mm header
KEY_TO_TX, SIDETONE_TO_AF 2-pin male 2.54mm header
PANEL 9-pin male 2.54mm header
HDR1, HDR2 10-hole female 2.54mm header
HDR3, HDR4 10-hole female 2.54mm header cut down to 7-pin


Before inserting the Arduino, check all points for continuity and shorts, then add Arduino, attach to power board, and ensure 5v is present on panel connector, and that Arduino boots.

The firmware permits compilation in ‘test harness mode’, by defining one of several preprocessor symbols. See the EasiBuildMk2.ino Arduino file in the code repository. There are several harnesses:

  • Input signals: BTN, DIT, DAH, ENCR, ENCL as a binary / hex number. Touch the controls, see the pins change.
  • Output signals: BAND1, BAND2, BAND3, RX/TX, KEY, DDS_RESET, DDS_DATA, DDS_CLOCK, DDS_UPDATE. Use the rotary encoder to switch to a different signal, or wait and it’ll loop through the set, toggling the pin shown on the LCD once per second. Test with meter, logic probe or scope.
  • Sidetone: use rotary encoder to adjust volume, press button to switch to use rotary encoder to adjust pitch.
  • Events: detection, debouncing of input signals and conversion into ‘events’ that are pushed onto a FIFO, that are decoded and displayed on the serial console.

After some initial teething issues, with incorrect pin numbering on the diagram I was following, the board tests out fine, and is now allowing me to build the UI framework I need to write the firmware. I’ll write a separate post about the firmware, its design, and test-driven development of Arduino code (without an actual Arduino).

Stay tuned….

Thanks to Bouni for the Arduino pinout diagram; Jenny List G7CKF and Dr. Lucy Rogers for advice on working with Eagle; Bill W0WCA and Dave Richards AA7EE for advice on use of polyester capacitors in audio circuits (that I completely forgot when I came to build!); Mike N2HTT for his 3-band VFO project, and details of the rotary encoder which I’ve used in this project; Colin M1BUU for showing his DDS signal generator, illustrating connection details, construction techniques, and for advice on driving the LCD; Mark VandeWettering K6HX for info on using PWM for audio.

In the next article, I’ll get into the actual radio hardware design, with the addition of the direct digital synthesis and buffer amplifier.

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: