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).

Si5351 Test Lashup

Si5351A Investigations Part 1

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 5x3 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).

5351 Start Up Spectrum

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.


Bitter Taste

Perhaps it's because the good weather has finally arrived here in Beaverton, but I seem to have become a bit more sanguine about my difficult situation with Etherkit, as described in my last post. It's in my nature to be more of a realist (others might call it pessimism), sometimes trending to a bit of fatalism. I probably should not have stated quite so equivocally that Etherkit is shut down.

I do plan on continuing to sell kits until I am out of stock. I may also keep replenishing a small amount of the OpenBeacon 30 meter and 40 meter kits, as I still do get occasional sales of those. In the mean time, I will still work on projects, even if only to keep me sane. One of my larger stumbling blocks right now is that the backlight on my TDS1012 oscilloscope completely gave out, rendering it nearly useless for now. So the first order of business in getting back in the game is to procure a replacement, probably a Rigol DS1052E or something similar. (I could work on fixing it, but after the investment in time and tools, I will probably be better off just getting a new inexpensive scope for now). So to that end, I have put new stuff up for sale in order to help fund a new scope.

So things are probably not quite as bleak as I first thought, if I can get a new oscilloscope soon. I still have the challenge of funding a new kit run, but perhaps I should just proceed to that point, then worry about that problem when I get there. I'm sorry to be that guy, but we all have our weak moments when times get difficult. For now, we'll just say I'm on an extended hiatus and will be making no promises, but perhaps Etherkit is not quiet dead yet.

Red Pill

There are times when one must face the reality of situations, no matter how painful it may be, because the alternative is even more destructive in the long term. This is one of those times for me. As I'm sure you have noticed, blogging here has dried up, I have done a horrible job in responding to emails, and developments at Etherkit have ground to a near halt.

Without getting into many overly-personal details other than to say that due to a lack of resources, I have made the decision that I see no viable way forward for Etherkit at this point, and rather than belabor the illusion that things will get better at some indeterminate point in the future, it is better for my mental health and my family to institute a graceful indefinite hiatus on the company. Why not a total shutdown of the business? I would like to liquidate the inventory that I have left and I want to keep my website online for at least another year (and preferably much longer) so that the documentation is still available.

To that end, I have decided to cut the price of the CRX1 receiver kit to a very nice price of $30 so that I can get a little more cash flow before turning off the store. If you could do me a solid, and let any of your kit-building friends know about this, I would be most grateful.

I will have more words about the personal situation here in the next post, but for now I wanted to move this process forward. I would like to most sincerely thank all of the fine folks who have been customers and beta testers for Etherkit. I know that I have been lacking in many ways and apologize for my poor level of responsiveness. Because I don't like to slam doors closed completely, this may not be the absolute end of Etherkit, but for now I am treating it as such.

Thank you so much.

Merry Christmas

2013-12-24 14.04.01

This has been a very unique Christmas for me. For most of my adult life, as someone without children, Christmas wasn't exactly the exciting holiday that it used to be as a kid, of course. It was still nice to get together with the family to exchange gifts and have a dinner feast. But the old magic had pretty much faded.

Now that I have two little ones, I'm getting to experience a new aspect of Christmas. I'm sure this is old news to most of my readers, but living Christmas vicariously through your young children is pretty fun. My oldest boy Noah is now 3.5 years old, so he's really able to understand what's going on, unlike previous years. His little brother Eli isn't quite 2 years old yet, so he doesn't really get it yet.

It was a joy to play Santa Claus this year; wrapping and hiding the gifts, preparing the stockings, sneaking out to put everything in place, and of course getting the cookies and milk as a reward. Seeing Noah's anticipation as I showed him the Santa Tracker online and his excitement as he woke up this morning to Santa's presents was the most fun I've had on Christmas in many years.

