Yup – It’s Another Si5351 VFO

To many, this will be just another Si5351 VFO project, with nothing to distinguish it from the others. In fact, that’s exactly what it is. The “how to” of connecting an Arduino board to an Si5351 board, wiring up a display, and loading the firmware, is straightforward, and well established. To me though, it was a complete mystery. I have been very adept, my whole life, at studiously avoiding anything to do with digital electronics, computing, coding, and the like. When my friends in school were getting excited over Sinclair ZX81’s, BBC Micros, and Commodore 64’s, I was building a one-tube regen, an 80M DSB transceiver, listening to my British military R107 shortwave receiver, and talking to hams on the local repeater on my converted Pye tube VHF base station. I remember wandering into a Tandy store (what us Brits called Radio Shack) in the city of Worcester at some point in the late 70’s, and being greeted by the sight of a Tandy computer – probably a TRS-80 or something similar.

“What does it do?” I asked the salesperson.

“What do you want it to do?” he replied.

This seemed like a strangely non-committal response. Maybe he didn’t know what it did, and was merely throwing the responsibility for finding out back on me? I don’t remember anything about him now, but perhaps he was some gangly teenager who knew little about the stuff he sold, and whose main thought was getting off work so he could go to the pub with his friends? That’s it! He was just trying to appear knowledgeable by giving me a non-answer! This suspicious reaction was quite representative of the way I thought about computers back then. Just as it’s hard, if not impossible, to get the measure of a person if they willfully refuse to reveal anything of themselves to others, so it seemed with computers. These expensive boxes just sat there, doing nothing, except waiting for instructions. Such a disappointing lack of character! How is one supposed to respect a person or an object that sits quietly in a corner, waiting to be told what do? How feckless! Dedicated hardware, however, was different. When you bought a radio receiver, you knew that, on twiddling a few knobs and flicking a few switches, it would receive radio signals. A burglar alarm would alert you to the presence of burglars (well in theory, anyway), and those remote control cars that RS sold by the gazillion were guaranteed to quietly drive your family nuts in the days after Christmas before work, and school, resumed. Computers, on the other hand, promised everything but actually did nothing, until you told them what to do – and even then, there were a myriad of ways in which they could obstinately refuse to comply with your wishes. Not for me!

And so it was that, throughout my adult years, I deprived myself of exposure to things digital. I am not proud of my incurious nature about many things – though, when I am interested in something, I exhaust myself with the sheer intensity of focus. It’s an odd type of blinkered approach to the world that leaves others confused. I can’t say I blame them. The projects I built ran off anything from a few volts, up to 15-20V or even more. 9V batteries worked fine (we called ’em PP3’s), as did the old 12V lead acid battery that would no longer power the family lawn mower, but did a sterling job of powering the radio gear in my bedroom. My circuits weren’t picky about voltage, but these new-fangled digital chips just wanted to see 5V. Really? What kind of a voltage was that? They came with a surfeit of incomprehensible nomenclature too. Words that sounded like something John Lennon would have made up for a song post-1965. Words like NAND. You know, it wasn’t so much that this stuff wasn’t interesting – it was simply that I was really into building little radio receivers, and didn’t see how this digital stuff could help me (I wasn’t very imaginative). I had a small stash of ferrite rods, variable capacitors, resistors, and transistors, and some 9V battery snaps and with that, I had all that I needed. These were the days when loading a program onto a computer meant playing an audio cassette into the “line in” jack of your computer. I just didn’t see how any of that world full of DOS, NAND gates, tiny amounts of RAM, and the like, as well as really weird voltages like 5V, could possibly apply to me. Yes – I was that closed-minded. It’s not hard to see how a few years later, when we all graduated from University, my colleagues went on to successful careers with big technology companies, designing integrated circuits, and building the backbone of the internet, while I moved to Los Angeles and promptly became a DJ 🙂

