Menu:

• Main
  

Stretching the ZL2PD SugarCube Si5351 VFO Display

Do you like getting something extra for nothing? Here's a version of my SugarCube software that delivers a full screen of graphics on a larger 0.96" 128x64 OLED display. And it requires no extra bytes of program memory! And as a bonus, I've added extra tuning steps as an extra treat.. 

Introduction

My SugarCube VFO family has proven to be very popular. There are now many different versions and variations of the original SugarCube (“SC”) VFO described here on my website. They use a small low cost ATtiny85 8-pin microcontroller and the very popular Si5351a three-output PLL oscillator chip.

 


Most of my SC VFOs use a small OLED display, either a 0.91” 128 x 32 pixel display or a very compact 0.49” 64 x 32 pixel display. The compact dimensions of the SC oscillator has made it particularly useful for compact receivers and transceivers. I have also shown elsewhere on my website how the SC can be integrated into a number of different small portable HF transceivers.

This latest version of SC software delivers a screen-filling display on the larger and most common 0.96" 128x64 pixel OLED. And I managed to fit it into the existing 8k program memory space without requiring a single extra byte to generate the double-size stretched graphics.  

All of the usual standard SugarCube features are user-programmable. The user-defined parameters are usually stored in the ATtiny85’s EEPROM. To make things even easier, I've added an EXCEL spreadsheet to generate this file with a single click of a mouse button.

But first, let me explain how all of this came about...

The Double Height Issue

Recently, Eric ZL2BMI emailed me to describe a problem he’d encountered with the SugarCube VFO. Some time ago, he had discovered that several of his larger 0.96” 128 x 64 OLED I2C displays operated nicely with my standard SC software. My SugarCube VFOs are designed for use with more compact 0.91” 128x32 or 0.49” 64x32 pixel OLED displays.

Eric's 0.96” OLEDs would display the VFO’s frequency as usual in the horizontal i.e. X-axis direction, but expanded out at TWICE their usual height in the vertical Y-axis direction. To the user, it appeared as if the displayed pixels were stretched out vertically. The only other difference was that the brightness and contrast was slightly reduced.

The increased character height proved to be quite useful for some SugarCube VFO users. The frequency was much easier to read, and the slightly reduced brightness didn’t present a problem. This accidental 'feature' also allowed Eric to make use of some larger OLED displays in his parts bins. So, all good.

Until it wasn’t.

He soon discovered that it was not an effect that was reproduced by most 0.96” OLED displays in his parts bin or those ordered fresh from China. While this stretched display would reliably appear on a few OLEDs, it was not universally repeatable with any and all 0.96” 128x64 pixel OLED.

Eric emailed me to ask if I’d seen this issue. Was this a fault or a firmware bug in the 0.96” OLED embedded display controllers? In any case, was it possible for me to modify the SugarCube software in some way to deliver the useful ‘double height’ effect reliably on all 0.96” OLEDs if required?

The Investigation

Eric’s questions arrived at an opportune moment. I was in the middle of an interesting project but I was waiting on the delivery of some critical parts before continuing. Eric’s OLED issue was an ideal distraction to chase down while I waited for those parts. I began by testing several 0.96” OLED displays with the SC software that Eric was using.

The 0.49”, 0.91” and (most) 0.96” OLEDs incorporate a SSD1306 ‘silicon-on-glass’ controller. It’s bonded into each OLED display. Like others, I’ve discovered that not all displays are built to the same quality. This may be due to their widespread manufacture by a number of Chinese vendors with different quality standards.

I have encountered some OLEDs with what appeared to be ‘cut down’ controllers. These seemed to only respond to some of the standard SSD1306 command set. I’ve found others to be QC (quality control) rejects, also only responding sometimes to some commands. Some of these latter OLEDs had obvious rework marks suggesting they had been removed or recycled from other equipment before resale.


I initially thought Eric’s ‘double height’ display issue might be due to QC problems or, possibly, by the accidental use of the SH1106 controller in the display by the display vendor. The SH1106 is used in some larger 1.3” OLED displays. Although some vendors claim these are compatible with SSD1306 OLEDs, there are some important differences that sometimes prevent them being direct ‘drop-in’ replacements.

I also carefully reread the SSD1306 datasheet. This datasheet is not particularly well written. It gives rise to considerable speculation and variations between vendors and users particularly when it comes to initializing the display. At the same time, I carried out a series of tests using my standard SugarCube VFO software using a variety of different display subroutines.

