Feb 24, 2016:
Revised: v1.1

Low Current Compact CS2000-based Signal Generator

CS2000 signal generatorTrials and tribulations with the Cirrus Logic CS2000 DDS oscillator chip while designing and building a new compact low current RF signal generator.


Oscillators form a key section in many designs. In amateur radio, a variable frequency oscillator (VFO) is often used to generate the operating frequency of a receiver, transmitter or transceiver.

Back in 2008, I published the details of my AD9850-based DDS VFO in Silicon Chip magazine in Australia. That design was later republished in EPE magazine in the UK about a year later. Some details can be found here. It used the Atmel 89C2051 8051-based processor and used a recycled Nokia 5110 graphics LCD display. The Analog Devices AD9850 DDS chip was relatively easy to use. The datasheets were clear, and Analog Devices also published a number of useful application notes for the chip.

As time has passed, the AD9850 presented a few limitations. Firstly, the output frequency of the VFO was limited to about 40MHz with the standard 125MHz crystal oscillator. This was not a serious issue for most applications. However, the increasing use of software dependent receivers (SDR) require the use of quadrature oscillators. These usually run at four times the operating frequency. That means that a VFO using the AD9850 would limit receiver or transceiver operation to, at most, about 10MHz. That’s quite restrictive.

The second problem was the current consumption of the AD9850. VFO designs using these chips or the recent low cost Chinese-made AD9850 modules typically consume about 200mA at 5V. Consequrently, low power QRP or battery operation was a problem. Besides, any linear regulators to drop 12V supplies down to 5V for the DDS got very hot very quickly. I developed a more efficient switching regulator specifically to address this latter problem. The details can be found [here]. It didn’t resolve the fundamental issue of that high load current.

The Search for a New DDS Chip

I started to look around for some alternatives about 18 months ago, spurred on by the increasing interest elsewhere in the si570 chip. I stumbled across some references to the Cirrus Logic CS2000 and, after further detailed study, it looked to be quite a promising component. While there were very few users of the device and no helpful application data from the manufacturer, the (claimed) output range of the chip of 2 – 75MHz looked good, the current drain promised to be less than 20mA, and the price was reasonable, about $US9 each.

Assuming the chip was used in a quadrature oscillator running at four times the operating frequency (“4xF”), it could the operating range of a SDR, up to about 20MHz, and if a “2xF” quadrature approach was used, it could cover all of the HF band, up to 30MHz. After considerable effort, I managed to purchase two samples from a UK source.

The Pain Begins

The apparently simple process of purchasing the chips was just the start of a succession of problems that hung like the proverbial mariner's curse around this design. It should have been a simple delivery through the mail to a UK address I used for such purchases. But it quickly turned into an epic struggle. The supplier could only deliver the parts by courier. The courier couldn’t find the address (!!), so this simple delivery of a pair of eye-wateringly tiny parts required many phone calls, several failed courier deliveries and considerable anxiety. Eventually, however, the tiny 10-pin SMD chips were in my hand.

The next step was to build a simple oscillator with the chip. I designed a basic circuit using a suitable microprocessor, this time an Atmel ATmega328. I also added a compact I2C 2x16 alphanumeric LCD and a rotary encoder.

This thing fought me all the way. The encoder software I’d used in a previous design refused to work properly with the new encoders I’d recently purchased from an Asian source. Resolving that issue took some effort.

Fortunately, I came across some excellent advice on a German language website by Georg, DL6GL. My problems were all to do with variations in operation between different types of low cost mechanical rotary encoders. Buying cheap parts brings its own rewards, it seems.

A previous design of mine had solved the problem of driving the I2C LCD displays I planned to us, so at least the display did not generate problems.

But the CS2000 chip did.

CS2000 Problems

I carefully followed the details in the CS2000 datasheet and started with a 20MHz crystal divided internally to produce a 10MHz reference frequency. This is used in the fractional PLL system to generate the final output frequency.

The datasheet implies the CS2000 will tune from 6 – 75 MHz regardless of crystal. Tuning resolution, of course, basically depends on the crystal. When I tested the chip, I did managed to get an output quite quickly, but then I began to notice gaps in the tuning range. Thinking it might be the crystal frequency I’d chosen, I tried several other crystals to see if they would give different results. They did, but gaps still existed across the 75MHz tuning range.

