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:

Si5351SSBBlockDiagram

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.

DSCN0678

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.

20140612_140918

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)

DSCN0671

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

DSCN0658

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.

5351SecondRun

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.

5351SelfHeating

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.

5351-40C

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.

5351-50C-2

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.

TCXO-Run1

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.

GrabberRXBlockDiagram

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.

DSCN0641

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.

WSPR

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.

Terminal_001

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

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.

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!

Wideband Transmission #2

CC1 Beta Kit For Sale

I ended up having one leftover kit from the CC1 beta test and I thought that an experience builder might like to build it. There are a few minor mods to perform to the PCB, so it's best suited for someone who feels comfortable with that. The (hopefully) final PCB spin is coming soon and will be slightly different, but this version works well, as AA7EE can attest to. I can offer the kit for a discount over the final CC1 retail price, and it's currently available for 20 or 40 meters (although the final retail product will be available for more bands). Contact me at milldrum at gmail dot com if you are interested.

SOTA 12 Meter Challenge

I'm not subscribed to the SOTA reflector, but I saw a post on the VK3ZPF blog that there was an announcement on the reflector that there will be a SOTA 12 Meter Challenge. I think this is a great idea and I want to support it if I can. I haven't made too many 12 meter QSOs, but when I have it seems like the DX has been pretty easy picking. When it's open, the band seems quiet and the signals sound great. The plus for SOTA activation is that a resonant antenna is small and easy to pack.

My original plans for the CC1 were to only support up to 15 meters, but I think I may add 12 meters in order to support this initiative. The DDS in the CC1 is clocked at 50 MHz, so technically I should be able to output a 24.9 MHz signal, although I don't know in practice how well this works at a frequency so close 0.5 Fc. If I can get it to work, I will release it as an available band on the CC1.

New PCBs Are Here!

CRX1 Beta
CRX1 Beta

Here is the latest beta PCB from the Etherkit, the CRX1 receiver! It is all-SMT construction, but I spread out the components a bit more than the CC1 and all of the parts are on one side of the PCB only. It's VXO-tuned for the 40 meter band (a few kilohertz around 7.030 MHz) and is based on the Clackamas transceiver which I entered into the 2010 FDIM Challenge (which means it's also a cousin of the CC1). This receiver has only discrete components (size 0805 resistors/caps, SOT-23 transistors), so it should be fairly easy to build. In other words, a good warm-up for the CC1. It also has a port for an external VFO, so it will be a platform for experimentation as well.

I'll build this PCB up today and verify that it works, then get a few beta testers to confirm that all is well. Hopefully I can get this product onto market fairly quickly, with a low price. Stay tuned for more details as work progresses.

More Stuff For Sale!

I've added some new gear to my For Sale page that would be a great addition to the bench of any homebrewer. Please stop by and take a look!

Wideband Transmission #1

This is the first in a series of blog posts covering a wide variety of topics. In the past, I have used Twitter for my microblogging needs. For a variety of reasons, I'm on a Twitter hiatus right now, so I'll be using this series to convey some of the disconnected (and possibly connected) random thoughts that I feel I need to get out there. I don't think I'll be abandoning Twitter completely, but I will be reworking the ways in which I use it once I come back.

I'm also in the process of disconnecting completely from Google, so I wanted to give fair warning to those who correspond with me via my Gmail account that I will be abandoning that service very soon. I've already deleted my Google+ profile, and will be deactivating the rest shortly. I'll probably describe my rationale for this later, but keep in mind that I've been a Google customer data mine for nearly a decade, so this is not something that I undertake lightly. I'll try to get alternate contact information to those of you who regularly correspond with me.

It is an age of new beginnings.

Clackamas 2 Prototype

With the introduction out of the way, let's get down to the good stuff. Above, you can see the latest project on the Etherkit bench. It's a re-work of the receiver from the Clackamas transceiver (the rig that I submitted to the 2010 FDIM 72-part challenge). I've decided to make this receiver into a cheap & cheerful little kit to get people warmed up for building the CC1. It's currently for 40 meters only, is a superhet, and is VXO tuned (covers 7.030 MHz plus a bit more). It is 100% discrete component (you can see a TDA7052 IC above, but I've abandoned it for a different AF amp) and will be SMT construction. The receiver itself is pretty simple, but you can see there's a fair bit of other circuitry on there. That stuff is mute and sidetone circuits. It's easy enough to design a standalone receiver, but most of them will probably just gather dust after being built unless they can interface to a transmitter easily. With this extra circuitry, you can just split off your transmitter's key line and connect it to this receiver to have built-in muting and sidetone. My goal is to make this project cheap and fun to build. I'll be fast-tracking this one so I can get back to the CC1 soon.

Oddly enough, another project from the FDIM Class of 2010 is also coming out soon. As spotted on The QRPer, the Cyclone 40 transceiver is based on the rig that Dave Cripe, NM0S submitted as his 2010 FDIM 72-part challenge entry. I recall that the rig had a very unique design and that the specs were impressive. Dave's a great designer, so be sure to buy one to get a rig unlike anything else you've seen before and to support 4SQRP.

Choking off the Internet firehose that I had previously directed at me has allowed me to devote a bit more time to enjoyable activities that I've neglected, one of those being reading. I'm currently enjoying a book I've had on my shelf for a while now called Seeing in the Dark by Timothy Ferris. It's billed about being about amateur astronomers, but it does get into the professional side quite a bit as well. It's a good read and very entertaining, and I can't help but see a lot of parallels between amateur radio and amateur astronomy.

That's a great segue to the final item, which is a bit of fun from our favorite Canuck astronaut, Cmdr Hadfield. He's leaving ISS in a few days and just released a surprisingly touching (although obviously light-hearted) rendition of Space Oddity by David Bowie (one of my guilty favorites). Cmdr Hadfield may not be on the level of Neil Armstrong or Yuri Gagarin, but he's definitely making a play for Coolest Astronaut Ever.