Eventually(!), I found that the issue reported by Eric was not caused by either poor QC or through the use of a different embedded OLED controller. By careful step by step testing, I discovered I could reliably reproduce the ‘double height’ effect on demand. I could also see how to support a full size 128x64 OLED display for the SugarCube VFO with a bare minimum of changes to the original software.

To explain why this ‘stretch’ feature is a useful option, I first have to briefly explain how the normal OLED display is handled in software. If you have no interest in “looking under the hood”, just skip past this next section.

Text and Graphics on an SSD1306 OLED Display

All of the numerical characters, as well as the various graphics elements used on the SC display, are defined and stored in program memory. To make optimal use of the limited program space in the ATtiny85 and to make best use the available screen space on the 128x32 or 64x32 OLED displays, the numerals use a space-efficient 16x8 pixel font that I designed specifically for the project. Similarly, the various icons were each created using an efficient 8x8 pixel block.


Figure 3 : This typical 16x8 pixel character requires 16 bytes of program memory.

Usually, if these characters and icons were all to be doubled in size to allow double-height characters and icons to be displayed on the much larger 128x64 pixel OLED display, the memory required to store each element’s pixel data would double. I use a very efficient graphics storage scheme which requires about 300 bytes for the set of numeral and icon graphic data. If I designed a new set of conventional stretched 'double height' elements, that would require at least 300 bytes more program storage space.

Since I only have space in the ATtiny85’s program memory to fit the graphical elements for the specified 128x32 or 64x32 OLED display, and I am always within 3 to 30 or so bytes of the Atiny85’s program memory limit in all of the various SC versions, there is clearly absolutely no way in any sensible universe that I could ever hope to support a genuine double height display element set.

Yet, here we are. I can.

Double Height Characters Without Extra Program Memory

The key to this effect lies in the SSD1306 display controler initialization. To stretch the vertical height of the displayed pixels, the OLED Multiplexing parameter must be set as usual to suit the larger 128x64 pixel display i.e. 3Fh (This is set to 1Fh for 128x32 OLEDs). However, the COM Pin Configuration parameter is set for sequential operation which is the mode normally used with the 128x32 pixel display i.e. 02h (This is usually set to 12h for 128x64 OLEDs)

An important side-effect of this setting is that it effectively reduces the number of 8-pixel high rows in the 128x64 OLED from usual eight rows down to four addressable rows because this addressing mode skips sequential pixel rows. Importantly, this affects row addressing in the SC software. Row 0 now consumes the first sixteen rows of pixels (Usually addressed as rows 0 and 1 in the software), Row 1 consumes the following sixteen pixel rows (Usually rows 2 and 3), and so forth.


The stored display elements are all therefore automatically vertically stretched due to the additional alternate blank pixel lines. Usefully for us, these larger characters are created without any need for the additional program memory normally essential to deliver double height elements.

And so, with only a minor tweak to the SC OLED initialization, coupled with a few more changes to OLED row addressing values in the display subroutines, I can reliably achieve the desired height doubling effect on all standard 128x64 OLED I2C displays without requiring any additional code space.

Tuning Step Size Change

Of course, I had to add a ‘nice to have’ feature while I was down in the depths of the SC software. I updated the set of tuning step sizes to a more conventional 1-10-100 Hz – 1-10-100kHz – 1MHz tuning step selection. This change had been requested by a number of users but, until now, I did not have the code space in this early generation code. I took advantage of some code reduction measures I’d used with later SC software to permit this modification to be squeezed into the software.

The desired tuning step is selected as usual by momentarily pressing the tuning encoder shaft switch. Each press-release selects the next step size. The arrow icon displayed on the OLED, as usual, indicates the selected digit on the display.

The Prototype VFO Test Bed

In order to carry out all these tests, I constructed a ‘SC test bed’ using the PCB used in the SC+M VFO. This PCB had provision for a small TO-92 packaged 78L33 3.3V regulator. It also provided a little more space for connecting the various inputs and outputs. These use a series of standard 0.1” DuPont type connectors. Figure 5 shows the schematic of the final test bed SC VFO.

I mounted a 3k3 trimpot (It could have been any value from 1 – 100k) on the 3D-printed test bed to provide an adjustable voltage of 0 – 3.3VDC for quick testing of the S-meter function on the VFO. Usually, in a receiver or transceiver, the S-meter input is interfaced to the receiver AGC or the S-meter voltage that delivers the required 0 – 3.3V level for the ATtiny85 to convert to the OLED bar meter display.