For example, a 10MHz crystal produced outputs from 2-4.5MHz, 4.9-8.5MHz, 9.7-17MHz, 20-34MHz, 39-68MHz and 78-130MHz. Well, the good news in that test was that the CS2000 could readily exceed its stated tuning limit of 75MHz (or 70MHz, depending on where you look on the datasheet). Some crystals I tried allowed me to reach 160MHz. That was helpful, but the real problem remained - All of those gaps.

I found if I used a 13.5MHz crystal, then I got 2.2-2.9, 4.4-5.7, 6.8-11.5, 17.6-23, 35-46, 70-92 and 141-166 (The chips tended to get a bit erratic above about 165 MHz, but hardly unsurprising!!) The 12MHz crystal was an utter disaster. You can see this in the results graphed below for a variety of crystals tried.

Figure 1 : RF output gaps with different CS2000 crystals

Can you see the harmonic relationships going on in there? I carefully rechecked my calculation method again and double-checked the values going to the device. I even ended up building a separate I2C bus analyser just to take a closer look at that serial data just in case the data transfer was being messed somehow. But, no. The I2C bus was working just fine. Well, just to be sure, I also rebuilt the unit using the alternative three-wire SPI serial interface. No change. None. Same problem.

So I built another one with the second CS2000 chip I’d purchased, this time using a Tiny85 processor. Same problem. I started to look under my workshop desk for signs of albatross feathers

Figure 2 : The second version used a compact Midas I2C 2x16 alphanumeric LCD and an ATtiny85 8-pin processor

I would like to acknowledge the useful help I received during all of this from the software written for the same CS2000 chip by Ray on his website. He had no such problems. Go figure.

Over the month or two that I’d been messing with these chips, I tried to ask Cirrus about the problem several times. Despite having a website page for such questions, I never received any response. Searching around forums and through other designs resulted in a similar dead end. It was just as well I wasn’t doing this stuff for real in a production environment with 100,000 units backing up on the line.

Clasping at straws, I tried some other crystals to see if I could spot a pattern somewhere which could help me to better identify the problem. I got wider bands of output (and fewer gaps) when I tried a 16.93MHz crystal on the CS2000. That crystal was outside the specified operating range of the chip and it was not supposed to work, but it did. And checking the reference output on pin 4 of the CS2000, I confirmed it was oscillating just fine at 16.93 MHz. Hmmm.

So I tried a 17.5 and a 22 MHz crystal. I obtained even better results, with still fewer gaps.

So I went for broke, and fitted the only higher frequency crystal I had in my box of bits, a 24MHz crystal. And, by golly, I got complete continuous coverage from 1.55 – 166 MHz on the CS2000 output without any gaps!! I tried it with the other chip and got the exact same result.

That left me really scratching my head. Was it my software? Was it a pair of bad chips? Was it my misreading of the spec sheet? Still deathly silence from Cirrus.

Sometimes looking at vendor support software can yield some clues. Cirrus have a “configuration wizard” on their website for these chips. Well, it doesn’t work on any platform I tried, although it did ‘sorta’ work on an elderly Windows XP computer. Certainly didn’t work on Windows 7 or Windows 8, 8.1 or 10. But even on that ancient WinXP box, the software was, to put it kindly, obtuse.

Anyway, I’ve documented the design here in case it helps someone else. It all works, all the way from 1.6 to 160MHz, and it draws less than 20mA, but that’s about it. But, honestly, I can’t really recommend using these devices, or frankly, based on my experience, much of anything else from Cirrus Logic.

There are better devices (and vendors!) elsewhere. My subsequent si5351a-based VFO works precisely as the datasheet states. OK, the Silicon Labs datasheet is complex and the device requires some quite demanding calculations and software to get it running, but, hey, Silicon Labs support their chips and answer questions.

The Design

The compact signal generator design is shown in the schematic below. (I’ll show the schematic of the even smaller Tiny85 version further down the page)

Figure 2: The schematic] diagram of the ATmega328 controlled CS2000 DDS oscillator / signal generator

