I recently received this nice flowchart in email from Joe Marin, CO7RR which documents a method for programming the Si5351. It looks slightly different from the way I do it in the Si5351 Arduino library and I haven’t personally tried it, so I can’t vouch for its accuracy, but I wanted to pass it along in the spirit in which it was offered. I have seen different algorithms used by different projects, so I know that there is definitely more than one way to do it successfully.
This reminds me that I get inundated with requests for help and bug reports/feature requests for the various open source code that I maintain, and it’s kind of difficult for me to stay on top of all of that, plus work on developing new products, as I’m mostly a one-man operation. I do try my best and thank you for your patience, as I know I don’t answer a lot of you as quickly as would be ideal.
Anyway, hopefully this will be helpful to others. Thanks Joe!
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 seriesofarticlesaboutit. 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:
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
9732256178011768 2df8 foreach_test.ino.elf
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 nt7s.com. See you soon!
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:
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 hackaday.io, 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!
I enjoy writing up my projects, but it’s much better to get feedback to see that someone was actually able to take my writing and successfully duplicate my project. Via the Etherkit Twitter account, I received this from Tom Hall, AK2B regarding my last posted project:
Awesome work! Tom has been a great supporter of Etherkit from the beginning and I’d like to thank him for sharing his neat creations with the rest of us. It’s wonderful to see such a minimalist design perform so well!
More Coding Resources for Fun
I haven’t had a ton of free time here, but I do get snippets of time occasionally where I can sit with my notebook PC for a bit and mess around. As mentioned in some recentposts, I’ve been revisiting coding for fun, and I’ve stumbled upon quite a bit of new resources that are new to me and that I thought would be good to share.
The first one I’d like to mention is called Scratchapixel. I was curious about the mathematical methods behind 3D rendering, and some searching brought me to this exhaustive tutorial site. It’s not 100% complete yet, but most of the fundamentals of 3D graphics are already well-explained there. A fantastic resource if you are curious about the first principles of 3D rendering like me.
A related site is called Shadertoy. Not by the same people, but also related to the topic of learning 3D programming. Shadertoy is a web application that lets you play with shaders in C++ inside a web IDE that can be updated on-the-fly. It takes a bit of CPU and graphics horsepower to run comfortably, but if you’ve got the capacity, it’s worth browsing the demos on the site just to see the cool stuff you can create with it. This tool was created by Íñigo Quílez, who also has a really cool home page with lots of tutorials and whitepapers. If you like demoscene stuff, then definitely check it out.
Another neat find that I only recently discovered goes by the name of Rosetta Code. It bills itself as a programming chrestomathy site, which basically means that it’s a way to learn how programming languages are related in a comparative way. There is a large directory of different programming tasks, and each task page lists ways to implement a solution in a wide variety of languages. It’s a wiki, so not every page has every language implementation, but there’s obviously a ton of work put into the site, and most tasks have implementation in the major languages. Really fascinating and useful at the same time.
Finally, there’s The Nature of Code. This site hosts a free e-book download of the content, and provides a link to purchase a dead tree version if you wish. Here’s how the website describes the book:
How can we capture the unpredictable evolutionary and emergent properties of nature in software? How can understanding the mathematical principles behind our physical world help us to create digital worlds? This book focuses on the programming strategies and techniques behind computer simulations of natural systems using Processing.
That sounds right up my alley. I haven’t read the book yet, but I have skimmed it a bit, and it looks like the kind of things that I love: non-linear systems, physics simulations, fractals, and the like. When things settle down here a bit, I may tackle the book and re-write the sample code into Python. That would give me some more Python practice and force me to really think about the algorithms behind the text, not just blindly copying, pasting, and executing the scripts.
Let me know in the comments if you found any of these links useful or fascinating, or better yet if you know of other links in the same vein.
New Miles-Per-Watt Record Opportunity?
If you regularly follow science news, you may have heard of the Breakthrough Starshot initiative. In short, this is a study to create pathfinding technology that would allow the eventual launch of micro-lightsails with tiny mass to the Alpha Centauri system at a significant velocity (0.2c!) with a ground-based laser array. It’s probably a serious effort, as it is being privately funded to the tune of a whopping $100,000,000. No doubt, an extremely audacious undertaking.
Sounds interesting, but what does this have to do with radio? Well, obviously there’s the issue of how you can get a usable signal back to Earth across a distance of 4-and-a-half lightyears from a craft that masses in 10s of grams. I was wondering about that exact engineering challenge when I came across this article in my feed reader today. It turns out that someone has studied how one might use the Sun as a gravitational lens for lightwave communication across interstellar distances. Claudio Maccone, an Italian physicist, has run an analysis and has determined that putting a receiver at distance of at least 550 AU from Sol will give the desired lensing effect for optical communications.
Speaking before Maccone at the Breakthrough Discuss meeting, Slava Turyshev (Caltech) pointed out that the gain for optical radiation through a FOCAL mission is 1011, a gain that oscillates but increases as you go further from the lens. This gives us the opportunity to consider multi-pixel imaging of exoplanets before we ever send missions to them.
That’s kind of amazing. Maccone calculates that the bit error rate of optical communication from at any significant distance from Sol quickly degrades to around 0.5. However, by using the Sun as a lens, the BER stays at 0 out to a distance of 9 LY. Here is a graph of the effect of standard comms and those enhanced by using the Sun as a gravitational lens, as calculated by Maccone:
What’s really crazy is this next paragraph:
But as Maccone told the crowd at Stanford, we do much better still if we set up a bridge with not one but two FOCAL missions. Put one at the gravitational lens of the Sun, the other at the lens of the other star. At this point, things get wild. The minimum transmitted power drops to less than 10-4 watts. You’re reading that right — one-tenth of a milliwatt is enough to create error-free communications between the Sun and Alpha Centauri through two FOCAL antennas. Maccone’s paper assumes two 12-meter FOCAL antennas. StarShot envisions using its somewhat smaller sail as the antenna, a goal given impetus by these numbers.
So that would have to rate as the ultimate QRP DX, eh? I’m not sure how realistic any of this is, but I’m pretty sure the physics are well-established by now. Kind of makes the Elser-Mathes Cup look like small potatoes.
As I mentioned toward the end of my post on the Python/GTK+ implementation of the Lorenz attractor, I ultimately wanted to add some of the other strange attractors to my program in order to make it a bit more interesting. So I did just that. It also gave me a good excuse to learn a bit more about how to use and layout widgets in a GTK+ application.
In addition to the Lorenz attractor, the program now will generate the Rössler Attractor and a plot of the behavior of Chua’s Circuit. The Rössler Attractor is another well-known system in the world of chaos theory, which you can learn more about by following the above link. Since I’m only plotting a 2D section of each attractor, I have to decide which view to display. In the case of the Rössler, I thought that the X-Y view was better than the X-Z view.
More interesting to me is the simulation of Chua’s Circuit, as this is based on an actual analog circuit you can build. The circuit is a chaotic oscillator that consists of the usual L-C elements (and a resistor plus limiting diodes) along with a nonlinear negative resistance circuit element. The negative resistance element is usually implemented with an active device such as an op-amp, although it has been reported that a memristor can also serve this function. The simulation is a system of three ordinary differential equations, much like the Lorenz or Rössler systems, but with a function in the first ODE to represent the behavior of the nonlinear negative resistance element. You can see in the code listing below that this was easy to implement in Python with a lambda function. It’s cool to see the pattern drawn on a display, but I think it would be much better to have an actual circuit render it on an analog oscilloscope. One day, I hope to do that, but in the mean time, enjoy these videos of the behavior of such a circuit.
As far as my additions to the Python code, I created a GTK DrawingArea for each attractor, then added them to a Stack, which allows them to be switched with the StackSwitcher widget at the bottom of the screen. For clarity, I also added a legend to each DrawingArea to display which axes are being rendered for each attractor, as the Rössler has a different view from the other two. This code is a bit longer than the initial iteration, but much of it is similar, since the calculation and plotting of each system is nearly the same (yes, I could have factored the code quite a bit, but this is just for fun). Another fun time with code was had!
Back in the day, when I was a budding nerd in the late 80s/early 90s, I spent a lot of my free time down at the local public library looking for any books I could find regarding certain topics which captured my interest: programming, astronomy, electronics, radio, mathematics (especially the recreational mathematics books), and other topics in the realm of science.
One of my fondest recollections of that time was how accessible that home investigations into some of these topics became due to the advent of the personal computer. Of course, in those times, not every household had some kind of computing device like they do today, but PCs were affordable enough that even a lower middle class house like ours could scrape together enough for a computer with a bit of work.
We also didn’t have widespread household Internet, so your options for getting new programs to play with were limited to the relatively expensive services like Compuserve, trying to find warez on bulletin board systems, checking out books and magazines with program listings from the public library, or perhaps if you were lucky, being able to check out a stack of 3.5 in floppies from the library (how were they able to do that with commercial software?). Of course, given the previously mentioned socio-economic status, I was mostly limited to the public library option. Although perhaps some day I’ll tell the tale of how I talked my parents into letting me get Compuserve, and then proceeding to rack up a huge access bill on my parents’ credit. Oops.
Of particular interest to me was the relatively new field of chaos theory and fractals. These studies were conceived a bit earlier than this time period, but were popularized in the public eye during this time. I got hooked in by the photos published in the groundbreaking books The Fractal Geometry of Nature, Chaos: Making a New Science, and The Beauty of Fractals. There were also plenty of articles in publications like Scientific American and the books of authors like Clifford Pickover. The wonderful thing about these resources is that many of them not only showed you the pretty photos of fractals and chaotic systems, but actually described and illustrated the algorithms behind them, which allowed you to code your own implementations at home.
During my early work in trying to recreate these forms in my own computer, I had an Atari 800XL with a dodgy floppy disk drive, which made any kind of coding a bit of an adventure as it seemed like my mass storage old successfully worked about half of the time (on a side note, who remembers the even earlier days, where you would type in a machine language monitor program in BASIC, and then transcribe strings of ML from a listing in a magazine in order to get a new program…good times). Things really got serious when we ended up acquiring a Tandy 1000 (I believe the RL version, but I’m not 100% certain about that). Once we had that in the house, I spent many late weekend nights trying to write code to reproduce the fascinating patterns found in the pages of those books. You know you’re a true nerd when you get such an electric thrill from finally mastering the code to generate a Sierpinski triangle or Barnsley fern in glorious CGA on your own monitor.
So what’s the point of this overwrought bout of nostalgia? Well, I was recently pining for the old days when you could just sit down at the PC and implement a chaos system in one quick setting with minimal fuss. Compiled languages with arcane GUI frameworks were right out. Fortunately, we are blessed with quite a few good replacements for the old BASIC environment. My favorite is Python, and since I use Linux Mint as my primary desktop OS, the GTK+ 3 libraries for Python are already included by default, so it’s quite easy to get a rudimentary 2D graphics system up and running quickly.
For my first chaos system coding challenge, I decided to go with the great-granddaddy of chaos: the Lorenz attractor. It’s an easy system to compute, and it’s quite obvious if you get the implementation right or wrong. Once I got the hang of the GTK+ 3 library interface, it didn’t take that long to bang out an implementation of the Lorenz attractor in relatively few lines of Python. The simplicity is satisfying, and reminds me of the fabled old days of coding.
There’s the code if any of you would like to play around with it. It should be fairly easy to replicate if you are using any of the Debian-derived Linux distributions, and probably only marginally more difficult with other Linux distros. I have no idea what it would take to get running on Windows, so good luck if that’s your OS of choice.
Now I have a framework to build off if I get a further itch for similar experiments. I’m already working on an extension to this code that will render other attractors. It would be fun to find a 3D rendering library that would be easy to use so that I could plot in three dimensions, but that’s not hugely critical to me. This is just an exercise to have some fun, capture a bit of that nostalgia, and distract myself a bit during downtime. Hopefully a few of you kindred souls will have derived some enjoyment from this trip down memory lane.
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.
A few exciting developments here on the Si5351 front. First off, I took the C code from my Si5351 library for avr-gcc and converted it to an Arduino/C++ library, which you can find here. It replicates the functionality in the avr-gcc library, but makes it quite a bit easier to rapidly implement designs. I’ve tested this design on an Arduino Uno and an Arduino Uno clone, but I see no reason why the library shouldn’t work on other Arduino variants as well. Please give it a try and leave feedback on the GitHub page if you find bugs or have suggestions for improvements.
The other news is about the Si5351 Breakout Board that I mentioned in the last post. I just got the 3 purple PCBs back from OSHpark and they are most excellent.
I got one quickly populated with components and paired it with an Arduino in order to test the new library. As you can see in the photo at the top of the post, it’s a pretty small little board, but it’s pretty powerful for its size. All you do is connect VCC, GND, and the I2C SDA and SCL lines to the Arduino, and you get three independent transformer-isolated outputs on SMA connectors that can generate 1 to 150 MHz (in the future the library will be modified to allow the full 8 kHz to 160 MHz range)
Will I end up selling these as a kit? I’d like to but I’m uncertain at this point. Oddly enough, I just found out that it’s highly likely that Adafruit will also be selling a Si5351 breakout board. If you watch the video below at about the 6:22 mark, you’ll see it.
I’m a bit surprised by this, as RF is not something that I was aware that Adafruit was interested in. To be honest, it will be difficult to compete against the relatively much larger fish in the hobbyist pond that is Adafruit. Although, it looks as though my breakout board has something that the Adafruit board does not: isolation output transformers. Most likely, I will do one trial kitting run and see if there will be enough interest for another after that. Keep an eye on the blog for further news about that in the near future.
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.
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.