A few years ago, a friend generously gifted me a Bare Bones Arduino board. I didn’t know what it was. It had header pins sticking out of it but, at that point, I didn’t really know what header pins were, or how to connect to them. I looked at it, and wondered what to do with it. What did it do? How did it do it? What was I supposed to connect to it? I placed it carefully in a box along with some other electronic things that confused my simplistic analog mind, and carried on with my life. Every now and again, I’d take it out of the box, blink at it a few times, and put it back. I knew that Arduino was the new big thing, and something that was going to play a big part in ham radio homebrewing in the coming years but I guess that, with my toroids and air-spaced variable capacitors, I wasn’t ready for it yet. Not that my experience level in this arena was completely non-existent. I had taken part in the beta tests of the Etherkit CC-20 and later, the planned CC1 series of QRP transceivers. These experiences had taught me that I could solder SMT devices, and even replace an SMT ATMega328P with nothing more than a soldering iron, soldering wick, flux, and a sharp blade. It was a small revelation to learn that I could do this stuff. Jason NT7S very patiently walked me through the process of flashing the firmware onto the ATMega328 via the ICSP header mounted on the board. This was a first for me, and quite exciting to gain a new skill, which proved handy when I built the SPT “Sproutie” Beacon, and needed to flash firmware onto the ATtiny13 in that little transmitter.

Then, recently, I took the Bare Bones Arduino board out of the box which had been it’s home for a few years and, this time, something clicked. “Goshdarnit” I thought, “I’m going to make an LED blink. If others can do it, so can I!

You can’t see the LED blinking in the above photo. The fact that the board is not powered doesn’t help, but take it from me that when it was powered, it was blinking!

I spent a few days and nights with the LED blinking and pulsating at various rates, as I loaded different sketches, and adjusted the parameters. As fun as flashing lights are to a simple lad like me, it wasn’t the reason I wanted to resurrect this little Arduino board from it’s relaxing life in storage. I had an Etherkit Si5351 Breakout Board that needed to have life breathed into it. I wanted to generate RF, by golly!

This next stage was where things started to come into focus, and it began to dawn on me that using one of these little breakout boards to generate a stable RF signal wasn’t all that hard at all – well, from the point of view of the end user, at least. Once I did a bit of reading up on how to control the Si5351, I was just a little gobsmacked. You mean all it needs in terms of data input is 2 connections? SDA (serial data) and SCL (serial clock)? That’s it? I made those 2 connections between the Arduino and Si5351 board, uploaded the Etherkit Si5351 example sketch, and almost fell off my chair when the Si5351 began emitting RF on the frequency I had entered into the sketch just before uploading it. It was a moment of realization – that this little board actually was a programmable oscillator. How incredibly neat! No more custom-cut crystals – for ~$10, you can get a board like this, and program it to the frequency of your desire (within it’s specified limits), and it replaces both the crystal and the oscillator. For a single frequency, once you have programmed it, it doesn’t even need a micro-controller connected to it.  Fantastic!

I suppose that was the moment at which my mind, which moves at the speed of molasses, “got” that a VFO with this board is really a micro-controller which, with the help of a rotary encoder, is re-programming the Si5351 “in real time” as the encoder knob is turned. Every single click of the encoder sends a new instruction to the Si5351, to step up or down, in an increment which the firmware has already specified. I was hot to trot, so began looking around for a basic Si5351 sketch. The word “sketch” reminds me of the Etch-A-Sketch which I never came close to mastering as a child. I must admit that I think this association slightly trivializes Arduino programs (which are written in a type of C) in my mind, but that is what they are called, so that is what I will call them.

What I was looking for was a sketch that would allow me to vary the frequency of the Etherkit Breakout Board continuously in the HF region, from at least 3 – 30MHz. I was only concerned with one of the 3 clock outputs. At this point, I simply wanted to use it as an HF signal generator for testing purposes, or to control a general coverage direct conversion receiver. Perhaps at some point, I’ll begin fiddling around with code, and learning how to modify it for my own purposes, but at this point, I wanted a sketch that I could upload to the programmer, and immediately be in business. I also wanted to use one of those tiny little OLED displays, due to the enclosure I was considering.  This was the point at which I found Thomas LA3PNA’s sketch entitled, “A simple VFO for the Si5351 for either LCD or OLED.” Perfect!

