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.

For Noontime Net

I've been working on getting the little bugs out of the Si5351 SSB rig and making improvements to the circuit. Since SSB QRP operating can be a bit more challenging than CW QRP ops, Dave AA7EE suggested that I think about a speech processor IC to use in place of the op-amp microphone amplifier. He directed me to the Elecraft K2 schematic, which uses an Analog Devices SSM2166. I poked around the Analog website a bit and found a sister IC called the SSM2167. It's smaller, simpler, and cheaper than the SSM2166, which could make it perfect for this radio.  I ordered a couple of samples of each from Analog and they rush-shipped them here within a few days.

So today I got around to installing the SSM2167 in the 40 meter SSB radio, set the compression level to about 10 dB, and took a look at the transmitter waveform on my oscilloscope (I can still kind of see the screen if I get some light shining on it from the side). There is a single resistor which sets the compression level, and by jumpering around it, I can set the level to 0 dB. By comparing the waveforms with compression at ~10 dB and then off, I could tell that the average transmit power was increased quite a bit with compression on.

Next, I decided to check-in to the Noontime Net to see how it would work on the air and hopefully get an audio report. Luck would have it that net control Leslie N7LOB was very strong here, so I knew I should have no trouble checking in today. Also I was fortunate to have a strong signal from Lynn KV7L, the gentleman who donated the SA602s that are used in the radio. I've got a raw clip of my check-in below, which I hope to incorporate into a more polished video a bit later.

As you can tell from Lynn, 10 dB of compression might be a bit much for something like checking into a net. I changed the resistor to set compression at around 6 dB, which should be more appropriate for this type of use. It also sounds like some folks on the Noontime Net want to see some photos of the rig, so here are a few taken with my tablet. Not the best quality, but it should give you an idea of what it looks like until I can get my "real" camera back and take better photos.

PC_20140702_134826_PerfectlyClear PC_20140702_135131_PerfectlyClear PC_20140702_135139_PerfectlyClear

A Prototype for a Si5351-Based SSB Rig

Now that I think I've fairly well determined that the Si5351 is suitable for use in a ham radio transceiver, it seems like time to put thought into action and actually try to build one. Ever since discovering that the Si5351 can output multiple independent clocks from one IC, I thought it would be neat to use one output as a VFO and a second as a BFO. As I showed with my Grabber RX prototype, this is certainly a viable thing to do.

One type of SSB transceiver architecture that I've been experimenting with in the NT7S shack is one using an unidirectional IF for both the receive and transmit signal paths, as opposed to the bidirectional designs seen in radios such as the BITX. The Lichen transceiver seen in Chapter 6 of Experimental Methods in RF Design is a nice example of such a radio. In past experiments, I have switched the VFO and BFO signal paths using analog switch ICs. But I realized that when using the Si5351, all you would need to do to implement this type of architecture is to connect, for example, the CLK0 output to the first mixer and the CLK1 output to the second mixer, then swap the frequencies on each CLK output when switching to transmit.

With that in mind, let me present the block diagram of my implementation of this below:


The mixers are the ubiquitous 602/612 loved and hated by QRP homebrewers around the world. I'm not a huge fan of the 602, but it has a couple of things going for it in this application. First is that there are essentially two inputs and two outputs on the IC, which makes it very handy for this type of design. And while it has fairly atrocious intercept figures, it does reduce component count quite a bit. So you could consider this more of a cheap & cheerful radio for fun, not a design for work in seriously crowded conditions. The rest of the elements in the design are pretty much your standard circuits. Nothing too groundbreaking there. One thing I neglected to put on the diagram above is 10 dB attenuator pads on Si5351 outputs in order to get the ~3 Vpp output down to around the 300 mVpp that the 602 likes to see for oscillator drive.


So here's the beautiful ugly mess on a piece of copper clad. This was originally a CC1 prototype board, but I decided to cannibalize it for this SSB rig since it already had the microcontroller and Si5351A, and because I was feeling too lazy to start from scratch. The radio build only took a couple of half-day sessions in the shack, and worked mostly as expected right off the bat. The T/R VFO and BFO swapping scheme worked perfectly, needing only a few extra lines of code to implement in the already-existing code. I ended up making my first QSO with the rig (5 watts transmitter output) checking into the Noontime Net and getting a S7-S9 report from net control. The second QSO was last night with fellow Oregonian, Joel KB6QVI, who was kind enough to give me a sked in order to check out how the radio was working on the air. Finally, I had a very brief QSO with Dave AA7EE, who gave me an inciteful audio report although we had a poor propagation path between us. Right now, I've got it back off the air to tweak a few thing, such as the audio response in the mic amp, but expect to get it back in working order for use at Field Day.