In a time when humanity hasn't exactly been impressing me lately (especially the online denizens), it's a lift to my spirits to disconnect from the craziness and enjoy the holidays with my family. It reminds one of what is real and what is transient noise.

I hope that all of the readers of this blog had a wonderful holiday season and sincerely hope that you have an even better 2014.

2013-12-25 09.44.49


We Make Contact

My last blog post (from two months ago, sorry about that) detailed my participation in the worldwide Hi Juno event; a coordinated effort from amateur radio operators from around the world to send a very slow speed Morse Code signal (HI, to be exact...DIT-DIT-DIT-DIT DIT-DIT) to the Juno spacecraft as it slingshotted around Earth on it's way out to Jupiter.

After the attempt, the Juno science team promised an update to let us know how the experiment turned out, but was very quiet over the last few months. Worse, was news that Juno had tripped into safe mode during the Earth flyby. There was a decent chance that no usable data from this experiment would be recovered. Suddenly, yesterday on 9 December 2013, there was a press release announcing that there would be a presentation on the results of the Juno Earth flyby, including results from the Hi Juno experiment, and that this presentation would be streamed online. This morning at 10:30 AM, I eagerly connected to the livestream to see what they would announce.

Hi Juno Spectrogram

Hi Juno Spectrogram

In short: we did it! As you can see in the spectrogram above, our signals were detected by the Juno spacecraft in a couple of different time slots. The green dits are the signals that were actually detected by Juno, while the gray ones are anticipated signals which were not detected. One thing is slightly misleading about the spectrogram, as it appears that our actual signals are not depicted in it. I'm not sure why that is, but I imagine it is for clarity in public outreach. Still, as a ham, I would love to see the spectrogram without the overlay of the expected data. One other thing that is interesting is the streaky lines in the upper right-hand corner. It is said that these are terrestrial SW broadcasters.

The Waves instrument primary investigator said that there were at least 1400 hams who participated in the experiment (I assume that is based on the number of QSL requests sent through their email address). If you assume that each was running a barefoot commercial rig (I was, but had it dialed back to 50 W just to go easy on the finals), it's not hard to imagine that collectively we put around 100 kW of 28 MHz RF out there for a few hours.

Perhaps this stuff is too obscure for the average person to care about, but in my view this is one of the most inspiring and amazing things I've done in amateur radio. You can see a bit of my raw reactions from Twitter below:

It's pretty rare for a space agency to reach out to the public at-large for active participation in a spacecraft science experiment. The fact that we were able to pool together and successfully transmit a signal to space probe whipping around the Earth at very high velocities just boggles my mind. I also have to give a huge huzzah to the team who created the public outreach website for Hi Juno. It was top-notch and did a perfect job in coordinating all of us hams around the world. I hope that the success of the Hi Juno experiment will encourage science teams to consider similar future efforts when possible.

It does seem that the Hi Juno experiment had quite an impact on the science team, as it inspired them to create a short documentary about the event and the results, which you can see below. It's very well produced and exciting to watch. There is also a shorter video which just shows a depiction of reception of the Hi Juno signal. Now I just need to wait for my Juno QSL to arrive...

UPDATE: Here's a press release about Hi Juno from the mission page.

Hi Juno After-Action Report

As I write this, the Juno spacecraft has completed its slingshot maneuver around Earth, having stolen a bit of Earth's rotation energy. and is now on its way out to Jupiter. A bit before the designated 1800 UTC start time for the event, I was able to set up my Icom IC-718 at the appointed frequency of 28.324 MHz with an output power of approximately 60 watts CW.

I executed the hijuno.py script via SSH (as mentioned in my last post) a few minutes shy of 1800, turned on my handheld scanner so I could monitor the transmit frequency, and waited for the show to start. I also checked a few WebSDR receivers to see if I could detect how many hams were participating in the Hi Juno event.

Hi Juno Website

Hi Juno Website