This was also the point at which I discovered that the ATMega168 in my little Arduino clone board didn’t have enough memory to hold Thomas’ VFO sketch. I considered purchasing a newer Arduino board or clone, but most of the ones I saw had more stuff on them than I needed or wanted, in terms of inputs/outputs and programming ability. All I wanted was the ATMega328P, and a 6-pin ICSP header to program it with. Then I remembered back to my time working on the Etherkit CC-20 beta, and how I had expertly fried the micro-controller. Jason sent me a replacement and, wisely, included a few extras, in case my prowess at destroying delicate chips were to reassert itself. I still had those little SMT ATMega328P’s lying around, as well as a supply of breakout boards to mount them on. Problem solved! Building something from parts on hand is so much more satisfying than purchasing a ready-made solution – at least, for the first time, it is.

I sat down to scribble out a schematic, and it was during this process that the realization hit, as to what an Arduino board is. What makes Arduino, well, Arduino, is not the board, but the software platform that supports it. Apologies for stating what is well known fact to many readers, but this had all been previously unknown to me. The board itself is really just a micro-controller, with the power supply and input/output options either suited to the tasks at hand or, in the case of a larger and more general purpose board, such as the Uno, many different such options, to make it as versatile as possible. Ths was fantastic, because what it meant was that all I needed to control the Si5351, was a micro-controller (ATMega328P), a 16MHz crystal with the two associated capacitors, a 5V power supply, and some 0.1uF capacitors for bypassing. Oh – and a 6-pin header for programming. The schematic for the VFO is simple because, as far as the hardware goes, everything happens inside the micro-controller and the the Si5351 (which are both internally complex). The rest of it happens in the firmware. As far as hardware goes, we’re simply tasked with the 21st century equivalent of assembling a crystal set.

Here’s what I came up with. There are an awful lot of unused pins but, for this purpose, there are a lot of pins we don’t need. Without thinking, I was about to connect the AREF pin to +5V, because that’s what I was seeing in the various schematics I was using as references, until it occurred to me what AREF stands for. It’s an Analog REFerence pin. This application uses only digital inputs and outputs, so figuring that I didn’t need an analog reference, I didn’t connect it –

Although not shown in this schematic, the encoder pushbutton for setting the tuning rate goes to digital pin 11 (pin 15 of this TQFP package). Also, the CLK outputs of the Si5351 don’t like DC voltage being applied. I fried one of these chips by accidentally applying 13.8V DC to the CLK 0 output. As a safeguard, it would be a good idea to permanently attach a coupling capacitor to the CLK 0 output of the Si5351. After my accident, I used as 0.1uF capacitor on mine. Some projects might require looser coupling, but you can always put a lower value capacitor in series with the output of this VFO to achieve this objective.

While planning this little VFO, a number of questions were presenting themselves to me. The main one concerned the issue of both the Si5351 Breakout Board and the OLED display being connected to exactly the same SDA and SCL connections. The I2C protocol does allow for multiple devices on the same line, but my understanding was that if more than one device is employed, then the firmware needs to include the unique address of each device. Would Thomas’ sketch work from the get-go, I wondered? As it happened, it did and, as of writing this, I don’t know if this is because

a) the address of the OLED was included in the library definition for this little display, or

b) with a setup like this that only has 2 devices connected, the instructions for the OLED are ignored by the Si5351, and vice-versa.

I’d like to be able to describe the exact steps I took when setting up the sketch, but I have, lamentably, forgotten them. I do remember installing the UG8lib library in the Arduino IDE, which supports the commonly available OLED displays. I also remember, at some point, uncommenting a line that specifically refers to devices that have an SSD1306 driver chip. If you purchase a cheap monochrome 128 x 64 OLED, this is probably the driver chip your display will have. These little displays are available for <$3 including shipping. Deal!

Here’s the ATMega328P mounted on the breakout board –

The controller part of the circuit constructed, with it’s supporting components. No power supply yet, as during initial testing, it will be powered through the ICSP header –

And with the Etherkit Si5351 Breakout Board fitted. The I2C control lines and 5V supply line are connected underneath the Etherkit board –

