Please enjoy this write-up of a nifty, compact signal generator project using the Etherkit Si5351A Breakout Board driven by a Teensy LC. What I really love about it is that it uses an 18650 LiPo cell with a small USB charge controller, so that it is very portable. Neat stuff!
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.
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.
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 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!
Back when I was working at Tektronix (wow, this summer it’s been 10 years since I graduated with a AAS in EET and started at Tek), they had a one-time program where an employee could purchase a new TDS1000/2000 series oscilloscope for half of the list price. This was back in the day before the era of cheap and decent Chinese-manufactured scopes, so naturally I jumped on the deal. Even though I wanted more, I found that I could fit the TDS1012 into my budget (list price was a bit more than $1000 at that time).
The TDS1012 was a very faithful instrument on my bench for many years. I came to depend on it quite heavily. Too heavily, in fact, as I left it on a lot. Not thinking about the ramifications of it at the time. A few years ago, the backlight in the scope started fading, and not long after that, gave out completely. I figured I could just replace the display module, but finding a replacement turned out to be more difficult than I anticipated. Tektronix repair didn’t stock it by the time that I inquired about it, and I could not find any through the back-channels that I checked with my Tektronix contacts. Even looking for NOS on eBay was fruitless (although later on, some grey market displays started turning up there for expensive list prices).
Eventually I gave up hope of realistically finding a replacement display and tried to sell the scope, although not very enthusiastically. The scope stayed in this state for quite a while, until I found something fortuitous. One of my favorite vlogs is The Signal Path, and Shahriar recently released a short video about repairing an VNA with a broken CCFL backlight with a LED replacement.
I’m not sure why it never occurred to me to try this, but I was grateful to have seen a path forward with the TDS1012. I didn’t even know that there existed LED backlight upgrade kits, but I shouldn’t have been surprised. Long story short, I ordered a handful of parts from eBay and took a chance, and was rewarded with a working display that was able to bring my beloved TDS1012 back from the dead! I’ll give you some details below so that hopefully this can be of help to others in the future.
Bill of Materials
LED Backlight Upgrade Kit (there’s a wide variety of these available on eBay)
XL6009 DC-DC Boost Converter
5 kΩ trimmer potentiometer
4.7 kΩ resistor, 0.25 W
The first thing to do was disassemble the TDS1012 so that I could get to the guts. Fortunately, I had done this in the past, so I knew exactly what to do. It’s actually quite easy to do in the home lab with just two tools: a deep Torx T15 screwdriver and a small pair of hook-nosed tweezers. Pry off the knobs on the front panel by wedging the hook-nosed tweezers in the gap between the knob and panel, and then using them as a lever.
Remove the back case from the instrument by unscrewing four T15 screws: one on the bottom-left, one on the bottom-right near the AC power connector, and two hidden under the fold-up handle.
Next, the front panel can be removed by unscrewing five T15 screws: one on each corner and one hard-to-find screw that is between the CH1 and CH2 BNC connectors (on the back of the chassis). You can see side where those screws need to be removed from the chassis in the photo above.
Once the front panel is off, you can now remove the display module. There are two cables to disconnect: the CCFL backlight cable going to the HV supply, which is on the top-left of the above photo, and the data cable which is on the right side (unseen in the above photo). Disconnect the CCFL cable and the data cable from the main board, and then remove the four T15 screws from the four corners.
Now with the display module removed, you can see where the CCFL lives on the left side, under the beige plastic. I removed the Kapton tape securing the CCFL leads to the module, and then tried to pry the plastic apart at what looked to be interlocking snap tabs.
That turned out to be a bit of a mistake. The plastic was quite brittle and broke on the back side, including a few fragments from each end that snapped off completely. I think I should have removed that tiny screw that you can see on the center-left of the front of the display module before trying to take the CCFL out.
There is some metallic foil that loops around the CCFL. I used a craft knife to slit it down the length of the display, freeing the CCFL from the module.
You can see the burned-out CCFL in the photo above, removed from the display module. Now that the defective part was removed, it was time to figure out how to rig up the new LED backlight.
Here you can see the LED module as packed by the seller. I was pleasantly surprised. Quite nice and secure.
And here is the LED kit. This kit was made for a 15 inch monitor, so I would only need part of the LED strip. As was the case with other LED strips I’ve used, this module was wired so that groups of three LEDs were in series, with each of those groups in parallel with each other. I cut the LED strip at a multiple of three at a size that would fit where the CCFL used to live. Be very careful with this strip, as it is quite fragile and could easily break at the length it is shipped (which I’m sure it why the seller packaged it so well).
Next, I lashed up the LED driver module on the breadboard to see how it should be wired. As is common with these eBay modules, the documentation is pretty lacking, so I had to put in a bit of work to make sure I got the wiring right. There are four input pins on this module: VCC, GND, ENB (enable), and DM (dim). A bit of experimentation showed me that you needed to tie ENB to VCC and that DM could be fed using a simple voltage divider with a trimmer and fixed resistor to provide an adjustable voltage to DM that ranged from about 0.5 VCC to VCC.
The product page recommends that the DC input be at least 10 VDC, and when driving it with >11 VDC the LEDs were quite bright. Any voltage below about 9 VDC, and the LED just won’t light. In a lot of instruments, that may not be a big deal, but it was a problem with the TDS1012. It turns out there is no 12 VDC available, nor anything even close. The only other appropriate DC voltages available from the power supply are 6 VDC and 3.3 VDC. But the module just won’t run on a voltage that low. I identified the IC on the LED driver module to be a DF6113. By the looks of the datasheet, it should be able to function as both a boost converter and constant current source for the LEDs, but this particular module will not run at 6 VDC.
A bit of half-hearted reverse-engineering showed me that while the DF6113 has the capability to function as a boost converter, that functionality was not being used here. In the reference design on the datasheet, it shows it being used as a boost converter with an LED output which is ground-referenced. However from what I could suss out of the eBay module, this one was configured to not be ground-referenced. Instead, the lower potential terminal of the LED driver was set at approximately 9 VDC lower than the input voltage, hence the reason why it would not function below 9 VDC input.
Rather than try to hack this module, I figured it would be easier to purchase a DC-DC boost converter module off of eBay from a US seller. After a few days, I had a XL6009-based module in hand, which looks to have a wide range of usable input and output voltages, and can easily source enough current to drive a small strip of LEDs. With the plan to drive the boost converter from the 6 VDC rail available from the TDS1012 power supply board, I set my bench supply to supply 6 VDC to the boost converter, set the boost converter to supply 12 VDC to the LED driver, and managed to get everything set up to light that LED strip from 6 VDC input. I just had to hope that the power supply had enough current margin for this LED strip, plus the losses in the boost converter and driver board.
Now that the LED has been verified to work correctly, it was time to fit it into the display module in the place where the CCFL used to be. With the CCFL removed, you can peer down into the cavity it has left behind and see the glass panel that diffuses the backlight. The LED strip was placed facing into the edge of this glass so that the terminals came out of the top of the module (where the old CCFL wiring ran), and I used RTV silicone to secure it in place. I chose RTV silicone for two reasons: it would be easy to remove if I messed up the placement of the LEDs and it would be reasonably transparent if I got some adhesive in between the LEDs and the glass. It appears that was a good choice.
Now I used epoxy (the cheap stuff from Harbor Freight) to seal up the plastic cover that I cracked earlier, mainly to provide mechanical stability and extra protection to the LED strip.
Once that was dried, I lashed everything up to breadboarded driver circuitry to ensure that the backlight was actually do the job. As you can see above, it looked good so far!
The real acid test for me was to see if the TDS1012 could actually drive the new backlight from its own power supply. I really had no idea if the current budget was there in the instrument, as there weren’t enough details in the service manual to know. So I had to just lash it together to try. The boost converter was soldered into the 6 VDC and GND terminals on the J9 connector on the power supply board, and then power was applied to check for magic smoke. Nope, success! BTW, if you are replicating this test, be sure to plug all of the modules together, as the instrument won’t power up unless all of the cables are connected.
Now the job was to stuff the boost converter, trimmer pot, and LED driver module into the existing chassis so that it was secure and safe. The modules were test fitted into spaces where they looked like they would conveniently fit, and then Kapton tape was generously laid down on the chassis to give them a safe mounting point.
Fortunately, both of the modules were small enough to fit quite nicely in existing space, and both were single-sided boards, which meant that they could sit flush against the Kapton tape easily. The modules and pot were secured in place using more of that epoxy (although hot glue would have probably also worked well).
The leads to the LED strip were routed back through the hole in chassis where the old CCFL leads went, and easily were able to reach the new LED driver module. After that, it was a simple matter to reassemble the instrument and power it on for a final smoke check.
Although not the most skillful of hacks, it’s always quite satisfying to recover something of value from the scrap heap with a handful of parts (about $15 worth in this particular case). I think the new LED backlight is actually brighter than the old CCFL backlight, but it has been a while since I’ve seen it with the original backlight, so that’s a pretty poor subjective observation on my part.
One small warning here: I have only done rudimentary checks to see what effect the DC-DC boost converter would have on the measurements from the scope. I don’t see any obvious hash from the switching power supply on the most sensitive vertical setting, but it’s possible that the this might introduce some low-level unwanted spurious into the instrument, which perhaps may be visible when using the FFT function. Caveat emptor. You have been warned.
So for those of you with older instruments with busted CCFL backlights, I would highly suggest that you can retrofit a new LED backlight if you have some moderate electronics skills. There’s nothing particularly magical here. The biggest concern is whether you can pull enough current from the existing DC power supply, but I imagine most instruments have power supplies that are designed to easily give up enough extra current to power a small LED strip without and difficulty. And if you have an instrument with 12 to 24 VDC already available, you can skip the boost converter that I had to use and not even have to worry about that. Give it a try and give some old junk new life!
Just a few days ago, I finally received some of the TCXO parts that I’ve been planning on using with the Si5351A Breakout Board. I had no problem using one on the remaining prototype circuit board that I have, and at first glance it appeared quite stable and also very close to the nominal frequency (my correction factor for this one was only 8 Hz at 10 MHz).
Direct comparisons are always the best way to do things, so I ran the Si5351 with TCXO through my thermal chamber at the same profile that I did in the last test in my initial blog post. Rather than write a whole new blog post, I updated the original post to keep that data together, which will be handy for future reference. Go forth and look at the update at the bottom of the original post. Thanks!
In looking through the analytics here on the blog, I noticed a search term that has been regularly coming up near the top: Si5351 crosstalk. Realizing that I haven’t yet presented data on this, it seemed like a good time to knock this one out, since it isn’t that difficult of a measurement to make.
It appeared to be a wise idea to choose output frequencies that were non-harmonically related, so I decided on the following outputs:
- CLK0: 22.444555 MHz
- CLK1: 10.140123 MHz
- CLK2: 57.456789 MHz
Each output was set to the maximum 8 mA current and each one was locked to PLLA, which was set at 900 MHz.
The measurement procedure was simple. I connected the spectrum analyzer to each output sequentially. The unused outputs were terminated in 50 Ω. For each measurement, I used a delta marker to measure the difference in amplitude between the desired signal from that output and the frequencies of the other two outputs.
Without further ado, allow me to present the spectrum analyzer plots.
I thought that perhaps these measurements would be a best-case scenario, and that leaving the unused output ports unterminated might produce even worse performance, but it turns out I was wrong. Below are the same measurements, but with an open circuit on the unused ports.
I’m not quite sure what to make of that. In practice, I haven’t seen any problems in my receivers so far that I can trace back to crosstalk from adjacent channels. Of course, this probably won’t do in a higher-performing receiver, but if you wanted to use the Si5351 in such a receiver perhaps you could find a way to put two or more on an I2C bus at the same time, then use only one output from each. My advice would be to turn off any channels you are not currently using, just to keep the other outputs clean.
I have no doubt that this data will be more ammunition for those who are convinced that the Si5351 is a terrible LO. I stand where I always have: this is an excellent IC for the price and you are hard pressed to find such capability and stability for such a low price anywhere else. If, knowing its limitations, the Si5351 meets your needs, then excellent! If not, that’s fine too. Neither I, nor anyone else I have heard, has suggested that the Si5351 is a panacea or a substitute for a better oscillator such as the Si570. It’s another tool to be put into our toolbox in the quest to stay relevant with the march of technology.
Quite a bit of work has been done in quantifying the performance of the Si5351 for amateur radio use, within the limitations of our modest home labs. Something that you don’t see done with a lot of other new components these days. Have I made mistakes or overlooked some things? Almost certainly. I’m still learning how to apply a strict measurement discipline over all of my serious building activities, so this is a learning process for me as well. If you have some constructive criticism of any of my measurements or feel that I have neglected things, I absolutely welcome an email or comment on the blog. Let’s try to hold ourselves to high standards as home experimenters without being unduly negative, as many of us continue in the journey of RF experimentation.
You may have seen in my previous post that I have been working on the latest (and hopefully final) major revision of the CC1. Many of the previous decisions on the radio architecture have been thrown out, perhaps most importantly the decision to use a dual-gate MOSFET as the mixer. In the quest for a replacement, I considered using the old standby, a diode ring mixer, but I wanted to be open to other possibilities as well. As shown in that last post, the KISS mixer from Chris Trask seems to have excellent intermod performance with relative simplicity. So the current plan is to try to build an IF chain using the KISS mixer and see if it will work well in the CC1.
Having quantified the performance of the KISS mixer, the current quest is to find an IF amplifier that will provide decent performance at a reasonable current “price”. With an IIP3 of approximately +30 dBm (I believe it should be able to get the mixer there with some improvements in components), the limiting factor for IP3 performance in the IF chain will be the IF amplifiers. Consider that my current goals for the CC1 receiver are:
- Dynamic range of around 100 dB
- Decent sensitivity (less than -130 dB MDS in 400 Hz bandwidth)
- Reasonable current consumption for portable use (< 60 mA)
In order to achieve this, I’ve determined (using the excellent Cascade08 program from W7ZOI’s LADPAC software suite) that the IF amp that I choose will need the following characteristics:
- OIP3 of at least +20 dBm (although higher is better since the amp is the limiting factor)
- modest gain
The current candidate for the IF topology is similar to the design seen in Figure 6.89 in Experimental Methods in RF Design, with no gain until after the first IF filter. To that end, I’ve been looking a various amplifier designs to see if I could find something that would fit (or at least come close to) the requirements above. Bipolar amps are nice, but use a lot of current. MMICs were another possibility; the ones I have found do have about +20 dBm OIP3, but with around 20 mA of current draw and approximately 20 dB of gain, which means the IIP3 is not that great. I figured it wouldn’t hurt to take a look at the dual-gate MOSFET again, as I know that at least they can use modest current and many have excellent noise figure.
Without getting into the weeds of every detail of the experiment that I tried, I’ll just recap the important parts. Initially I used a BF998 with an L-network on gate 1 to transform the 2.2 kΩ input impedance of the amplifier to 50 Ω. A pot was provided to provide variable voltage bias to gate 2. Different permutations of source resistor and gate 2 bias were tried, and the best IIP3 I could get from that amplifier was about -3 dBm (with perhaps 14 dB of gain). OK, but not great. So I decided to give the BF991 a try and see what I could get out of it. Again, I tried many variations of source resistor and gate 2 bias, and was able to find a configuration that is somewhat promising.
You can see in the schematic above that I settled on a source resistor of 100 Ω and “dipped” the gate 2 pot for best IP3, which came out at 5.6 V of bias. I also found in previous trials that leaving the source bypass capacitor out improved the IP3 a few dB and decreased the gain a few dB, which was a worthy improvement. Input and output was matched for 50 Ω. The current consumption was only 4 mA, which is pretty great for an IF amp in a portable radio.
Here is the capture of the OIP3 measurement from my DSA815-TG. Only 10 dB of gain, but that is OK as we wanted modest gain. The IIP3 measured +8 dBm, and when you add in the 10 dB of gain, the OIP3 is +18 dBm, which is pretty close to my original spec, and all for only 4 mA.
This all looks very reasonable. But there’s one problem. The good IP3 is highly dependent on VDD and VG2, especially the gate 2 voltage. As this is going to be a production radio, there needs to be a reliable way to set VG2 during calibration, every time. Also it appears that I probably need some way to keep VDD stable over a variety of voltage inputs, such as a LDO voltage regulator (maybe 9 or 10 V would work). But I need as much headway as possible in VDD in order to get the most out of my dual-gate MOSFET amp. In my experience, they don’t like being voltage-starved. There also appears to be a bit of dependency on the tuning of the input L-network, although that is not as pronounced as the other effects.
As it stands now, this is a promising candidate for the IF amp, but I’ll have to find a way to reduce these dependencies quite a bit in order for it to be viable for a commercial product. That’s my next line of inquiry, and I’ll be sure to have a follow-up post if I am able to get around the remaining limitations
Here’s the post I know that a lot of you have been waiting for. Buzz around the Si5351 has been picking up at a pretty rapid clip over the last month or so, but a lot of homebrewers have been hesitant to use it in their designs because one critical parameter has not yet been measured: phase noise.
Phase noise measurements seem to be one of the least easily accessible to the typical ham homebrewer, but fortunately for us, we have in our ranks some engineers with access to excellent T&M gear that most of us would never be able to afford for our home workbench. Thomas LA3PNA was able to put me in touch with one such engineer, John Miles KE5FX. I don’t know much about John, but I should, as it looks like he has developed the TimePod phase noise measurement device and the TimeLab analysis software (which is very slick, I must say).
John was generous enough to make a variety of phase noise measurements on the Si5351A Breakout Board that I sent him. Below, I present some plots of the phase noise measurement that were taken at various frequencies and under a few different conditions.
Before I get to a brief commentary, here are the plots. The first two plots were taken at 3 MHz, first with 2 mA output current then at 8 mA output current. Then you will find 10 MHz, 13.371 MHz (in both fractional and integer divider modes), 14 MHz, 100 MHz, and then a composite plot of all of the different traces.
I believe that the plots speak for themselves fairly well. If you compare these results to the receivers in the Sherwood Engineering receiver table, I think you’ll see that the Si5351 acquits itself quite nicely for such an inexpensive part. Personally, I think the Si5351 is eminently usable for many receiver applications, except perhaps the most high-performance. Certainly for the price, it’s going to be extremely hard to beat. I hope this motivates those sitting on the fence to decide if the Si5351 will meet their needs.
Finally, I would like to share a new video of the Si5351 in action, courtesy of prolific builder Pete N6QW. Here’s Pete having the very first QSO with his new SSB QRP rig built using one of the Adafruit Si5351A Breakout Boards:
I would like to sincerely thank KE5FX for taking the time to make these measurements for the community and for allowing me to share them with you. If you have any ideas for critical phase noise measurements that aren’t included here, let me know in the comments and perhaps we can get those made as well.
Edit: I failed to mention that these measurements were taken with a plain old 25 MHz ECS crystal as the reference oscillator. With a higher-quality reference oscillator, one would expect even better phase noise performance.
I’ve got a lot of project ideas rattling around my head. Got even more of them in my notebook. One of the projects floating around in there for years that seemed pretty cool, but not urgent, was an automated thermal chamber for oscillator stability testing, roughly based on the one seen at the end of chapter 7 of Experimental Methods in RF Design.
My interest was renewed a few months ago when Jennifer brought home some free Styrofoam containers from the vet’s office from Baxter’s annual checkup. They were nice and thick, as well as having straight interior walls, unlike the typical cheap beer cooler you find at the supermarket. Of course, Jennifer was thinking of using them for food, but naturally I had more nefarious purposes in mind for one of them.
The real impetus to build the thermal chamber was the realization that it would be extremely helpful in characterizing the behavior of the Si5351A. Taking mental stock of what I had on hand, I realized that I already had almost everything I would need to do the job. So this last weekend, I decided to build the chamber and put it to use characterizing the Si5351A. In these tests, I used the Si5351A with a cheap garden-variety crystal: the ECS-250-8-30B-CKM.
I don’t intend to do full write-up of the thermal chamber here (that will be coming in a separate post), but I will cover the basic design here briefly. The physical chamber is that veterinary Styrofoam cooler with rough dimensions of 25 x 30 x 30 cm. The device under test (DUT) sits in the bottom of the chamber. Over the top of that sits a shield constructed from pressboard and legs made from 2x2s which raises the shield to a height of about 9 cm from the floor of the container, and keeps the DUT from receiving much direct radiant heat. A 12 V PC cooling fan is mounted over a hole in the pressboard. There are also three other large holes on the outside edge of the pressboard, which allows the fan to circulate air between the upper and lower partitions of the chamber. The heating element is a 60 watt incandescent light bulb. A porcelain light socket is secured to the lid with a large cable tie, allowing the light to drop down into the top of the chamber. The weight of the porcelain light socket also helps to weight down the lid securely onto the container.
On the electronics side, I chose an Arduino Uno clone (the Sparkfun Redboard) as the controller platform. Fortuitously, a little while ago I also happened to win a Seeed Studio Relay Shield, which worked perfectly in this application for switching the lightbulb and the fan. There was also a DS1821 One-Wire temperature sensor in my junkbox, which interfaced with the Redboard with a little bit of code I found online. An old two-conductor power cord and inline ATC fuse was used to provide power to the light bulb. Simple firmware was written for the Redboard that allows it to be commanded via the serial connection. The light and fan can be switched on or off via a single character command sent over the serial connection. Likewise, the temperature can be queried and sent to the PC via the serial connection.
The shack PC ties everything together via a Python script. My Rigol DSA815-TG spectrum analyzer is used as the frequency counter, since I can control it remotely via USB with the Python usbtmc library. My control script reads the temperature and frequency on an interval (I’ve been using 15 or 30 second intervals) and has logic to control the light and fan based on the readings. I will post the code to GitHub when I write a full post about the chamber.
Now that you know how the system works, let’s look at what I found with the Si5351A as the DUT. After doing some initial tweaking of the system to get it working the way I expected, on my first true run, I set up a simple temperature profile. After a 4 minute idle period, the light and fan was commanded to turn on until the temperature reached 60C, then the light was turned off, and I cracked open the lid of the chamber a bit so that it could cool off relatively quickly. The most noticeable thing is the double-humped response in the frequency. You can see the typical frequency reduction as temperature increases, but then around 52C, the trend reverses! I’m not quite sure what to make of it. But I must say that total frequency excursion of about 70 Hz over 35 degrees of temperature change looks pretty nice to me.
Next, Thomas LA3PNA suggested in the Etherkit IRC channel that I do a long run with no extra heating so I can get an idea of the warm-up drift and the long term stability of the oscillator in a temperature stable environment. That’s a very useful thing to know, so I reconfigured the Python control program to do that. As you can see from the plot below, after a small amount of drift in the first 10 minutes or so, the Si5351A is extremely stable. Those excursions that you see from the main trend line are only 1 Hz, so those may be due to the oscillator or to error in the frequency measurement, but either way I’d say that’s rock-solid. You can even notice that the temperature of the chamber was a bit high from the previous run and settled down slowly to ambient, but that had no noticeable effect on the stability.
After that, the Python program was rewritten to ramp up temperature to 40C, then try to hold it there by toggling the light on and off if the temperature deviated more than +/- 1 degree. I wasn’t completely happy with the control loop in this one (I used 30 second intervals, but it should have been shorter) but the graph was still instructive. This time, the frequency response looks about how one would expect with this type of temperature profile.
Finally, I again tweaked the control algorithm in order to tighten up the measurement interval to 20 seconds and the maximum temperature excursion to +/- 0.5 degrees. The hold temperature was set for 50C, which is close to where that odd inflection in the drift appears. You can see that the control at 50C is much better here. You will also notice that blip where the positive temperature coefficient appears to go negative. Still, it holds relatively stable at 50C.
There is not a lot of data out on the internet to use for a comparison against this data. However, I believe it’s fair to say that the Si5351A looks pretty solid from a stability standpoint. It’s doubtful one will be operating a radio under such extreme temperature excursions in almost any case, but even so, <100 Hz of drift seems tolerable for almost any application where one is using a conversational operating mode. Of course there is still some more data which could be collected, such as performance at low temperatures, but from this initial investigation, I would say that things look very promising for the Si5351A.
11 January 2015 Update
I finally received a small supply of the TCXO that I have been planning on using with the Si5351A for a while now: the FOX924B-25.000. In the interest of comparing the performance of the TCXO against the standard crystal, I ran the same thermal chamber temperature profile as the last one above, although I removed the lid at the end of the 50C cycle to get a steeper cooldown gradient.
As you can see, the TCXO stability is approximately an order of magnitude better than the crystal. The maximum frequency deviation is 9 Hz, although that occurs at the point where the lamp is turned off, so the frequency response is somewhat like the first derivative of the temperature curve. Once temperature is stabilized near 50C, the TCXO control loop does a great job maintaining frequency only a few Hz higher than the room temperature frequency. This TCXO should be suitable for nearly all but the most demanding applications. Certainly it would be excellent for WSPR/QRSS work and for portable outdoor ops like SOTA.
Sometime not too long ago, I was tipped off (sorry, I don’t remember by whom) to a potential rival to the popular Si570 called the Si5351. This PLL-based clock generator IC has a few points in its favor over the Si570: it is significantly less expensive (even with the required external crystal or clock) and it can output multiple independent clock frequencies from 8 kHz to 160 MHz at the same time (3 or 8 output ports, depending on which version you get). You could potentially generate a stable VFO and BFO signal from the same tiny IC, or perhaps build a multi-channel grabber receiver or MEPT/WSPR transmitter.
These capabilities looked too good to pass up, so I ordered a few of the Si5351A variety, which is the MSSOP-10 package with 3 output channels and a 10 ppm 25 MHz crystal to pair with it. A bit of searching on the Internet shows a bit of discussion about the IC in the ham radio communities, but I haven’t found any examples of the IC being used in a ham radio project yet. So, my plan of attack is to take an incremental approach in investigating this interesting IC.
The first part of this diabolical plan is to simply breadboard the bare minimum components and use a Bus Pirate to talk to the Si5351 so that I can get a handle on how it is programmed and its capabilities. That is what the rest of this blog post will be covering. Step two will involve using Si5351 as the VFO in a multiband grabber receiver (with plug-in BPF modules) that will be paired with a Raspberry Pi running LOPORA or WSPR. Assuming that works well, the final step will be to investigate whether the Si5351 can be tuned quickly and glitch-free on the fly and will be suitable for use in a proper transceiver.
As you can somewhat see in the photo above, I mounted the 5351 on a SSOP carrier board and glued that to a large piece of copper clad. The crystal needs to be mounted as close to the 5351 as possible, so I took the small 5×3 mm 25 MHz crystal and mounted it directly to the pads on the carrier board. For now, power can be conveniently provided by the Bus Pirate. It was a breeze to connect the Bus Pirate for I2C operation, start a serial console on my Linux Mint PC, and start issuing commands to the 5351. (As an aside, I can’t recommend the Bus Pirate highly enough for this type of experimentation. It’s well worth the modest price for the ability to quickly and simply start experimenting with new ICs).
On start up, I measured the spectrum above. As you can see from the marker measurement, the fundamental is at an amazing +18.5 dBm. The output impedance of 85 ohms, so properly matched, the output power could be even higher. The good news is that there are four output level options in a 5351 register, so it can be turned down. Also, I intend to use a pi attenuator pad in order to provide a better match to 50 ohms anyway, so the high power may be a good thing. Also, you will notice the large harmonic content of the output. I don’t currently have a working oscilloscope, but I’m sure that the waveform looks quite squarish.
Having confirmed that the IC at least works on power-up, I then proceeded to issue I2C commands to the 5351 that should disable and enable the output that I was measuring. Sure enough, that worked exactly as expected. Then, by using a Windows program called ClockBuilder supplied by Silicon Labs, I generated the full register set that needed to be written in order to change frequencies and manually changed the registers via the Bus Pirate, and sure enough the output changed frequencies. But not quite to exactly the desired frequency.
After puzzling on this problem a bit, I realized that I neglected to set on of the 5351 registers which controls the load capacitance on the external crystal. I use a crystal with an 8 pF specified load capacitance, but the Si5351 defaults to 10 pF on start up. After changing this register to the proper value, the output frequency was quite a bit closer to the nominal value, but still was about 1 kHz off (at a setting of 20 MHz). At this point, I assume this is a close as I can get it, and that I will need to write a calibration routine to determine the PPM error of the output and apply that error to the calculations which determine the PLL settings for a desired output frequency. I should have more on that in my next Si5351 post.
Being able to change frequencies is wonderful, but not when you have to use a PC program to do it. So the next step of the journey was to figure out an algorithm so that the 5351 can be tuned via microcontroller.
In order to explain this, I’ll need to provide a very brief overview of the Si5351 architecture. There are two main fractional PLLs in the 5351, each of which are independently locked to the external crystal (either 25 MHz or 27 MHz). These PLLs have a VCO which runs from 600 to 900 MHz. Each output channel then has a 2nd synthesizer which is locked to the output of either of the PLLs. This is also a fractional synthesizer which divides down the 600 to 900 MHz PLL frequency to the output frequency ranging from 1 to 160 MHz. There is also a final divider which can get that output frequency down to as low as 8 kHz if desired.
The trick then is to come up with an algorithm to determine the correct (and hopefully optimum) division ratios for each synthesizer in the 5351. PLLs are not my strong suit (the last one I built from hand was a LM 566 circuit in college), so I didn’t make much progress on my own. The Si5351 algorithm does not have the required data, but fortunately there is an application note that does have the basic algorithm. Still, that didn’t really explain a strategy for optimization of the synthesizer settings.
Fortunately, Tomas OK4BX gave me a huge bit of help in the Etherkit IRC channel. It turns out that there is an Si5351 driver in the Linux kernel, oddly enough. Not being a kernel hacker, the code conventions were a bit odd to me, but I was able to suss out enough to strip some basic tuning code out and now have a working C program (currently running on the Linux desktop) which can generate the a set of synthesizer frequencies and the register settings needed to tune to that frequency. I’m not ready to post it publicly yet, but rest assured that I will put it up on GitHub when it’s more complete and cleaned up.
That’s where things stand as of today. The next task will be to complete the C tuning program, then transfer that to an AVR microcontroller so that it can do the hard work of setting all of the registers on the Si5351. After that, I need to devise a calibration routine so that hopefully I can bring the frequency accuracy of the Si5351 to much closer than it is now (currently at 60 ppm, hopefully to within 1 Hz at 50 MHz or so). If that can be accomplished, then I should be good to go with integrating the Si5351 into a grabber receiver. Stay tuned for further updates.