I also fitted a USB-C connector onto the rear apron of the 3D-printed SC VFO test bed chassis to allow the use of an external 5VDC power supply. In normal use, the VFO can be supplied from 3 – 9V which can be wired directly to the 78L33 regulator. By adding a further series resistor (See the approach used in the SC+M VFO described elsewhere on my website), higher supply voltages can also be used.

A tuning knob was also 3D-printed for the test bed. It’s quite large but it’s a really nice size to use while doing lots of testing and it costs practically nothing to make.

The final 128x64 I2C OLED display was mounted using hot glue to the front panel. A short four-wire cable connects this to the PCB using DuPont connectors. Note that the Ground and +3V wires are swapped over between the two ends of this short cable.

 
Three small pushbuttons (PTT – VFO A/B – Lock) were then mounted on a small PCB along with several resistors (See the schematic in Figure 5 for details) and this was then also hot-glued to the front panel. A small piece of prototyping board could also be used for this.

I designed a small front panel label for the testbed. This was printed out, covered in transparent self-adhesive film, trimmed to size with a sharp modelling knife, and mounted on the test bed front panel using double-sided self-adhesive tape.

A short length of stereo audio coax was used to connect the two VFO outputs to the pair of panel mounted female SMA coaxial connectors on the rear apron. I noticed a little stress on the soldered connections at the PCB connector end of this cable. These soldered joints and the cable tails were covered with a blob of hot glue to add some rigidity to resolve the problem.

The VFO PCB and the remaining assembly details are shown in Figure 7. The completed PCB simply drops into the space provided for it on the test bed. No glue is necessary – It is rigidly held in place by the wiring. It can be swiftly and very easily removed for any necessary changes, typically for reprogramming the ATtiny85.

Programming the ATtiny85

The ZIP file containing the software can be found in the Downloads section below. It includes the HEX and EEPROM files. The fuses should be set as follows: HIGH=&05F  LOW=&0E1. The fuses should be programmed last because these remove the reset functionality from pin 1 of the ATtiny85.

If you wish to reprogram the chip, you will need to use a HV fuse eraser first to reset the fuses. The full description of how to build your own low cost fuse eraser can be found here on my website.

User Programmable Parameters

The following VFO settings are stored in the non-volatile EEPROM in the ATtiny85 and can be changed by the user:

• Reference crystal frequency e.g. 25.000000 MHz (Calibration for Si5351a crystal)
• VFO A Start Frequency e.g. 14.100 MHz (VFO A begins here when power is applied)
• VFO B Start Frequency e.g. 3.650 MHz (VFO B begins here when power is applied)
• IF Offset e.g. 12.00MHz (or 0 if you are using an SDR or direct conversion radio)
• BFO/CIO for VFO A e.g. 12.002850 MHz (to give USB for example)
• BFO/CIO for VFO B e.g. 11.997300 MHz (to give LSB for example)
• The oscillator mixing method used (i.e. high-side, low-side, inverted, or no offset) is independently programmable for the transmit and receive modes for both VFO A and VFO B

Frequencies are stored in Hertz i.e. 3.650MHz is saved as 3650000 and the mixing settings are set by storing values of 0 , 1, 2, or 3 for the respective VFO operating modes.


There is also a new Excel spreadsheet available (See Downloads section below). This can be used to quickly configure the VFO with the frequencies and settings for your specific requirements. The spreadsheet can also generate the required EEPROM file for programming the ATtiny85 with a single click of your mouse.

Final Remarks

Special thanks must go to Eric ZL2BMI for his timely email which kicked off this successful little project. He also very kindly independently tested the final software to verify the software changes also worked correctly with a number of other standard 128x64 I2C OLED displays.

And the very next day after this little task was completed, the parts for my other project arrived on my bench.

Perfect timing!

Downloads:

Double-Height 128x64 OLED SugarCube VFO software (HEX program file and a sample EEPROM file)

EXCEL spreadsheet for this SugarCube VFO to generate an EEPROM file for your specific requirements (ZIP Excel spreadsheet) Note: You MUST enable macros in Excel as you are opening the Excel file for the single-button EEPROM file generation to work.

3D-printed VFO test bed chassis (ZIPped STL file)

3D-printed VFO tuning knob (STL file)

Gerber files for the SC+M VFO PCB (ZIP file)

Front panel label (JPG file)



Questions? Send me an email. I'll try my best to answer as soon as I can. Keep in mind I may busy on my workbench designing something new, away on holiday, or dealing with a family crisis such as a lightbulb that needs to be changed, or if the internet has stopped working.

Want to go back to the main page? Click here to return directly.

© 2026 Andrew Woodfield ZL2PD
Template design by Andreas Viklund