Low Current Compact CS2000-based Signal Generator
Trials
and tribulations with the Cirrus Logic CS2000 DDS oscillator chip while
designing and building a new compact low current RF signal generator.
Introduction
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 circuitsalad.com 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.
Software
As
usual, I wrote the software using Bascom, the Basic-like compiler for
the Atmel AVR family. The software is available for download below.
Construction
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.
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.
Conclusions
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.
Downloads:
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.