Overall, I'm pretty happy with the direction this radio is proceeding. If I can get all of the bugs worked out, this could be a pretty potent design. Not in the performance category, but in the cost and component count sense. I'm seriously considering whether it may be feasible to do crowdfunding for a run of kits if I can nail down the design well enough. I have come to believe that the Si5351 could be a game changer for ham radio HF and VHF radio designs.

Si5351 Libraries and Breakout Board

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.

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.

Si5351A Investigations Part 5

The Si5351 library for avr-gcc that I've been promising for the last four posts is finally in a state where I feel comfortable releasing it, so I've posted it on GitHub. I think that the documentation posted on the README file and inside the code should be enough to get you going, but if you run into problems, please comment here or file an issue on the GitHub repository.

At this point it is very basic, but it will generate frequencies from 1 to 150 MHz on any of the three outputs of the Si5351A, and you can do stuff like turn the clocks on and off and change the drive strengths of the output drivers. More features will be added as time goes on, with the priority on things which will be needed to make a functioning amateur radio transceiver.

I'd like to point out something interesting that I've discovered about the parts that I've been working with. I ordered my Si5351A parts from Mouser (P/N 634-SI5351A-B02075GT). I never had any luck communicating with them on the datasheet-specified I2C address of 0x60; instead they need to be addressed at 0x6F. Thanks to the Bus Pirate and its built-in I2C address space scan macro, that didn't take me too long to figure out. I just chalked it up to yet another datasheet error (the Si5351 is riddled with problems), but it turns out that I may actually have some defective or custom parts which shouldn't have made it out to Mouser.

Over the last few days, I have been corresponding via email with Ian K3IMW, who has been having a horrible time getting his Si5351 to work. After he described his symptoms to me, I suggested that he try address 0x6F, and sure enough, that worked. What confounded him was that another ham he was in correspondence with was able to talk to the Si5351 using address 0x60. It turns out that those parts that work on 0x60 were from Digi-Key and both Ian and I obtained our parts from Mouser. So, the theory is that perhaps some custom parts accidentally made it out the door to Mouser. I will try to contact Mouser in the next day or two and see if perhaps they can get it straightened out with Silicon Labs.

The moral of the story to to pay attention to where you got your parts from if you are having problems with the Si5351. Once I can get my hands on some of the same P/N from a different vendor and can confirm that it does indeed work on address 0x60, I will make the change in the library. In the meantime, you may need to change that value yourself in the si5351.h file in order to get it working.

Si5351A Investigations Part 4

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.

Si5351A Investigations Part 3

Since the previous Si5351 Investigations post, I've made quite a bit of progress integrating the Si5351 into a grabber receiver. First, let's look at the grabber receiver architecture and how the Si5351 is used in it.


Above you can see the basic block diagram of the receiver. The front end has two switchable plug-in bandpass filter modules (which is switched by a pair of TI TS5A3157 analog switch ICs controlled by the AVR microcontroller). An ADE-1 diode-ring mixer is fed directly from one of the Si5351 ports set for the lowest output level (which is about +8 dBm). The pair of IF amplifiers are TriQuint AG203-63G MMICs, and the actual IF filter is a 6-crystal ladder filter with a bandwidth of 3 kHz (filter plots provided below). Another ADE-1 is used as the product detector, with the BFO signal provided by another output port on the Si5351. Finally, the recovered audio is amplified to line level by a NE5532 op amp and delivered to a 3.5 mm stereo socket by way of a transformer in order to provide good ground isolation between the receiver and sound card.

grx1 grx2

As an interesting side note, you can see my modular bandpass filter boards below. They are your standard double-tuned circuits placed on a 20 mm x 50 mm piece of copper clad, with 0.1 in SIP headers soldered to pads cut out of the material with a rotary tool. There are some extra pins which are reserved for a future module identification system.


Happily, the receiver mostly worked as expected right out of the gate. A few minor tweaks need to be made, such as in the gain of the AF amplifier, but I'm pretty happy with the results so far. Although it's my intention to pair this receiver with a Raspberry Pi running LOPORA in my garage, right now the receiver is sitting on my bench capturing WSPR RF on various bands, and looks to be doing a fine business job doing that. Frequency stability looks at least as good as my IC-718 on WSPR, based on an eyeball assessment of WSPR spots.


