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:
username=windowsdomain\\windowsusername
domain=windowsdomain
password=windowspassword

(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:

username=windowsusername
domain=windowsdomain
password=windowspassword

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 libodbcinst.so.1! So, one quick ln -s libodbcinst.so.2.0.0 libodbcinst.so.1 later, I have the combination of unixODBC 2.3.0, perl-DBD-ODBC 1.48-1 and MS’ libmsodbcsql-11.0.so.2270.0 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):

[MyDataSource]
Driver = ODBC Driver 11 for SQL Server
Server = tcp:mysqlserver.organisation.com

The perl script I used to test it:

#!/usr/bin/perl
use strict;
use warnings;
use DBI;
use DBD::ODBC;
my $server = "mysqlserver.organisation.com";
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
$sth->finish;
$dbh->disconnect;

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.

Errata

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.

Testing

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

Previously, I described the HF antenna analyser project I’m building, from Beric Dunn K6BEZ’
schematics
and Arduino firmware, listed the costs of the components (around £50 in May 2014) and where I obtained them. In this article, I’ll show the veroboard layouts I’ve designed, and start with the construction. All resources, pictures and files for this project are available from the project GitHub repository.

Please contact me if you have any questions about the analyser and the plans shown here, I’d love to hear from anyone building it!

Errata

First, a correction and apology – the pin strips I chose for connecting the Arduino and DDS module are fine for connecting chips with thin pins, but are unfortunately too small for the thicker pins of the Arduino and DDS module. If you started buying components based on the previous post, I’m sorry for the mistake – I only spotted it when plugging the boards in. I’ve replaced them with sockets made from “springy” Dual-In-Line chip sockets – these are not ideal: the boards connect into them, but I’m not satisfied with their security. I’ll be looking for suitable, cheap replacements. You’ll see the changes throughout the rest of the article.

Power distribution

Also in the previous article I mentioned small changes I’d made to the original design – I omitted that I’m powering the Arduino Micro with 7-9v via its VIN input, rather than its 5.5v pin (I think this is a power output, rather than power input?) – the Arduino Micro page states:

Power

The Arduino Micro can be powered via the micro USB connection or with an external power supply. The power source is selected automatically.

External (non-USB) power can come either from a DC power supply or battery. Leads from a battery or DC power supply can be connected to the Gnd and Vin pins.

The board can operate on an external supply of 6 to 20 volts. If supplied with less than 7V, however, the 5V pin may supply less than five volts and the board may be unstable. If using more than 12V, the voltage regulator may overheat and damage the board. The recommended range is 7 to 12 volts.

The power pins are as follows:

  • VIN. The input voltage to the Arduino board when it’s using an external power source (as opposed to 5 volts from the USB connection or other regulated power source). You can supply voltage through this pin.
  • 5V. The regulated power supply used to power the microcontroller and other components on the board. This can come either from VIN via an on-board regulator, or be supplied by USB or another regulated 5V supply.
  • 3V. A 3.3 volt supply generated by the on-board regulator. Maximum current draw is 50 mA.
  • ⏚ Ground pins.

Construction Time!

OK, let’s start!

Firstly, prepare a piece of veroboard, 38 strips x 31 holes, 96mm x 81mm, 2.54mm hole spacing. Farnell sell a 121.92mm x 101.6mm 41 tracks x 44 holes board that can be cut to fit.

Carefully mark where you’ll cut tracks in the places shown by the red X’s in the diagram below, check them, then cut with a spot face cutter (or drill bit).

Here, I’ve used the solid tracks at the top (which I’ll later cut off), and the solid tracks cut from the bottom of the board as a guide to where to place track cut marks. I’ve marked the cuts with a CD marker pen before checking, then cutting.

I’ve placed mounting holes in the four corners of the board.

Clean the board by lightly sanding it with fine sandpaper to aid soldering, then check that you do NOT have continuity across each of the track cuts.

Here’s the board with tracks cut, mounting holes drilled and the top solid strip still attached.