The transmitter started up, but immediately I could see that it wasn't in sync with other stations that I could hear and see on the receiver. My shack PC is running Ubuntu 13.04 and it set up to automatically set its clock via NTP, but obviously it was off by quite a bit. So I had to duck into the shack quickly to manually update NTP, then come back to my laptop to restart hijuno.py via SSH. This time, I could see by following along with the interactive Hi Juno website and listening to my transmit monitor, that my timing was correct. As you can see above, the website had a nice graphical display of when to key up and key down for those doing this manually. That little yellow triangle at the bottom of the screen moved from left to right to indicate the current position within the transmit timing window.



At this point, satisfied that the Python script seemed to be working, I went back to WebSDR for a listen. The W5ZA 10 meter beacon receiver in Shreveport, Louisiana seemed to be a great choice for monitoring all the Hi Juno signals out there, probably because it was still in daytime, as opposed to the European receivers, which seemed to be showing nothing. Normally this would be considered bad, but I have to think in this case it was a good thing, since the ionosphere was probably not reflecting 10 meter signals back to Earth in this part of the world, and they were free to make it to Juno. To the left, you can see a screen capture of the W5ZA WebSDR just after a Hi Juno keydown period.

The rest of the event was fairly...uneventful. The Python code worked perfectly and stopped transmitting at the right time. It was fun chatting on Twitter with other hams who were also participating in the event. Based on watching the WebSDR waterfall and checking Twitter search, it seemed like there were quite a bit of us taking part in the event. I have no idea, how long it will take for us to hear back from the investigators whether this worked or not, but I hope it's fairly soon. I'm definitely looking forward to getting a QSL. My first one from an interplanetary spacecraft. I also have to say that the Hi Juno website worked wonderfully during the event with its simple and clear graphic instructing you when to transmit, and showing you transmit window. if we ever get more opportunities to participate in experiments like this in the ham community, it should be a model on how to run things. Even though we didn't get any immediate gratification, it was a fun event and I hope that NASA/JPL reaches out to us again in the future.

Hi Juno!

As a world-class procrastinator, I know I'm very late with this post only about 12 hours before the event. However, I still wanted to share it with you in the hopes that maybe it could help one person.

As you may have heard, the Juno spacecraft will be making a close approach to Earth on 9 October 2013 as it slingshots to gain energy for the trip to Jupiter. The investigators who are in charge of a radio receiver on the spacecraft wish to see if they can detect intelligent life on Earth who may be transmitting on the 10 meter band. Therefore, they are asking licensed radio amateurs to transmit a slow-speed CW "HI" signal to Juno during a window at Juno's closest approach. The full details are on the Hi Juno page (due to the US government shutdown, the primary page is offline, but the event is still planned to take place).

BWFZtUsCcAA8RgFIn order to be able to take part in this event without having to be right at the transmitter (I have to take care of my two toddler boys during the specified time period), I wrote a program in Python which will automatically transmit at the appropriate time. You just need a PC synchronized to NTP time, a 10 meter CW transmitter, a serial port, and a keying interface (which I will describe shortly). I plan to execute the program on my shack PC via SSH and monitor my transmissions on a portable receiver to maintain control of the transmitter.

Serial Port Keying Circuit

Serial Port Keying Circuit

Here is the simple keying circuit I use to key my Icom IC-718. It should work with just about any grounded keying transmitter, but as usual your mileage may vary. I use a DB9 female jack for the serial port. The RTS line is used to turn on a 2N7000 MOSFET, which will ground the key line in order to transmit. You can use any key jack that is appropriate for your transmitter. I use this circuit with a USB-to-Serial adapter, and it still seems to work fine.