The microcontroller controls everything, of course. At power up, it initializes the display and the CS2000 by sending a brief string of I2C data to the LCD and another short data burst, this time via the SPI bus, to the CS2000. The processor starts up with two frequencies saved in program memory. “VFO A” is set to 5.00MHz, and this is sent to the CS2000 at power-up. “VFO B” (the “memory” channel, basically) is set to 75MHz. VFO A or B can be selected using the A/B pushbutton. The output from the CS2000 is a 3.3V square wave.

For simplicity, 3.3V supplies everything in the generator including the LCD. An LM317L low power regulator in a compact TO-92 package is used to drop the external supply to the required 3.3V. The external supply can be anything from 6 – 12V usually, but the oscillator seems to work fine with a 5V external supply.

The rotary encoder allows tuning in 5, 50, 500Hz and 5kHz steps. Pushing the encoder inwards allows step selection. Larger steps of 1MHz are selected via the MHz Up and MHz Down pushbuttons. All of the pushbutton inputs have internal pullup resistors inside the microcontroller which thanks to the software.

The final pushbutton (“4xF”) multiplies the displayed frequency by four. E.g. If the display shows 10.000MHz, the CS2000 output is at 40.000MHz. This allows the generator to be connected to a divide by 4 quadrature divider (e.g. 74HC74). These are frequently used in SDRs so this button allows the signal generator to be used as a VFO with an SDR during testing.

 Of course, the CS2000 output frequency cannot exceed the limit of 75MHz (according to the specifications) or 160MHz in the case of my devices. If the user tries to exceed an output frequency of 160MHz, a “?” appears on the LCD on the far right hand edge of the displayed frequency.


As usual, I wrote the software using Bascom, the Basic-like compiler for the Atmel AVR family. The software is available for download below.


The generator was built up on a piece of prototyping board. The CS2000 was mounted on a tiny DIP-SMD adapter PCB to make construction a little easier. 

SMD adapter board with CS2000

Figure 3: SMD adapter board with CS2000

With the battery power in mind and as a distraction from the chip problems I was having, I experimented during the project with the design of a small 3D printed PLA enclosure with a curved base.  I use Designspark Mechanical for my 3D designs.

Figure 4: Top cover of 3D-printed case. The square hole on the right hand side allows access to the programming connector after the case is assembled.

Figure 5: Enclosure base

While the finished box fits easily in the palm of my hand, the base had enough space for a single cell AA battery and a compact boost converter to generate the required 3.3V supply. However, in light of the results and wanting to finish it off and put more effort on the better si5351 design, I just used an external wall-wart 5V supply. There was space for the necessary DC connector in the side of the printed enclosure base, and that’s where I mounted it.

Some small printed buttons sit on top of the switches on the prototyping board going
through the holes in the top cover to allow the switches to be pressed.

The panel artwork was a similarly quick design. It was cut out and trimmed to size, covered with adhesive clear plastic film and glued to the enclosure cover.

Figure 6: Front panel 

Version 2: The "Teeny Tiny Gennyrator" - The Tiny85 Version

As noted above, here's the schematic for the second more compact version of this design which is shown in Figure 2:

Figure 8: Schematic of oscillator #2. This version uses I2C to drive both the CS2000 and the LCD

If anyone wants to try this version, email me and i can send you the software.


The CS2000 oscillator works, but it was a battle. It’s compact and covers a useful range from about 1.5 to 165 MHz. The output is a 3.3V square wave.

Now that I have developed comprehensive software for the more widely used si5351a, backed by a more responsive vendor and a larger user community, I’ll be sticking with the si5351a. It’s also less expensive, about 25% of the CS2000’s cost, and it draws a similarly low current. In addition, the new si5351a chip also boasts three programmable oscillator outputs while this CS2000 chip has only one. Well, it’s an easy choice, really.

Meanwhile, this box can kick around the workbench for a while and serve as an extra RF signal source.


ATmega328 Version Software: Available for download here. Fuse settings are noted in the source code.

Enclosure: The STL format file is available here. It's printed using standard PLA.

Panel artwork: Available here

Want to go back to the main page? Click here to return directly.