Now it’s time to add all the wire jumpers, IC holder and pin strips for the Arduino Micro and DDS Module. Use CD marker pen first to mark these out on the component side of the board.

Here’s the board layout:

The DDS Module goes at the top left, with its trimmer at the top and crystal at the bottom. The Arduino Micro goes at the bottom left of the board, so that its USB socket can protrude through the case. The PSU is at the bottom right, and the SWR bridge circuitry is at the top right, connecting to the antenna UHF socket (the type that takes a PL-259 plug – feel free to change this to a 50 Ohm BNC socket). Power comes in via a barrel socket and switch.

When the wires, test pins and pin strips are done, the board should look like this:

Now would be a good time to check the continuity of the ground and +5v connections. Check that ground is connected to all the components connected by the purple tracks here:

Check that +5v is connected to all the components connected by the purple tracks here:

If all is OK, now add the components for the PSU: the electrolytic capacitors, 7805 and 7809 voltage regulators at the bottom right. Take note that in the layout diagrams, the square pin of the electrolytic capacitors is negative. The In/Ground/Out connections of the voltage regulators can be found here [PDF 78xx datasheet].

After fitting the PSU components, and connecting a 9V battery to the +V IN and GND IN pins on the right of the board, you should have a board like this:

Measuring the voltage between the GND test pin (between the DDS module and Arduino), and the +5V test pin, I had 5.02V, and between that GND and the +9V test pin near the Arduino Micro pin strip, I had 7.02V – which is fine, it’s within the 6-20V given in the Arduino Micro page – with a 12V DC wall adapter, I expect to have a nice, smooth 9V. Be careful with the GND test pin next to the +9V test pin – I added the one between DDS and Arduino because the one next to the +9V test pin is very close to GND, and you don’t want to accidentally short them out!

Next, add the rest of the components in the top right of the board forming the SWR bridge. Solder the diodes in last so they don’t get overheated, and remember to get them the right way round: the end with the line is the cathode, and matches the line in the diode circuit symbol. Take care with the C1 electrolytic capacitor – the square pin on the layout diagram is negative. I couldn’t find 5K Ohm resistors, so made them out of a pair of 10K Ohm resistors in parallel, mounted on their end next to each other. Add the R12 resistor on the left of the Arduino Micro.

When done, the board should look like:

Some detail on the SWR bridge components, in case the layout isn’t clear:

Connect the scan LED on long wires, as it’ll need to fit into a hole in the case (I used a LED mounting clip). Connect the power (I’m using a 9V battery for now) and antenna connector (I’m using a longish piece of RG174 cable from a previous project). When finished, the board will look like this (with the original pin strips replaced with homebrew ones made from “springy” Dual-In-Line chip sockets):

After adding the Arduino Micro and DDS module boards, the analyser looks like this:

Firmware

The firmware then needs loading into the Arduino Micro. I’m using version 1.0.5 of the Arduino programming software. I’ve made a few changes to Beric’s original firmware:

  • Added the “Scan in Progress” LED control.
  • Made the Arduino’s inbuilt LED pulse slowly when it’s waiting for serial input, as a way of showing that it’s working.
  • Fixed a bug in the reporting of the stop frequency in the ? report.

Testing

After uploading the firmware, and starting the Serial Monitor at 57600 baud, you should be able to issue commands to the analyser, and test that the DDS module is generating a signal at the RF test pin. I connected the analyser output to a 50 Ohm dummy load, and started a sweep at a low frequency (my old scope doesn’t handle high frequencies), and observed:

Next….

I haven’t covered testing the SWR bridge circuit yet, so that’s next. The “Scan in Progress” LED isn’t working; don’t know why yet. Also, I’ll finish off the construction, cover the software used to drive the analyser, showing SWR graphs, and hopefully give some background on what’s being measured here, and how you can use the analyser to adjust your antenna.

Acknowledgements

Thanks to Rick Murray for VeroDes, a very nice Windows program that I used to draw the board / track / continuity layout diagrams in these articles.