The actual Python program to control the serial port keyer is found here at GitHub. You will need to have the PySerial module installed on your system, in addition to the regular Python installation. I've tested it here, but please be sure to test it yourself on a dummy load before using it on the air (you will need to temporarily change the START_DATE variable to an earlier time in order to get the program to transmit). You will also need to change the DEVICE, BAUD, and CALLSIGN variables to values appropriate for you. Linux/OS X users would change DEVICE to whichever "/dev/tty*" port is appropriate, where the * is your port numbe. Windows users would use "COM*", where * is the COM port number. Sorry that I can't hold your hand through this, but it should be fairly simple to get running. Linux and OS X users may also have to execute the program under sudo in order to access the serial port.

Please let me know if you end up using this, and don't forget to request a QSL from Juno!

The CRX1 Is Here!

I'm happy to report that the CRX1 40 meter receiver kit is now in full production and is available for purchase in the Etherkit Store for $40 (which includes all controls and connectors, you just add some wires and an enclosure). Allow me to quote from the product page:

The CRX1 is a simple VXO-tuned superheterodyne receiver for the 40 meter band, with tuning centered around the popular QRP watering hole frequency of 7.030 MHz. It is entirely constructed from surface mount devices in the easy-to-build 0805 (US) size for passive components and SOT-23 class semiconductors. The PCB is large and single-sided, which provides for uncramped construction and makes the CRX1 an ideal warm-up kit for the CC1 QRP transceiver (coming soon). The CRX1 is not just meant to be a novelty to be tossed aside after construction. All of the support circuitry for muting, T/R, and sidetone is included, so it can be paired with virtually any transmitter which uses grounded keying. There is also a port for an external VFO to enable further user experimentation.

All controls and connectors are included with this kit, so you just need to supply an enclosure and a few knobs to finish the job!


Frequency Range: Approximately 7.030 to 7.034 MHz (at +13.7 VDC power supply)
IF Bandwidth: Approximately 400 Hz
Current Consumption: 25 mA (at +13.7 VDC power supply)
Power supply: +9 VDC to +14 VDC
MDS: -123 dBm
3rd Order IMD DR: 84 dB
IF Rejection: 74 dB
Image Rejection: 67 dB
PCB dimensions: 70 mm x 100 mm
Antenna Connector: BNC
DC Power Connector: 2.1 mm barrel jack
Phone Jack: 3.5 mm stereo
Key Jack: 3.5 mm stereo
Reverse polarity protection
Muting, sidetone (user enabled), T/R switch, external VFO port included

Available Bands

40 Meters - 7.030 to 7.034 MHz

The CRX1 is a fun little receiver to build and is a great kit to get your feet wet with SMT construction!

On a side note, I've established an IRC server on my Raspberry Pi for Etherkit and it has been working great for the last month or so. Please do stop by for tech talk (and other occasional diversions) on channel #etherkit at irc.recursiv.com.

Wideband Transmission #3

Polyvaricons Now For Sale

I've decided to try a small experiment and see if there's any interest in selling a small selection of components that would be handy for RF experimenters. The first product I have up for sale (in limited quantities at this time) are four-packs of the somewhat-hard-to-find polyvaricon variable capacitor for only $10. Please head on over to the Etherkit store to get the details and to purchase a pack. If this is successful, I may keep selling them and branch out into some other RF rarities.

Behind the Scenes in Kitbiz

Think that your local small-time kit business is raking in the dough? Probably not. This blog post from ch00ftech does a wonderful job of explaining the economics behind small-batch kitting and will probably give you a new perspective on all of the expenses incurred in such an endeavor, including many which may not be obvious to you at first. Although in this particular instance, the author was not particularly trying to make a profit, the post still captures the process involved, even for those who wish to earn a few bucks from their toil, brilliantly.

World's First Mt. Hood SOTA Activation

Here's a really neat write-up (with photos) of the very first SOTA activation of Mt. Hood, the tallest peak in Oregon (11,249 ft [3,429 m] tall). Well done, KB3QEW!

Lower Prices on the For Sale Page

I've lowered the prices on most of the items on my For Sale page, so please get over there and take a look at some good ham gear and test equipment!

Emanations from Amateur Radio Station NT7S