It took a while to figure out how to mount the OLED to the front panel. The 4 mounting holes are sized for #2 screws. I thought of running 4 #2 screws from the front panel, straight through to the OLED, and spacing the display away from the panel with 4 #2 nuts. The nuts were so close to the glass covering the display though, that they could have cracked it while being tightened. In retrospect, stacked #2 washers might have worked, though long before thinking of that, I came up with this rather more complex solution. It involved a small piece of PCB material, drilled and cut to size. #2 shakeproof washers and 3/16″ x 3/16″ nylon spacers were also employed. Their use should be apparent in subsequent photos –

I seriously considered fabricating a PCB enclosure for this little VFO, even getting as far as cutting some of the main pieces. The primary reason for wanting to use a custom enclosure was that the other case I was considering (which I ended up using) was a little too high. As a result, the front panel had, in my opinion, too much empty space. A PCB enclosure, about 4″ x 4″ x 1.5″ high would have looked mighty spiffy. However, I didn’t have the mettle to go through with it. I just couldn’t get quite inspired enough to put all that extra work into making a custom enclosure, and fell back on my favorite ready-made enclosure, the 143 from LMB Heeger. It is 4″ x 4″ x 2″ high, and available in plain aluminum finish, smooth light grey paint, or a sort of wrinkled black finish. They are also available with either an undrilled cover, or a perforated cover. The encoder was connected using header. The main reason for this was that I wasn’t sure if the cheap Chinese encoder ($1.68 each, inc shipping) was up to the task, so wanted to facilitate easy replacement –

A close-up, showing a little more detail of the mounting of the OLED to the front panel. Like the encoder, the display was also connected using header, making installation, and any dismantling for repair or upgrade purposes, easier –

Amazingly, it worked!

With the perforated cover you could, if you wanted, add some internal LED’s, for a splash of light to brighten up the shack, and add some flair. Being frugal energy-wise, I left the LED’s out for the time being. As it stands, the VFO already consumes 86mA at ~12V, which is not an insignificant amount –

Although the hardware side of this little project is finished (or very close to it), I am still very much fiddling with the firmware. As well as using Thomas’ code, I have been trying out sketches from other folk too. I began by trying to find a sketch that would do exactly what I wanted it to do, and fast discovered that, at the very least, an ability to modify code was required. That lesson led to a desire to actually develop a more complete understanding of C, so that I can at least do intelligent re-writes, if not write my own from scratch. This is all a bit overwhelming, and I vacillate from having fun, to being very grumpy, and back again 😀

Thank you Thomas LA3PNA for the sketch – and also to the many others whose code I have been borrowing, and will no doubt butcher. I view this little VFO very much as a learning platform, from a programming point of view. Also, a big thank you to Jason NT7S for the Etherkit Si5351 Breakout Board, and the very useful libraries, which are seeing much use from homebrewing hams.

PS – I just started reading “Beginning C For Arduino” by Jack Purdum. Great stuff.

UPDATE (Jan 30th 2021) – I made a few small changes to the sketch, to improve the display a little. I found a font to display the frequency, that is a little larger. It is in the U8G library, and is known as helvB18. I also removed the word “step” from in front of the step size, as I felt it was self-explanatory. The text needed to be moved around on the display a little to fit it in, and this was adjusted in the sketch.

Since building this little clock generator, I noticed that, although the sketch set the Si5351 to start up on 7030KHz, it would nearly always start up 100Hz higher. Unsure whether this is a software or hardware issue, I did the clumsy workaround of altering the sketch to start up on 7029.9KHz. As a result, it now starts up on 7030KHz. I’d like to find the reason for this discrepancy, and fix it at the source.

I also added a 5mm red LED inside the case, with a 1K resistor in series with the +ve lead, connected to the 12V DC power connector on the back. The LED lights up the whole inside of the case, though this is not so obvious in the daylight shot below – 

However, when used indoors, the red light is visible through all the perforations in the case, and looks great. It’s almost reminiscent of the old tube days. The red light effect actually looks a bit better in real life than in the photo. This Si5351 VFO/signal generator draws 105mA, of which 10mA is the LED –  

Although I’ve had quite a few thoughts about using it as a stable signal source for other projects, it’s very handy to have around the shack, just as it is. Calibrating receivers is a lot easier with this accurate signal source. I didn’t run the calibration sketch but, through a process of trial and error found a correction integer to place in the sketch, that places the VFO to within a few Hz, as verified by beating the output against WWV.