The Si5351 seems to do a bang-up job acting as both the VFO and BFO. What's nice is that I can easily switch sidebands merely by changing the output frequency of the CLK1 BFO output with one line of code. I haven't seen any indications of spurious products affecting the receiver yet.

My Si5351A library for avr-gcc is still pretty rough, so I'm not quite ready to publish it yet. Next up on my todo list is to get it in a state where I'm ready to put it up on GitHub, then implement the USB control protocol and client program so that the grabber receiver can be tuned via command line (especially handy when using SSH).

At this point, I'm fairly confident that the Si5351 will make a very fine oscillator system for a grabber receiver. My next line of investigation is to look at the temperature stability of the Si5351 via a thermal chamber lashup. I've got a nice Styrofoam cooler, an Arduino knockoff, a 120 V relay shield, a temperature sensor, and a frequency counter I can read via serial port, so I just need a heat source (probably in the form of an incandescent bulb) and I should be good to go. Keep watching for more experiments!

Si5351A Investigations Part 2

It has been another productive weekend with the Si5351 here in the shack. Since the last report, I've made significant progress in confirming that the Si5351 may be a good candidate for use as a LO in a radio.

After getting the most basic communications with the Si5351 going via the Bus Pirate, my next task was to find out if I could determine a calibration routine that eventually would be easy enough for anyone to do with even simple equipment like a digimode PC program and WWV. Recall from my previous post that there was quite a bit of error in the output frequency when uncorrected (over 1 kHz error at 20 MHz output frequency). According to its datasheet, the Si5351 has 0 PPM of inherent frequency error, which means that all frequency errors should result only from the attached 25/27 MHz reference crystal. Theoretically, if that can be measured, one calibration value should be good across the entire tuning range.

I added in a line of code to change the nominal 25 MHz reference frequency (called "parent_rate" in the above code snippet) based on an amount of error entered as a command line argument in parts-per-ten million. This reference frequency is the basis of the calculations of the two synthesizer values calculated in the program, so tweaking it to its actual oscillation frequency should give the proper output frequency wherever that output frequency is set.


After adding this simple calibration code, I first used my tuning program to output a set of registers for 10.000000 MHz oscillation with 0 correction. These tuning registers were loaded into the Si5351 and the output was measured on my Tektronix DC 503A frequency counter at 1 Hz resolution. A difference of -887 Hz was measured between the nominal 10.000000 MHz frequency requested and the actual output frequency. Next, as you can see in the screenshot above, I entered a correction factor of -887 parts-per-ten million into the tuning program and generated a new set of tuning registers. (For those who are curious, the program prints out a variety of variables for troubleshooting, then at the end spits out the hexadecimal code for the Bus Pirate to send the registers to the Si5351. I just copy and paste that string into my serial terminal).

Happily, the Si5351 output a frequency within 1 Hz of the nominal 10.00000 MHz requested frequency. Experiments with other tuning frequencies showed similar amounts of error. Up at 50 MHz, the frequency counter only showed ~3 Hz of error. This bodes very well for the use of the 5351 in amateur radio projects.

SI5351 Test Board
SI5351 Test Board

So, with calibration seemingly under control, it was time to move everything over to a microcontroller. The above photo shows the current hardware setup. I've added my old favorite, an Atmel ATmega328P microcontroller, with a 16 MHz crystal. I have also added a USB B jack, as I intend to make this Si5351 controlled and powered exclusively via USB. Since the Si5351 operates off of 3.3 V power, I provide power to it and the '328P via a LE33CZ LDO regulator fed from the USB 5 V supply. I have also added some simple resistive voltage dividers to the AVR ISP lines to convert 5 V programming signals down to 3.3 V.

Fortunately, I now seem to have enough AVR code sitting around that a lot of these new endeavors can be launched very quickly via the application of a bit of copy-and-paste. I borrowed a bit of I2C code from some CC1 development work and pasted in the rough tuning code that I originally wrote for the Linux command line. A bit of jiggery-pokery and I was able to get the '328P sending I2C commands to the Si5351 to set various parameters and tune to a non-default frequency in order to ensure that the I2C comms were working.

Which is where I currently sit with the project. Next up on the agenda is to write a basic Si5351 library for the ATmega88/168/328 series and then paste in the V-USB code in order to get USB control up and running. After that, it will be onward with the grabber receiver portion of this experiment. Stay tuned for updates (and yes, code will be forthcoming on GitHub once it's in a decent state).