Arduino C++ Investigations - Introduction

As mentioned in the last Wideband Transmission, I recently viewed a presentation from CppCon 2016 which convinced me that a lot of my preconceived notions about the (lack of) suitability of C++ for use in microcontroller applications might be misplaced.

The standard lore (go ask Wes Hayward W7ZOI his opinion of lore) states that C++ is inefficient in generating the compact binaries that are required when using a device with very limited program storage and RAM space, as you will find with microcontrollers (especially 8-bit controllers). Given that C is a probably fairly categorized as a mid-level language, and that C++ easily falls into the high-level language category with its much larger feature set, it seems natural to believe that there has to be an overhead cost to pay when using C++ over C. Yet, if you take the time to watch that video, you can see that it is possible to use advanced features of C++ and incur little to no overhead in the binary.

Not to say that you can just blithely use C++ without the possibility of incurring an overhead penalty. I've tried it and had some horrible results, and chalked my experience up to the old lore being correct as a general case. But that's obviously not true.


What I intend to do with this series is to look into ways that the features of C++ (mostly C++11 at this point) can be leveraged in the Arduino environment to take advantage of the advanced features of the language (and perhaps even things such as the Standard Template Library) while incurring no or perhaps a very small penalty in flash and RAM usage.

As most of you are probably aware, Arduino is based on C++, and every Arduino library coder has to use at least minimal C++ functionality in order to create a library. However, in the name of abstracting away much complexity, Arduino sketches are written more in C-style than modern C++. That being the default case, there's no reason we can't incorporate more C++ coding techniques into our Arduino sketches, as long as doing so serves our purposes of being able to use the higher-level abstractions without paying a penalty.

Before seeing the above presentation, I had already been thinking about this topic because good old Hackaday has been running a series of articles about it. While I may cover some areas previously addressed by said articles, I notice that many (but not all) of the previously mentioned posts don't delve into making the measurements of how implementing the C++ coding patterns affect code and RAM size (or perhaps execution speed). Data is king, so I intend to provide as much of it as possible so that you can see actual proof of the effects of migrating to C++ coding.

Just so you know where I'm coming from, let me tell you about where I'm at in my journey as a coder. I've been writing C for microcontrollers for a fair bit of time now, and I think I'm at least proficient at it, but not an expert by any means. I've dabbled in C++, but never really written any major programs in it, so I'm on a learning journey here as well. I'm sure I probably won't do everything perfectly or the most efficiently, but by holding to what the data tells me, I think I can provide some useful information to all while I learn some new things for myself.

Areas of Investigation

At this point, I don't have a list of topics for this series that is set in stone. I do have some initial ideas for investigation, but plan to follow other leads as they present themselves and as I learn more about this topic. From my initial notes, here are some potential topics you may see in future posts:

  • Using constexpr
  • C++ Standard Library and Standard Template Library usage
  • Using lambda functions/inline functions
  • Variable declaration: auto vs explicit
  • Other C++11 features, such as the new for loop syntax that functions as a foreach

Please feel free to comment below if you have some other topics of potential interest.


In order to maintain consistency across the series, I intend to use the same microcontroller platform in all articles. The controller of choice will be my Empyrean Alpha board, which is basically an Arduino Zero minus the debugging circuitry on a form factor that can be plugged into a solderless breadboard, just like the Arduino Nano and related products. The Empyrean Alpha uses an Atmel ATSAMD21G18A microcontroller, which runs with a 48 MHz clock speed and has 256 kB of flash program memory and 32 kB of RAM, which is ample for many types of projects.

Hopefully in the near future, I'll be selling the Empyrean Alpha and its little brother Beta through Etherkit, so stay tuned for further news on that.

The Arduino environment for ATSAMD microcontrollers uses the arm-none-eabi-gcc toolchain, which has a variety of very nice tools that are available in addition to the compiler. One of those is arm-none-eabi-size, which can give a breakdown of the flash and RAM usage of a sketch simply by feeding it the file name of the ELF file that the compiler generates. For example:

jason@oberon /tmp/arduino_build_994621 $ arm-none-eabi-size -B foreach_test.ino.elf
   text    data     bss     dec     hex filename
   9732     256    1780   11768    2df8 foreach_test.ino.elf

From the above, you can see the text section, which indicates size of the program in flash memory, the data section, which is the initialized variable storage in RAM, and the bss section, which is allocated but uninitialized variable storage in RAM. Pretty easy to use and interpret. We'll talk about this tool a bit more in the first investigation so that we have a good understanding about it.

Most likely, I'll also be using the Compiler Explorer tool, as was used in the video above. It looks like a very handy way to quickly and roughly demonstrate how code changes affect the assembler output from the compiler.


Now that we have the preliminaries out of the way, I'm ready to start tackling this series. Watch this blog for the first installation, which will be coming soon. My patrons will have early draft access to articles in the series, and will have a chance to chime in there with suggestions to help me with the final article on See you soon!

Wideband Transmission #10


If you've been reading my blog for any amount of time, you've probably observed that I'm a big fan of all things open source, especially on the hardware side of things. One area where OSHW seems to be lagging a bit is in the test & measurement department, so it was a very pleasant surprise for me to stumble upon a fairly new channel on YouTube about a month ago.

As you can see from the first video, the presenter (sorry, I couldn't find the name of the bloke who makes these videos) gives an overview of the cheap logic analyzers on the market that can be loaded with open source firmware and then gives a very detailed demonstration on how to use the devices with the nifty open source Sigrok T&M suite (especially the PulseView GUI tool) and how to use a Linux environment and scripting to take measurements.

If you have any interest in this space, this is definitely a channel to which you should subscribe. There is also a show notes site that has links and other resources for the videos.

Using C++ in Arduino

In another case of me stumbling upon something which takes me down a rabbit hole, last week I was watching coding videos on YouTube when this one was recommended in the comments of another:

It's quite a long video, but if you have any interest in coding and are an old fart who grew up with 8-bit personal computers (or are at least a fan of retrocomputing), then the time will pass quickly on this one. It sounds crazy, but the presenter (Jason Turner) of this talk was able to make a game for the Commodore 64 in modern C++! The way he did it was to create a tool to convert from the 80386 flavor of x86 assembler to 6502 assembler (well really 6510 in this case), which apparently is more feasible than you may think. His development environment is an online tool called Compiler Explorer, which for some reason I only learned about with this video. It automagically spits out assembler from C++ compiled from a variety of different compilers. In this case, the Turner created a custom local version of this tool to do the 6502 conversion.

I was gobsmacked at multiple times in this video. Many of the newest C++ features (from the C++17 standard) were used. With some careful coding, Turner was able to produce code with literally no overhead from all of the C++ features. The compiler was able to optimize many lines of C++ down to a handful of assembler op codes. Just watch it, you'll be amazed as well.

This video, in conjunction with the series of posts that Hackaday has been running about using C++11 in Arduino, has convinced me that it would worth it to investigate the use of C++ in the Arduino coding environment. Arduino library coders already have to use a base level of C++ when they write for the ecosystem, but most people who write sketches do it in vanilla C-style (well, the bastardized Arduino version of it anyway). After seeing that talk, I had a lot of preconceptions of C++ overhead blown away. The ability to use the modern features of C++11 sound tempting indeed, so I plan to do some investigations into the feasibility of incorporating more C++ patterns into Arduino sketches, and I'll be posting my findings here. Stay tuned.

KiCad PCB Rendering Tool

I have a habit of skimming my RSS reader (yes, I'm one of those old fogies who still uses one) in the morning while drinking my coffee, opening tabs of interesting things to examine in further detail later, while simply reviewing the rest of the new posts. Sometimes that means it takes me a bit to get back around to something intriguing among my many browser tabs.

Such is the case with this article from Hackaday. It's just a short blurb about a new open source Python tool for making 2D renderings of KiCad boards. The attached demonstration image certainly looked nice. When I finally got around to downloading the code from GitHub and trying it out on one of my designs, I was pleasantly surprised. The script made a very sharp SVG rendering of my board, but unfortunately, there are only a handful of components in the PcbDraw-Lib library, which meant that most of my stuff didn't get rendered.

Since I've been looking for a way to make nice illustrations of my PCBs for documentation and promotional purposes, I decided that I'd invest some time in adding components to the library, since I think the project has a lot of promise. After about half a day of muddling through making component drawings in Inkscape by studying datasheet engineering drawings, I was able to output a complete render of my Empyrean board, which you can see above. I'm quite happy with the result.

I've got a pull request in for the components that I've created so far, and as I continue to use the tool and fill out more of the library, I will continue to submit them upstream. While it's still pretty rough around the edges, this project gets a strong recommend from me.

Market Research

It has been awfully quiet on the public front here for sure, but I have been working on quite a bit of things behind the scenes here at Etherkit Galactic HQ. It's been a challenging year since I last wrote about the personal things going on here, but things have been going reasonable well after a rough half-year immediately following that post. I'm just about ready to attempt to revamp Etherkit, however there are still a few challenging roadblocks to overcome, and I could use a bit of guidance.

The most difficult issue is trying to re-bootstrap the business financially. I'm currently only selling the Si5351A Breakout Board, which obviously isn't enough to expand a business upon. The possibility of a capital infusion unfortunately broke down, and so the only practical way forward at this point is most likely another crowdfunding campaign.

As mentioned in the opening paragraph, I have been working on various projects, and so I do have some candidates. Many of the projects that are in the works or only even in the planning stages require the use of a microcontroller, and so last year I decided to make my own Arduino-compatible microcontroller board family which I can then use as the heart of many of these products. I've taken a real liking to the Arduino Zero because of its speed and features, but the cost is fairly high and the standard Arduino form factor isn't great for many purposes. Therefore, I have decided to make a new standalone board derived from the Zero which I call Empyrean, and you can see in the photo at the top of the post. It comes in two flavors: Alpha and Beta. The Alpha is based on the Atmel ATSAMD21G18A microcontroller, same as the Arduino Zero. The Beta uses a controller (ATSAMD21G16B) with a bit less flash and RAM than the Zero (but still more than an Arduino Uno), but is also priced similarly to the ATmega328 line of microcontrollers. Both come on a small board similar in size to the Nano and has nearly all of the same circuitry of the Arduino Zero except for the EDBG support.

It is true that there are a flood of Arduino clones out there and this makes entering the market with another one somewhat crazy. My value proposition for Empyrean is based on the confluence of breadboard-friendly form factor along with a wallet-friendly price. My target price point is around $15 for Alpha and $10 for Beta. While that is a fair bit more than your typical eBay Nano clone, Empyrean would also be quite a bit more powerful than a Nano, in both clock speed and available memory. So my question to you, dear reader, is whether you would be interested enough in this product to back a crowdfunding campaign in order to have it made? I do plan to make a serious push on a radio soon, but it would be nice to ramp up the business before that, while also solidifying the microcontroller platform that will be used in future products. Let me know what you think in the comments, or send me an email.

In the mean time, I thought I'd let you know that I'm working on a Rev D board spin of the Si5351A Breakout Board. You can see a prototype in beautiful OSHPark purple above. The most significant changes in this revision will be to change the coupling of the reference oscillator to the Si5351 XA input pin to meet datasheet specs and to panelize the board in preparation for future pick-and-place operations (they are currently hand-assembled!).

Perhaps even more interesting is that I also hope to be able to soon offer a frequency calibration report with every board sold. Thanks to LA3PNA, I am now in possession of a decent 10 MHz GPSDO to use as a lab reference, which will allow me to measure the frequency correction value accurately enough for hobbyist usage. I now have a small printer on hand, and so now what I need to do is add new code to my board test script to measure the correction value and print it for inclusion with each board sold. Stay tuned for notification when I'm ready to go live with this; hopefully soon.

Let me reiterate: I'd love to hear your thoughts about the above proposals. I'm interested in serving the needs of my customers. Thank you!

Break My New Library

I know that the updates here have been extremely sparse. For that I do apologize. Things are slowly starting to settle into a new normal around here, and I've been able to regain the ability to put time back into work. There's a large to do list on my whiteboard, and many of the things on that list depend on improvements and bug fixes to the Si5351 Arduino library. So that has been my first priority as I dip my toes back in the water.

There were quite a few features of the Si5351 that the older versions of the library did not support, such as all of the 8 outputs of the variants excluding the A3 and the VCXO of the B variant. Also, there is a pretty big bug in how the tuning algorithm handles multiple outputs assigned to the same PLL, which causes tuning errors to crop up.

Therefore, I decided in one fell swoop that I needed to totally rewrite the tuning algorithm and add support for as many of the neglected features as I could before moving on to other projects involving the Si5351. Over the last month, I've been hacking away on the code in my spare time, and I'm glad to finally be able to announce that a beta version of the Si5351 Arduino v2.0.0 library is ready for public use.

Because it's such a drastic change to the underlying code, I'd like to have it in limited beta release before doing a final release via the Arduino Library Manager. So that means that if you would like to try it (and I encourage you to do so), then you'll need to install it manually, which isn't terribly difficult.

Go here and click on the green button on the upper right that says "Clone or download". Select "Download ZIP". Next, find where on your filesystem your Arduino libraries folder resides and delete the existing "Etherkit Si5351" folder. Inside the ZIP file you just downloaded, there is a folder entitled "Si5351Arduino-libupdate". Unzip this folder into the Arduino libraries folder, and then restart the Arduino IDE.

Since this is a new major version release, I took the opportunity to tweak the interface a bit, which means that you'll have to adjust your current code to work with the new library (but fortunately not too much). You'll find the details on how to do that here.

Please check out the updated documentation on the GitHub page, as it has been greatly expanded and should explain all of the new features in detail. Also, quite a few new example sketches have been added to the library, which you can find in the usual place in the Arduino IDE. I encourage you to try the new library in your existing projects, as it should be a bit more streamlined and stable. Also, there is plenty of opportunity to make new projects with the B and C variant ICs. If you do encounter any problems with the new library version, I would like to strongly encourage you to use the Issues feature of GitHub to let me know so that I can get on to fixing it as soon as possible. When I'm satisfied that there are no big show-stopper bugs in the code, I'll merge it to the master branch of the repository and tag it for release via the Arduino Library Manager, but I need help in testing it before I can do that.

Once there's a stable release of this version of the library out in the wild, then I'll be able to move forward with other projects based on this Si5351. With any luck, some more interesting things will be coming from this shack again in the near future. Thank you for all of your help and support!

Edit: an exclusive look into the development process:

Wideband Transmission #9

Arduino in the Cloud


I saw a recent post on the Make blog about the new cloud ecosystem for Arduino which has been dubbed Arduino Create. Since this will most likely be the future of Arduino, it seemed wise to get an early look at the platform. It includes quite a few features, but the most notable ones in my opinion are the Project Hub, Arduino Cloud (IoT infrastructure), and Web Editor. Arduino Cloud will allow you to connect your network-capable Arduino to the Internet to allow sharing of sensor data, remote control over the net; your typical IoT applications. The Web Editor gives you access to an Arduino IDE over the web. Your code is stored online, and a cloud compiler builds your project, so you don't have to worry about configuring that on your machine. However, you still have to install an OS-specific agent program on your PC in order to get the complied firmware from the Web Editor onto the Arduino's flash memory. The Project Hub is a project-sharing space, similar to, Instructables, etc.


I don't have much to comment on regarding Arduino Cloud, since I don't have any of the supported devices and cannot try it out at this time. The Web Editor gives me mixed feelings for sure. No doubt that this was created to compete with the mbed platform, which sounds awfully convenient from what I have seen. I like the idea of being able to easily save and share code with others, as well as having a standard set of build tools for everyone. However, the environment is obviously still in early stages, as there is no support for libraries to be added through the official Library Manager JSON list, nor for external hardware definition files to be used. I had some difficulties getting the Arudino Create Agent talking to my web browser in Linux Mint, and once I did, uploading seemed a bit flakier than it does on the desktop IDE. Of course, this is all still in beta, so rough edges are to be expected. Once they get the features of the Web Editor up to parity with the desktop IDE, it should be a very useful tool. Finally, the Project Hub looks nice, but I wonder if we aren't starting to see too much fragmentation in this type of service for it to be useful. Still, the one-stop shopping aspect of it all is very spiffy.

Something to Watch


Ham radio seems like a natural fit with the citizen scientist movement, so it pleases me to have discovered that some hams have created a platform to advance citizen science in an area where we are well equipped to do so. The new HamSCI website states its mission as:

HamSCI, the Ham Radio Science Citizen Investigation, is a platform for the publicity and promotion of projects that are consistent with the following objectives:

  • Advance scientific research and understanding through amateur radio activities.
  • Encourage the development of new technologies to support this research.
  • Provide educational opportunities for the amateur community and the general public.

HamSCI serves as a means for fostering collaborations between professional researchers and amateur radio operators. It assists in developing and maintaining standards and agreements between all people and organizations involved. HamSCI is not an operations or funding program, nor is it a supervisory organization. HamSCI does not perform research on its own. Rather, it supports other research programs, such as those funded by organizatons[sic] like the United States National Science Foundation.

They already have three listed projects that they are helping with: the 2017 Total Solar Eclipse, ePOP CASSIOPE Experiment, and Ionospheric Response to Solar Flares. The 2017 eclipse is of special interest to me, as totality will be seen at latitude 45°N here in Oregon, which puts it squarely over Salem; a place I will have easy access from which to observe (which also reminds me that I need to build some kind of solar observation device like the Sun Gun before August 2017).

I wish these folks the best and I hope they are able to make a useful contribution to science.

A Challenger Appears

A EEVBlog video popped into my YouTube feed yesterday that was of significant interest to me, and will probably be to you as well. Most of us who are into having a home test & measurement lab are well aware that the Rigol DSA-815 has been the king of spectrum analyzers for the last few years, due to the very reasonable cost paired with the decent amount of bandwidth and load of useful features that are included. Rigol seemed to own this market space since the DSA-815 was released, as the big boys of T&M didn't seem to care too much about serving us little guys with our small budgets. However, those days are probably at an end, as a new SA to rival the DSA-815 is on the cusp of release. Dave Jones gives a cursory review of the new Siglent SSA3021X, which looks like it will cost only a few hundred dollars more than the DSA-815 but may be significantly better in the performance category. I'd recommend watching the video below, but here's a summary of the points that interested me:

  • User interface seems to be heavily "inspired" by the Rigol DSA-815
  • The Siglent has significantly better DANL
  • 10 Hz RBW available on the Siglent vs 100 Hz on the Rigol (I've seen hints that the Rigol was supposed to have a 10 Hz RBW option, but they never released it)
  • Reference clock and PLL in the Siglent look better
  • The Siglent has a waterfall display available, which is missing from the Rigol
  • Dave spotted some potential unwanted spurious signals in the Siglent, but they were low level and his machine wasn't a release version either.

Also, don't miss Dave Jones in typical Dave Jones-style refer to a signal with unwanted sidebands as a "dick and balls".

My impression is that if Siglent can tighten up the fit and finish of this spectrum analyzer, it could give the DSA-815 a real run for its money. This is nothing but good news, as more competition in this space will mean even better products for us in the future. I'll be watching this one.

Fun with Marbles & Magnets

Finally as a palate cleanser, enjoy this clever kinetic artwork contraption built to play with marbles and magnets!


200,000 Miles Per Watt

If you wouldn't mind, I would like to draw your attention to my latest post on the Etherkit App Notes blog. In it, I detail how to create a 10 milliwatt WSPR beacon using nothing more than the Etherkit Si5351A Breakout Board, an Internet-connected PC, and a low-pass filter. A simple project, but one that gives quite a bit of fun testing the ionosphere given the cost and complexity.


I don't want to take away from the post, so I will advise you to go there to read it, but the bottom line is that with about 10 mW, I was able to get a signal decoded over 2000 miles away. I remember reading the old exploits of the QRPp gang in books like QRP Power, where you had to be really dedicated, organized, and good at decoding CW in the worst conditions. Now, we have the luxury of a mode like WSPR, which lets us do milliwatt propagation experiments without breaking a sweat.

One idle thought I had about this is whether it would be feasible to put this transmitter on the 13 MHz HiFER band (check out Dave AA7EE's excellent treatment on the matter) and whether that would be something that would be fun and useful for schoolkids to experiment with. Of course, it's technically feasible, but I would want to be sure that 1) it's legal and 2) there would be interest in doing it. A single PCB could be made with one Si5351A output attenuated to around 4.6 mW and low-pass filtered for transmit, while another output could be used to drive a simple fixed-frequency receiver based on the SA612. Let me know what you think about this in the comments.

Wideband Transmission #6

Happy New Year 2015!

2014 was a bit of a mixed bag here. It's been a transition year for Etherkit, as I reorganize and reorient the business for a renewed push to get the CC1 and other new products to market. I believe that good things are beginning to happen there.

On a personal level, my two boys have been doing fantastic. Noah started preschool and is really enjoying it. Eli is at a bit of a difficult age (the Terrible Twos) and is between baby and little kid, but he's got an amazing personality and is growing up so quickly. Jennifer and I celebrated five years of marriage and 11 years since our first date! Things haven't been perfect in the extended parts of our families, but at least in our household we've all been pretty healthy and have been able to enjoy many blessings.

Si5351A Breakout Board Campaign

There have been a fair number of neat projects I've seen using the Si5351A Breakout Board that I posted on OSHPark, along with my Si5351 Arduino library, which is absolutely wonderful. However, I realize that it's a pain to order PCBs and all of the parts separately, and that a kit or a finished board would be ideal.

I've decided to try something new in order to bring the Si5351A Breakout Board kit to market: we're going to try crowdfunding the first batch of kits. I'm going to set a modest goal to trigger the funding, but all orders will be welcome over the goal amount. In fact, I intend to set a stretch goal at some higher funding level to devote a certain number of hours to improving the Si5351 Arduino library, including:

  • Add tuning from 8 kHz to 1 MHz
  • Add tuning from 150 MHz to 160 MHz
  • Fix the bug that does not allow output over 125 MHz
  • Implement access to the phase register
  • Implement sub-Hz tuning for modes like WSPR
  • Other bug fixes

I also intend on lowering the BOM cost by removing the broadband output transformers, and offering multiple variants of the kit, including the option to add SMA connectors and a TCXO. I'm composing the campaign on Indiegogo right now, and I'm shooting for a launch in about 10 days. I'm hoping to gain experience with this campaign with the goal of using it to fund CC1 kitting later in the year.

Why am I telling you this now? Because I would like to let those of you are are interested in purchasing one (or otherwise interested in supporing Etherkit) get advance notice so that you can order on the first day that the campaign goes live. This will help to give the campaign more momentum and perhaps help to spread the word further. I will be sure to make a blog post here when the campaign goes live and tweet about it as well, so keep an eye on those channels if this is something that intrigues you.

Simple WSPR Transceiver using Si5351A

I came across this simple WSPR transceiver from KC3XM driven by one of my Si5351A Breakout Boards via @wm6h and Dangerous Prototypes. The WSPR transmitter is simply a BS170 driven by one of the Si5351 outputs, which is buffered by a logic gate and keyed by a standard PNP keying switch. Control of the Si5351 and keying of the transmitter is performed by a plain vanilla Arduino Uno (the code has been posted to GitHub).

This looked so simple to build that I had to give it a try. I quickly built up the transmitter portion, tacked on a 10 meter LPF (the original version is for 30 meters), modified the code for my callsign and grid, and changed the Si5351 output frequency to the 10 meter band. The transmitter put out nearly exactly 1 watt of RF (with only about 1.2 watts of DC input total) into 50 ohms and ran quite cool. Hooked up to my Moxon, it had no problem generating spots when pointed east and started on an even minute so as to properly synchronize. Fun stuff!

Generating PSK with an Arduino

If you haven't been following the blog of KO7M, you should be. Jeff has been doing a lot of experimentation with with NB6M and other home experimenters in Washington state, especially with stuff like the Minima and using microcontrollers in ham radio projects.

Lately, Jeff has been working on getting an Arduino to output PSK audio. He has a series of recent posts about it, but these two are probably the most important. The character timing is not quite right yet, but the basics of how to generate PSK via PWM audio signals are here. Good stuff!

Si5351 and Raspberry Pi

Another really great homebrewer blog is M0XPD's Shack Nasties (oh you Brits and your silly names) blog. Paul has been doing a lot of work with the Si5351 as well, and his latest post about the Si5351 is details of how he interfaced it with the Raspberry Pi. Excellent information to have, as the RPi is of course much more powerful than your garden variety Arduino.

Si5351A Breakout Board Update

I've had a good response to the Si5351A Breakout Board when it was posted on Hackaday last month. There have even been a few folks who went through the trouble of ordering PCBs from OSHPark so that they could build their own copies of the board for experimentation. One of them, Tom AK2B, even constructed a complete receiver using the Si5351A Breakout Board and the RF Toolkit modules from Check out the link to the nice-sounding audio in the embedded tweet below.

When the link to the Breakout Board was posted on Hackaday, I wasn't even sure that anyone would be interested, so the design was not as robust as it should have been for public use. But thanks to some suggestions from Tomas OK4BX and some of my own ideas, I've created a Rev B Breakout Board that has a number of improvements.

Si5351A Breakout Board Rev B
Si5351A Breakout Board Rev B

I increased the size of the board by 10 mm on the short side in order to accommodate some new circuitry. I could have kept the board the same size and put the new components on the back side of the board, but I thought it would be better to keep everything on the front. Thanks to Tomas' suggestion, I added simple MOSFET I2C level conversion so that the Si5351A can be properly interfaced with a 5 V microcontroller. I also added a 3.3 V LDO regulator and jumper blocks so that the I2C interface voltage and the 3.3 V source can be selected. The traces from the Si5351A to the output transformers were also screened with vias, which improved crosstalk between outputs by about -6 dB. I also increased the pad size for the SMT crystal in order to make it easier to hand solder. In addition, I added a provision for the crystal footprint to double as a footprint for a TCXO. So far, the crystal works fine, but I haven't ordered the TCXO yet in order to verify that it works as well, but I don't think there will be any problems as long as the crystal is working.

As I anticipated from a previous post, Adafruit has released their own version of a Si5351A breakout board. It looks like they use the same I2C level conversion scheme as my board, but that is where the similarity ends. The Adafruit board seems to be geared to using it strictly as a clock generator, where the Etherkit board is designed to be used in RF applications by providing output isolation via broadband transformers and screening of the output traces. The Etherkit board also has more flexible options for using the board in 5 V or 3.3 V environments.

You can order the new board from OSHPark here, and find the documentation for it on GitHub.

I need to do a bit more testing to ensure that everything is working as it needs to, but so far the preliminary tests look great. Assuming that everything with the new board checks out, there's a decent possibility that I will kitting at least one batch of these boards for sale. Stay Tuned.

Si5351A Breakout Board Documentation

I appreciate all of the interest in the Si5351A Breakout Board that I have available on OSHPark. I apologize for not having this available sooner, but here is a GitHub repository which hosts the KiCad design files and a PDF of the Breakout Board schematic, which lists the part numbers for the reference oscillator and the output transformers so that you can order your own. Also the few passives on the board are size 0805.

This, along with either the avr-gcc library or the Arduino library, should get you going in generating all kinds of clocks and local oscillators. While this board seems to work fine in interfacing with the 5V Arduinos that I have, I worry that comms might be iffy, so I'm going to add simple MOSFET-based level conversion to the next iteration of this board. Keep an eye on the blog for further developments in this area.

Si5351A Investigations Part 6

The theme of this blog post is not lots of tedious work, but refinement leading to good results.

First off, let's talk about the funny I2C address on the parts which I received from Mouser. Since Digi-Key has no order minimums and very inexpensive shipping available (in the form of USPS First Class mail), I ordered another batch of Si5351As from them so I could see if they would respond to the correct address of 0x60. Sure enough, once I received them and used the Bus Pirate I2C address scan macro, they came up on address 0x60. So it seems obvious that Mouser has some oddball parts; perhaps they were custom parts that inadvertently escaped Silicon Labs. I'm still waiting to hear back from Mouser about the issue, but in the meantime, I would recommend you order from a different distributor until they fix this problem.

I also decided last Friday to try to get my KiCad skills back in order and crank out a cheap and cheerful breakout board for the Si5351A. It didn't take me too long to get back in the groove and design a small, simple PCB that would make it easier to prototype with the Si5351A. The board is 30 mm x 50 mm, with three end launch SMA connectors on the right edge and the power/I2C pins on the other side. I've also added wideband transformers (Mini-Circuits TC1-6X+) to the outputs to isolate them from the breakout board. Below you can see the OSHPark rendering of the board.

Si5351A Breakout Board

They will hopefully be here in about a week or so (one of the benefits of living in the same city as OSHPark). Assuming that they work as expected, there's a chance that I may end up selling these as kits, so stay tuned if that interests you.

Now on to the best news. The last big question in my Si5351 investigations is whether it would be suitable for VFO usage in a standard amateur radio receiver, where it would have to be tuned rapidly. Having seen in a Silicon Labs application note that the Si5351 can be tuned glitch-free by locking the PLL to a fixed frequency and only changing the synth parameters of the attached multisynth, I set out to implement that in the Si5351 avr-gcc library.

Next, I ripped the AD9834 DDS and crystal BFO oscillator out of my last CC1 prototype and substituted the Si5351 for the VFO and BFO. Long story short, after a bit of tweaking, the part performed beautifully! I can crank the tuning encoder knob as fast as I possibly can, and I get no hint of any glitching or other tuning artifacts. The Si5351 has enough oomph to drive the BF998 dual-gate MOSFETs as well. Into a high-impedance, the drive level was over 4 Vpp, which is a decent drive level for that mixer. The only slight hardware change I had to make was to change the I2C pull-up resistors to 10kΩ and reduce the I2C clock speed down to about 100 kHz in order to reduce noise from the I2C line getting into the receiver. This change seemed to have no adverse affect on the tuning speed of the Si5351.

At this point, I believe I have investigated most of the main points that I wanted to look at when this first began. Wonderfully, the Si5351 appears to be a very suitable IC for use in all kinds of amateur radio applications. The multiple independent outputs is a superb feature, and has the potential to greatly reduce parts count and price in ham radio transceivers. I'm already thinking of many applications where this inexpensive, stable, and versatile IC can be used.

Even though the main objectives have been met, I'm still not done with this IC. I would like to look into further details, such as phase noise. I also have a lot of plans, such as building a new radio from scratch using the Si5351, possibly selling the breakout board mentioned above as a kit, and maybe even creating a more complete development board (which could be used as a wide-range VFO) by incorporating a microcontroller, LCD display, and encoder knob. Keep watching the blog for further updates.