Building an SDR around a Red Pitaya
This page is not about a finished project, but is rather a
sort of blog about a work in progress.
Over the last several decades radio technology has been moving in the
digital direction, like so many other things too. Digital signal
processing (DSP) started becoming commonplace in amateur radio
equipment from about 1990 on. At first DSP was only used to do the
demodulation, modulation, some of the filtering, and very specially,
doing kinds of filtering that cannot be done with analog technology,
such as non-coherent noise reduction. Such radios were conventional in
that they had frequency synthesizers, mixers, amplifiers, analog
automatic gain control circuits, worked as multiconversion
superheterodynes, until finally feeding the last IF signal into the DSP
system, typically at near-audio frequencies.
As technology advanced, more and more of the receiver (and transmitter)
chain was moved over from analog implementation into digital,
software-based systems. We started calling such things Software-defined
Radios (SDR), since really the software running at a given time defined
most of the characteristics of these transceivers.
The older generation
of SDRs still had a conventional receiver front-end, with an oscillator
or frequency synthesizer, and typically it would convert the RF signal
into two low (or zero) intermediate frequencies (IF), one of them in
phase and the other in quadrature (90 degrees off phase). These I/Q
signals would be converted to digital format and fed into the DSP.
Further technological advancements made it possible to move the frequency
down-conversion into the digital realm too. Such radios essentially take
everything that comes in from the antenna, digitize it, and do all
further processing digitally. They need fast analog to digital
converters (ADC) having enough resolution (14 bits as a minimum, 16 or
more bits is better), and since the amount of digital data coming out
of the ADC is more than what even a pretty fast computer can
it's first applied to a Field-programmable Gate Array (FPGA) , which is
basically a chip that has lots of configurable logic gates, adders,
multipliers, memory, etc, which are configured and interconnected by
programming. This FPGA is then used to synthesize a frequency with
numerical I/Q outputs, multiply (mix) those outputs with the data coming from the
ADC to produce two low or zero frequency IF signals, and then apply a process of sample rate reduction while gaining
resolution, which downsizes the bandwidth while gaining dynamic range,
and very importantly, reduces the amount of data to a level that a
computer can handle. After this point, a computer does all the
remaining processing. And in transmisison, simply the whole procedure
is done in reverse.
SDRs have a lot of advantages over conventional radios: The ability to
see spectral graphs of an entire band while operating, very
and infinitely configurable filtering, some filters that cannot be
implemented in small bandwidth radios (such as noise filters that can
tell static crashes from desired signals by detecting their wideband
nature), the AGC and ALC can be made highly effective and free from
attack overshoot, and many more. On the technician's side, there is a big
advantage in the fact that software doesn't go out of alignment, nor
does it wear out and fail! An SDR requires only minimal setup after being built,
and for the most part will never need realignment. This very stability
is what makes highly accurate filters possible!
SDRs also have disadvantages, of course: The leading one is probably
their latency. Unlike analog radios that process signals in realtime,
digital data is processed in blocks at several steps. So first a data
block has to be created, spanning a certain time of the input signal, then it's processed
while at the same time the second block is being filled with fresh data, and
only then is the first block delivered to the speaker, starting at its
beginning. In many cases there are more steps in the processing, such
as sending the pre-processed data blocks from an input card to a
computer for further processing, so that the total delay (latency) of
an SDR can be several times the amount of time required to fill one
data block. By good design, and using small data blocks, latency of
SDRs can be reduced to pretty good figures, and analog radios also have
some latency, mostly caused by their crystal filters - but still most
SDRs have longer latency than most analog radios. So they may not be
usable for certain communication modes that depend on very short
latency, for example modes that require very fast TX/RX switching.
Another disadvantage perceived by some older hams is the "mouse effect":
These people enjoy having large radios on their desks, with a front
panel having as many knobs and buttons as possible. Very specially they
demand a big, nice-feeling, round and hefty tuning knob, and despise
what they call "mouse radios". Well, it's true that an SDR can be
100% controlled just by a mouse, clicking at different things shown on
a screen, and very often exactly this is done. Instead of rotating that big tuning knob, you click on a
spectrum display and drag it to tune over a band, or you simply click
on a signal you see, to instantly tune it in. The fact is that most
people get to love this functionalty after just a few days using an
SDR, so much so that an old-fashioned tuning knob soon seems very old
and cumbersome to them. But for those diehards who cannot live without
a tuning knob, well, it is entirely possible to set up such a knob with
an SDR! Still some people who haven't ever even tried "mouse radios" keep
saying that radios shall have knobs, and lots of them...
When SDR was starting to be a really hot topic, a widely dispersed
group of hams started developing an open-source high
SDR. The first steps of the project were still based on a conventional
analog downconverter feeding a low IF as I/Q signals into a soundcard,
but very soon the main project became a direct-sampling SDR.
OpenHPSDR hardware consisted of several separate cards, such as a
receiver, a transmitter, an USB interface, an ethernet interface, a
sound card, etc, that could be plugged into a backplane. The whole
setup was connected to a PC running Windows and PowerSDR or similar
software, and after adding a power amplifer, filters, and TX/RX
switching, the result would be a complete, functional, high performance
A ham wanting to assemble his HPSDR faced several difficulties: The
availability of these modules, as kits or ready-made, has been rather
poor. Completely building one's own from published data is really hard,
because multilayer circuit boards and many tiny SMD parts are
used, a good number of which aren't easy to find. And lastly, the whole
thing is very expensive, far more expensive than buying a pretty good
significantly eased this situation is the development of the
Hermes board, which is essentially the entire openHPSDR on a single card, replacing the separate
receiver, transmitter, interface and backplane cards. So now it became
possible to get into OpenHPSDR by just buying a Hermes card, adding a
power amplifier, filters, switching, connect it to a PC, and get on the
air. And the Hermes card was available for quite some time -
the price was stiff, at close to US$1000 plus international shipping
plus taxes. So a complete radio built around a Hermes board would still
be more expensive than a factory-made radio. And last time I checked
(May 2017), the Hermes seems to be no longer available! But there are a
fair number of Hermes cards around, and some become available
The Hermes board does all of its processing in a single, large FPGA.
The program for this FPGA can be loaded from the host computer. Hermes
uses a 16-bit ADC and DAC, running at 122.88 MHz.
The OpenHPSDR hardware is most commonly used with a special version of PowerSDR,
the same software used for years by FlexRadio, a commercial
manufacturer of SDRs. For the communication between the software
and HPSDR hardware a protocol was defined, that originally
over an USB connection. This protocol was enhanced many times, to add
features and improve performance, and eventually was grafted onto
ethernet connections, by simply putting the data packets prepared for
USB into wrappers so they can be sent over ethernet, using UDP frames.
Later a new protocol was developed, that allows for more features, and
more quality. The new protocol is defined specifically for ethernet, separates data
streams and uses different logical ports, allows a large number of
simultaneous receivers, and so on. As far as I understand, currently
existing hardware and software still uses the old protocol.
The Red Pitaya:
2013 a group of clever people in Slovenia got together and
developed the Red Pitaya, as a Kickstarter project. The aim was to
offer it as a highly educational, user-programmable fast dual-channel
input/output board, to be used as oscilloscope, spectrum analyzer,
signal generator, and so on. It turns out that the Red Pitaya has
everything on board that's needed to use it as the core of an SDR,
almost as a direct replacement of the Hermes board. And soon Pavel
Denim developed several programs for the Red Pitaya that allow doing
The Red Pitaya has some disadvantages and some advantages relative to
the Hermes board. For example, it only has 14-bit ADCs and
DACs running at
125 MHz, compared to the 16 bits boasted by Hermes - but it has two
channels of each, compared to the Hermes' single channel! I understand
that the Red Pitaya's FPGA is significantly smaller than the Hermes',
but then the Red Pitaya has a dual-core ARM CPU built in, with lots of
memory, and runs Linux! And the biggest difference to Hermes: It costs
only one third as much. And this means that it is possible to build an
SDR around a Red Pitaya for less money than an equivalent factory-built
radio would cost. You cannot do that with a Hermes, at least not with a
Hermes bought new.
My SDR project:
In early 2017 I decided that it was time for me to get seriously into
SDR, and after confirming that the Red Pitaya was my best option, I
purchased one. My final goal is to put together an SDR having the
following fundamental characteristics:
- 160 to 10 meter coverage (6m would be possible too, but is pretty
irrelevant to me, so I prefer to leave it out to ease the transmitter section);
- Legal limit RF output power (that's 1200 watts in my country);
- High efficiency power amplifier, most likely class E running in EER
- Build as "black-box" radio connected to a PC at first, and in a
second step build a small embedded PC right into it to make it stand-alone;
- Keep everything as low-cost and simple as possible.
The PowerSDR software has specific support for EER (Envelope Elimination
and Restoration) transmission, and also has an adaptive predistortion
system to correct nonlinearities of the TX power amplifier chain.
And Pavel Denim made a program that allows
Pitaya to emulate the Hermes board. So this all seemed to be fitting
together pretty well. Just keep reading, and see my further adventures
and blues in this area.
Buying the Red Pitaya:
When I went shopping for the RP on the web, my first discovery was that
there was no place where one could buy it! It turned out that the
company making it had stopped selling the card by itself, and is
instead packaging it into kits, called STEMLab. The most basic kit, the
"starter", includes a power supply, adapters, a cable, and a preloaded
SD card, and already costs significantly more than a bare RP would. Oh
well. More complete kits include oscilloscope probes and other
accessories, which are absolutely not needed for SDR use, and they are
much more expensive. And there is a trap: STEMlab kits are sold in
125-14 and 125-10 versions. The -10 versions only have 10-bit ADCs and
DACs, and also have less memory! They are useless as SDRs, due to their
insufficient dynamic range.
So, if you are shopping for a Red Pitaya card for use as an SDR, buy a
"STEMlab 125-14 starter kit". That gets you the correct Red Pitaya
card, plus power supply and SD card, for the least possible money.
Most distributors I checked were out of stock when I tried to buy this.
Even the manufacturer's webstore was out of stock! The two I found that
had the RP available were both located in Germany. So we (CE6SAX and I)
placed an order with Reichelt in Germany.
Soon we got our RPs.
Firing up the Red Pitaya for the first time was pretty easy: Insert
the SD card (which acts as hard disk for the RP's Linux system), connect
the power supply, connect the network cable to my router, and apply
power. The LEDs gave their proper signs of life. The
for installing a certain third-party printer sharing utility that
allows connecting to the RP by its hardware address. This didn't work
for me, and it's totally unnecessary: One can perfectly well connect to
the RP using its IP address rather than its hardware address. The RP by
default gets its IP address via DHCP from the router, so connect to
your router, look at its DHCP client table, and you will find
IP address it assigned to the RP. Then point your web browser at this
address, and you will get the RP's screen. To avoid having to look up
each time which IP address the RP got assigned, it's typically more
convenient to configure the RP to use a fixed IP address. More about
Via the browser you can see which applications come preinstalled -
which doesn't mean that you can use all of them, as some require paid
"activation". My advice: Just don't use those. Instead navigate to the
user-contributed applications, and download what you want to use. You
will find oscilloscopes, spectrum analyzers, signal generators, various
other test instrument applications - and also several SDR applications.
Simply download what you want, and a moment later you can run them.
They are saved to the SD card, so next time they will be there - you
just need to start them each time.
After doing this much, the RP's tiny heatsink will be hot enough to
cook some eggs on it. In the interest of long-term reliability, it's
highly advisable to purchase a little fan that fits the heatsink and runs
from 5V. Such fans can be bought cheaply on eBay and elsewhere - try to
find a quiet one. A connector that provides power for the fan is
provided on the RP. While you are waiting for that fan to arrive, point
any other fan at the RP, to keep it cool. And in your definitive SDR,
plan on mounting the RP against a larger heatsink, part of the box, or
buy the special RP box, which also acts as heatsink - because tiny fans
are notoriously unreliable, and a dead fan might only be noticed when
the RP fails from overheating!
are several SDR programs available that can use the RP. Since
I had already installed HDSDR (Note: This is an SDR program,
compatible with the HPSDR!), which I used with the cheap RTL-SDR
dongle before, and noticing that there is an HDSDR-compatible transceiver
application by Pavel Denim available for the RP, I downloaded and tried
that first. One has to download a driver library too, named
ExtIO_RedPitaya_TRX.dll, and copy it into the HDSDR directory. Then
HDSDR gave me the option to select between the RTL-SDR and the Red
Pitaya, and I got my first SDR experience with the RP: Wow!
In this screenshot a 1250kHz wide swath of spectrum, including the 40m
ham band and the 41m broadcast band, is visible at once. A ionosounder
signal sweeping through the band left a clear track on the waterfall
display. Below are a spectrogram and waterfall of the demodulated audio
signal on 7085kHz. The bandwidth is adjustable by dragging the filter
slopes with the mouse, tuning is by clicking on the desired signal or
by adjusting the numerical frequency display. The S-meter, once
calibrated, is accurate over the full range, and the reception quality
HDSDR is an excellent program for general receiving, and in fact I
prefer it over all others I have tested so far. But it doesn't provide
much transmit capability, just the most basic - which I
haven't tested yet - and isn't really
designed to act as a transceiver controller. So, PowerSDR (freeware) or
perhaps Zeus Radio (payware, with free limited demo available) or some
other program of that sort need to
be used for a ham transceiver. This requires downloading and running
Pavel Denim's HPSDR-compatible transceiver software for the Red Pitaya.
I did that, but ran into trouble with the PC software: Neither PowerSDR nor Zeus would
install on my machine!!!
I had Windows XP SP2 on my PC, and despite all blah blah about it being
outdated and almost criminally dangerous to use due to termination of support
by Microsoft, it still serves me very well, has never gotten infected,
and an attempt to upgrade to Windows 7 Ultimate some time ago failed
miserably, as the installation DVD of Win7 I could get refused to upgrade my existing system and insisted
on a clean installation, then many of my programs and drivers (I use
more than 200 different programs) wouldn't run on Win7, and Win7 had
several nasty bugs for which there were no fixes, and would phone home
all the time without really letting me control that. So out it went, I
restored my XP installation from the backup, and since then
done any further attempts at upgrading.
I found hints that PowerSDR could run in XP, but only when SP3 is
installed. I had tried installing SP3 some time ago, before that
attempted upgrade to Win7, but it failed to install. Now I tried again.
It failed again. After spending lots of time on this issue, I was
finally able to find a version of SP3 that installed correctly on my
specific version of Windows XP SP2 - there are more different and
incompatible versions of Windows XP and SP3 out there than
you might think!
PowerSDR installed without any problem on Windows XP SP3. Zeus
Red Pitaya software and configuration:
Downloading Pavel's programs from the Red Pitaya website, directly to
the Red Pitaya, works fine, but requires starting the program via a web
browser every time the RP is powered up. If the RP will be used mostly
or only for SDR, it's far more practical to have the relevant RP
program self-start right after powering up the RP. This can be easily
done by downloading the relevant SD card image file from Pavel's website,
and unzipping its contents onto an empty, FAT32-formatted SD card. This
card will then contain a version of the RP operating system and the
preinstalled applications, and in addition, invisible on a web browser
accessing the RP, Pavel's software will be running. If you start
another RP application rom the browser, Pavel's program is aborted, but
power-cycling the RP will restart it.
To unzip the image file onto an SD card, you need nothing more than a
zip program such as WinZip, and an SD card reader/writer. If you don't
have such an SD card reader, you can use almost any digital camera in
The documentation says that the SD card for the RP needs to be at least
4GB in size, and have a speed rating of class 10. But what actually
gets copied to the card is far less, only about 70MB! I read somewhere
that the full development environment needs the 4GB card, but to just
run RP applications you don't need that. In fact the SD card that
was delivered in my STEMlab kit seems to be one of those Chinese eBay specials:
It claims 4GB capacity on the label, but its actual capacity is just
120MB! Still that's plenty to hold the "Red Pitaya Ecosystem" along
with a good number of applications.
Update (2017-7-3): The SD card delivered with the RP is not
a fake! It just comes formatted to far less than full capacity. If you
want to reformat it to its full size, download the program
"SDFormatter". Put the card in a card reader, copy all of its contents
to a zip file (with folders), then use SDFormatter to format the card,
choosing " full overwrite format, format size adjustment on". This will
format it to full size. Do not choose quick format, because that will
produce a card that seems to have full capacity, but fails to write
beyond the previously formatted size! After this you can expand your
zip file back onto the card, and it will run in the RP as good as it
did before, but with a huge lot of extra capacity for adding programs
and storing data. My thanks go to Gerald, DL3KGS, for hinting me at this, and suggesting SDFormatter!
It might be a good idea, although not essential for a plain user of RP
software, to download and install some programs to access
the Red Pitaya's Linux system. PuTTY can be used to open a console connection
to the RP. Log in as "root", password "root". You need to be fluent in
Linux to do anything there. And WinSCP can be used as a file
manager, editor, etc, for the RP, working very much like any other file
manager. Both of them work over the ethernet connection - you don't
need to add an USB connection to the RP, even if that's yet another
If you let your router dynamically assign an IP address to the RP, it
might get a different address each time, if there are various other
devices connecting and disconnecting from the router. So you might have
to ask the router every time at which address your RP landed! That's a
nuisance. In such cases it's better to configure the RP for a fixed IP.
Also if you
want to connect the RP directly to the PC, without a router, you need
both the PC and the RP to have fixed IP addresses. The PC can be
configured via the Windows Control Panel. The RP is configured by
editing a file named interfaces,
located in the etc/network
directory. The file has comments in it making it self-explanatory,
although after setting the RP for a fixed IP I couldn't make it connect
to the web anymore, although it worked fine with SDR software. The interfaces
file tells that one should make changes also to another file, but I
couldn't find what to change inside that one... and that's likely to
have been the reason why web connectivity was lost. Anyway, I it back
to DHCP for now.
can edit the configuration either through WinSCP, with the SD
card installed in the
RP, and first issuing a "rw" command via PuTTY to make the SD card
writable, or you can put the SD card into your card reader and edit the
with any Windows text file editor. The latter is much easier.
Red Pitaya modifications:
The RP has oscilloscope-like inputs, with an input resistance of 1MΩ in
parallel with a small capacitance. It can be jumper-configured for two
different input ranges, the more sensitive one being ±1V. This doesn't
suit radio work very well. 50Ω inputs have the advantage that the
length of coax cables doesn't affect the frequency response, and the
sensitivity provided by a 14-bit ADC scaled for ±1V is not
satisfactory for radio reception, except on the lowest bands in
evenings when the propagation is strong. So some minor modification is
convenient, if the RP will be used only or mainly as an SDR.
The first thing that can be done is very easy: Even the ±1V range is
configuring an input voltage divider for a 2:1 ratio. By removing one
of the jumpers, and placing the other over the two center pins of the
6-pin block, the RP is configured for an input range of ±0.5V. That's a
6 dB improvement, for free! The input impedance in this configuration
very high, so if desired one can solder a 51Ω resistor across
the input connector, to achieve a nominal 50Ω, DC-50MHz, almost
flat input response with a
card's high input impedance allows doing better than that. We
can obtain some "passive gain" by using a little RF transformer. There
is a limit to how much can be achieved, because the higher the
transformation ratio, the higher is the output impedance of such a
transformer, and the RP's capacitance will soon limit the frequency
response if we overdo it. But a 3:10 winding ratio is well within
the possibilities. I selected a small binocular ferrite core,
specifically a Ferronics 12-350-J, roughly equivalent to a Fair-Rite
2843002402, also known as Amidon
BN-43-2402. The Ferronics is just a little longer than the Fair-Rite
one. I wound 10 turns of AWG #36 wire on it, tapped at 3 turns. The tap
gets soldered to the RP's input connector pin connection, the 3-turn end is
soldered to ground at the same connector, and the 7-turn end is
soldered to one of the little configuration jumpers. Also a 1kΩ
resistor is soldered from this jumper to ground (at the input
connector), and the jumper is inserted just on pin 5 of the pin block.
For now this trafo is dangling just from its very thin wires, but
since it works so well, I will fix it in place with a dab of hot melt
glue someday when I feel generous.
This transformer provides a theoretical passive gain of 10.46 dB, and
the 1kΩ resistor combined with the losses in the ferrite core provide a
reasonably accurate 50Ω input termination all over the HF range. On the
160m band this transformer starts running out of sufficient inductance,
so the input impedance goes inductive and low, an effect that increases
at even lower frequencies. This is a desirable behaviour for an SDR
transceiver, as it acts as a progressive attenuator on the MF, LF, VLF and
ULF bands, on which there is usually a huge lot of noise which we want
to keep out of the ADC. It doesn't impair reception of those VLF
signals, because these tend to be extremely strong, but one needs to
keep in mind that the S-meter indication provided by the software will
become progressively inaccurate on frequencies from the 160m band down.
So, input 1 of my Red Pitaya now has a nominal 50Ω impedance, and about 16dB
higher sensitivity than in its stock configuration. Input 2 instead
will only be used for feeding back my transmit signal, for the
predistortion system, and that's well served by the stock ±1V input
range. I just added a 51Ω resistor soldered to the input 2 connector,
in order to have a clean and predictable wideband behaviour when using
coax cables of varying lengths during experimentation and final
RX front end
I played with the modified RP for several days without adding anything
else, and found the sensitivity (noise floor) to be good enough at all
times on bands from 30m downwards, and most of the time it was also
satisfactory on 20m. But on higher bands clearly some more gain in
front of the ADC is necessary. So I looked into my junk box, searching
for parts suitable to build a preamplifier. I found some J310 JFETs
which would serve beautifully in common-gate preamplifiers delivering a
modest gain, around 10dB, and I also found various low noise RF bipolar
transistors that could be used with gains of 10 to 15dB, but more
attractive was a small set of samples of the MAR series of MMICs
(Microwave Monolythic Integrated Circuit). I picked the MAR-6 from that
set, which has 21dB gain and 3dB noise figure, working pretty much from
DC to daylight as far as HF equipment is concerned. While this is an
antique device, it's still available at low cost at places like RF Parts.
Far more modern and even cheaper MMICs are available at many places,
even on eBay, but I used what I had.
is trivially simple: Apply the well bypassed supply voltage through a
properly calculated resistor, connect DC blocking capacitors to the
input and output - and that's it. I cut a piece of unetched
PCB material as a breadboarding groundplane, and assembled the
preamplifier on a corner of this board. The tiny black pill is the
MMIC. Now the RP SDR really came to
life! While on 40 meters and lower just the S-meter deflected more
strongly, on the high bands the SDR started hearing everything my good
old Kenwood TS-450 hears, and then some. I tested the noise floor with
open input, 50Ω-terminated input, and with the antenna connected, and
found that the 21dB of gain provided by this MMIC, along with its noise
figure, are entirely adequate even when propagation conditions
are poor. The
receiver's noise floor ends up 8 to 10dB below the atmospheric noise,
in my very RF-quiet forest location. More gain than this would make no
sense, and would unduly compromise the receiver's dynamic
few dB less
preamplifier gain might be optimal, but for the moment what I have is
The RP has a 125MHz sampling rate. This causes any signals above
62.5MHz to be aliased into the 0-62.5MHz range. It is thus necessary to
reject those signals before they reach the ADC. The RP only
has very basic low-pass filters built in for the input channels, and the result is
got FM broadcast signals on 88-108MHz aliasing strongly into the
17-37MHz range, and TV signals on VHF channels 3-6 aliasing into the
frequencies above 37MHz. Particularly on the 15 and 12 meter bands I
got a lot of QRM from these alias signals. So I added a 7-pole, 32MHz
Chebyshev low-pass filter in front of my MAR-6 preamplifier. I wound
the inductors on tiny T-20-6 cores, because I have a lot of
With this filter in place there is now no sign remaining of any
But my receiver front end has no further filtering so far. The 32MHz
low-pass filter cutting off VHF signals, and the transformer
the RP input attenuating MF, LF and VLF signals, is all the filtering
there is. The result is that when listening on the high bands in the
evenings, when propagation on the high bands is very weak but lots of
shortwave broadcast stations on about 5-16MHz are booming in with
S9+30dB signals and more, I get a comb spectrum of little carriers
spaced 5kHz apart. These must be mainly second-order IMD products
caused by nonlinearities mixing the broadcast signals. These carriers
are typically up to about 15dB above the noise floor, so they would be
easy to reject by using very modest band-pass or high-pass filters.
Maybe just a single 17MHz high-pass filter, switched in when operating
on 17 meters and higher, would be enough to cure this problem, but of
course a more solid solution is to either use a set of proper
band-switched band-pass filters, or use a set of high-pass filters that
are combined with the low-pass filters that will be needed at the
transmitter output. Adding these filters is something to be done in the
final SDR. For the time being, during the experimentation phase, this
IMD QRM is unimportant enough to ignore.
An audio CODEC for the Red Pitaya:
Hermes board includes an audio CODEC that provides speaker, headphone
and line outputs, plus microphone input. The Red Pitaya doesn't,
although it does have general purpose slow analog inputs and PCM
outputs, that might be pressed into audio service. PowerSDR by default
uses the audio CODEC of the SDR hardware, although it can also be
configured to use the PC's sound card. To level the field between the
Hermes and the RP, some hams like to add an external audio CODEC board
to the RP. I was given one of them, and while I don't yet know whether
I will use it in my final SDR, it's certainly proving useful for testing.
For example, there is the issue of antenna-to-speaker latency, of much
concern to SDR folks. I was told that using this CODEC is almost
essential, because PC sound cards have an enormous latency. Well, this
proved to be the case only when using standard Windows drivers for the
sound card, such as MME. Indeed they introduced more than 100ms of
additional latency! But using the PC's sound card with ASIO drivers
actually resulted in a tiny little bit less latency than using the CODEC
connected to the RP. So the use of a CODEC board seems to be
entirely optional. People who want to have microphone
and headphone connectors and a speaker right in their SDR black
should use it, while those who use either an embedded PC with sound
chip in their SDR, or are happy using a desktop PC with the microphone,
headphone and speakers connected to the PC, will not need this CODEC.
In any case, it's a real plug-and-play solution: I connected it to the
RP as indicated in the instructions, and it immediately worked very
well, with no configuration needed anywhere. WhenPowerSDR is set up to
use the sound card, which it does via a Virtual Audio Cable (VAC), both
the PC soundcard and the CODEC at the RP work at the same time. But the
mic gain control of PowerSDR only acts upon the CODEC, while the gain
of the microphone connected to the PC has to be set via the sound
card's mixer program.
Pavel's RP software supports four digital outputs that emulate the ones
Hermes has. The behaviour of these can be freely configured on a per-band
basis in PowerSDR. This allows easily switching RX and TX filters. Also
there are output pins that can be used to switch the RX preamplifier,
and an attenuator. I haven't yet gotten the attenuator pins to work,
but I really haven't tried seriously, because I don't intend to install
a step attenuator. Just switching my 21dB preamplifier in and
should be plenty for matching the dynamic range to band conditions, at
least at my rural place.
When not using an audio CODEC, the pins liberated that way can be used
to implement a far more sophisticated control of filters, attenuators,
antenna ports and
other devices, by means of shift registers. I don't foresee to use this
feature, since I don't think I will have any need for it. But it's
there, for those people who want to build a more flexible SDR.
Other digital I/O pins of the RP are used as PTT input, TX/RX output,
iambic keyer input, GPS time sync input, and two slow analog inputs of the RP are
used to read transmitter forward and reflected power. All this is
pretty good and should allow building a practical transceiver that
doesn't need physical switches nor other control devices on the front panel.
Everything can be controlled from the PC.
I discovered a funny bug in PowerSDR, when testing the PTT function:
Using the MOX button on the screen results in loud crashes in the
speaker when switching from RX to TX and back. Instead doing the same
switching via the PTT input of the RP does not result in such crashes. Since one
would normally always use the PTT, this is no significant problem. It's just
funny. One would expect the MOX function to work just like the PTT, but
of course they reach the innards of the software through very different channels...
An evil case of popping disease:
While I played with the RP and PowerSDR over days and weeks, a far
problem became impossible to ignore: There is a clicking and popping
appearing both in the audio output and on the spectral display. When
all signals in a band are of roughly the same strength, this problem is
nearly unnoticeable, but when receiving a strong signal on an otherwise
rather quiet band the popping becomes very noticeable. Listening to a
weak signal in the vicinity of a strong one is severely hampered by the
popping. Applying a clean
carrier from a signal generator to the RP and tuning to this carrier
makes the problem absolutely obvious:
I asked other people who use the RP with PowerSDR, and it turned out
that two of them have the same problem, with one of them having noticed
it before, and the other noticing it only when I pointed him to it.
Also one user reported not having this problem. So far these three
reports are the only ones I got. Including me, it's three users getting
the pops, and one not getting them. There must be a true problem.
A web search produced lots of results from people getting the pops when
using PowerSDR with other hardware, such as the FlexRadio
I made lots of systematic tests. My results so far are:
- The problem happens exactly the same regardless of whether I use the
PC sound card for audio output, or the CODEC connected to the RP.
- The problem is independent of the CPU load, and that's surprising.
Even when forcing a 100% CPU load by running a video conversion program
at the same time as PowerSDR, the popping does not change.
- Changing the process priority of PowerSDR does not change the popping either.
- Disabling my firewall (ZoneAlarm) strongly reduced the amount of popping, but
did not eliminate it. Disabling other resident
and services did not change the popping.
- Generating additional traffic over the ethernet, by downloading data
from the internet, does not seem to make a noticeable change in the
number of pops. But this isn't very relevant, because my internet
connection is slow, so that even the most intense web traffic I can
generate is small compared to the traffic between the RP and the PC.
- Connecting the RP directly to the PC, instead of through my router,
makes no difference.
- Changing the buffer size and the sampling rate in PowerSDR has a
strong effect on the problem. Playing with this, I found that switching
between 1024 and 2048 bytes per buffer makes little difference, but
that otherwise there seems to be a relatively linear relationship
between the total number of buffers transferred (sampling rate
divided by buffer size) and the number of pops I get, but there is a
sort of baseline number of pops per unit of time, which cannot be broken by any
- The sound of each pop changes with the sampling rate, but
not change with buffer size. I assume this has to do with
PowerSDR's filter responses changing with the sampling rate.
fact that the buffer size has no effect on the sound might indicate that
each pop is caused not by the loss of a complete buffer, but only one
sample. I'm just guessing here...
- When the test carrier is tuned exactly to the center of the spectral
display of PowerSDR, the popping gets so weak that it almost completely
disappears. This is interesting! This SDR is a zero-IF system, that is,
the signal coming out of the numerical mixers (multipliers) in the FPGA
is pure DC when the signal is tuned exactly to the center of the
bandwidth. And a DC signal means that all samples contain the same
numerical value, so that missing a sample, or many, won't change the
audio output! Instead when the signal is tuned even slightly off-center, it
turns into a low frequency IF signal, and missing samples will cause phase
jumps. So, this "discovery" seems to show that PowerSDR is either
skipping samples, or doubling up samples, or changing the order of
- I checked the latency my computer has in the execution of
time-critical interrupts, using the DPC Latency Checker
This program reported the latency to always stay in the
range, and changing settings in PowerSDR that result in more popping
did not affect the measured latency. It doesn't seem to be a DPC latency
In any case the problem seems to be localized in the data flow between
the RP and the digital signal processing on the PC getting stalled,
delayed, corrupted, or whatever. Is this perhaps a case of buffer
overflow or underflow caused by slightly differing
rates? After all, the RP and the PC don't have their clocks
synchronized! 192kHz in the RP might well be 0.001% or so different from
192kHz measured by the PC clock. If this isn't correctly handled by the software, data corruption will happen.
Then I tried again running HDSDR instead of PowerSDR,
using Pavel's HDSDR-compatible RP software. There is no
problem at all in that setup, even at 1250kHz sampling rate, which is
much higher than the highest rate supported by PowerSDR! This proves
that there must be either some
bug or some non-optimal implementation of something either in PowerSDR
(more likely) or perhaps in Pavel's HPSDR-compatible RP software (less
likely, I think, given the many reports of popping with PowerSDR and
The one report I got from a ham who does not get this popping prompted
me to try a newer Windows version. I installed Windows 7 Ultimate on a
clean SSD, then installed nothing else than the drivers for my
motherboard chips, for my sound card, and then PowerSDR. I
Windows 7 for as little internet traffic as I could, and ran tests with
the internet connection disabled, to prevent interference. The result
was interesting: As long as nothing else was done on the computer,
PowerSDR ran pop-free in this setup, but any activity, even if it was
just moving the mouse, resulted in much more popping than under Windows
XP! Also the reaction of PowerSDR to changes in the sampling rate and
buffer length was more critical.
Then I tried to install the demo version of Zeus Radio, and voilá, it
installed fine under Windows 7, after asking me to install a specific
version of a runtime environment. But.... it popped exactly as badly as
Now that opens a big question: Is the bug in Pavel's software? Or did
the authors of Zeus Radio copy sections of PowerSDR, which after all is
open-source? In the latter case both PowerSDR and Zeus are affected by
the same bug or non-optimal implementation.
Update about the popping problem (2017-6-29):
I made some more systematic tests. Using PowerSDR 3.4.1, I captured the
program's audio output while receiving a clean strong carrier, tuning
to a very low beat frequency (roughly 60Hz). I used DSB mode with the
widest possible filter setting, to preserve as much waveform detail as
possible. The result is interesting! It shows very clearly that blocks
of sample data get processed out of order!!!
This screenshot shows roughly one cycle of the 60Hz beat note, with one
of the nasty pops in it. After visually filtering out the high
frequency ripple added by the filters, we are left with the simple fact
that two sections of the waveform switched place! Each of these
sections is roughly 0.8ms long. The UDP packets sent by the Red Pitaya
contain 988 bytes of sample data, at a rate of 26 bytes per sample. At
the 48kHz sampling rate I used to capture this waveform, each UDP
packet contains 0. 792ms of data. So what's happening here is that two
UDP data packets were processed out of order!
I tried setting PowerSDR to different sample rates and buffer sizes.
The result clearly indicates that what's being processed out of order
are indeed UDP packets, and not PowerSDR's internal buffers.
Using sample rates of 192 or 384kHz the pops become correspondingly
shorter. Using different buffer lengths doesn't change the duration of
Not all of the pops are just two UDP packets processed in reversed
order. Many of the pops actually involve three UDP packets,
moving one forward in time by two slots! These two screenshots show
such cases. The UDP packet containing the data samples
corresponding to the approach to the negative peak of the beat note was
moved two slots left, then come the two UDP packets that were
skipped, and then the data flow continues normally. The same kind of
out-of-queue processing happened in the sample at right, only at a
different place of the waveform.
It's important to stress that no data seems to be lost. It's just
swapped out of sequence, not dropped nor repeated. After each pop the
sine wave continues without any phase shift.
Then I captured a few seconds worth of UDP packets, using Wireshark,
and looked at them. I spent a good while searching for any packets with
their serial numbers out of proper sequence, but couldn't find any. The
UDP traffic seems correct, as far as I can tell. What I might still do
is a write a small program to analyze the actual sample data, and see
if the Red Pitaya is sending packets with correct serial numbers but
swapped content. But this seems futile, given that the amount of
popping I get is strongly dependent on other programs running on the
PC, and on PowerSDR's setup, while the RP keeps operating exactly the
So my conclusion is that this problem is internal to PowerSDR, perhaps
triggered by other programs on the PC also requesting DPCs (deferred
procedure calls), and is not a problem of Pavel's RP software nor
of the UDP data flow between the RP and the PC. According to reports
from other people, using an extremely powerful PC seems to reduce the
problem to a level where it's not easily noticed in practical
operation, but there is a real bug that needs to be fixed.
Update, again! (2017-6-30):
I analyzed the UDP data, and it looks correct. So the facts are: The
Red Pitaya with Pavel's software is sending the correct data, my PC is
correctly receiving the data, and PowerSDR is changing the order
of UDP packets. How often this happens depends on CPU load, so that
when shutting down my firewall and NTP programs, and when configuring
PowerSDR to cause a lighter CPU load, I get far fewer of these
events - but I still get them, even at a total CPU load well below 10%!
They keep happening at a rate of ten to twenty pops per minute.
I can see that if any of my drivers (BIOS and otherwise) causes long
delays through poorly implemented interrupts and DPCs, the SDR software
might not be able to cope, due to an excessively small buffer, and
start stuttering. But I cannot see why it should switch the position of
UDP packets!!! This MUST be a bug.
playing with everything set up for least popping (disconnected from the
internet, firewall off, NTP off, all non-essential Windows services
turned off, PowerSDR configured for low CPU load) it became very
obvious that I have two different kinds of popping: One is the UDP
packet position switching detailed above, and the other is simply
audio dropouts. The audio signal goes to zero, and after 2.667ms
resumes at the same position of the waveform where it stopped. There is
no filter ringing on these dropouts, showing that these happen in the
audio stream, not in the input data stream. A simple calculation
confirms this: 2.667ms contain 128 samples at 48kHz, and I had the
audio buffer size in PowerSDR set to 128. Changing it to 256 doubled
the duration of each dropout, and halved the frequency at which they
occur, from about 35 seconds between dropouts to about 70 seconds.
These dropouts are surely caused by mismatch between the clocks of the
Red Pitaya and the sound card. Due to the finite accuracy of quartz
crystals, 48kHz derived from the Red Pitaya's crystal, and 48kHz
derived from the sound card's crystal are two slightly different
frequencies. These numbers also allow to compute the mismatch between
Pitaya's and the sound card's clocks: A whopping 46 ppm! Most of this
must be the sound card. Otherwise the frequency calibration in
would show it.
A good DSP program should handle this inevitable fact of life, by doing
a variable rate resampling or some other software trick, but PowerSDR
so far doesn't. If at least the program would skip or interpolate
single samples as needed, the resulting very minor clicks and
distortion would probably be small enough to go unnoticed. But zeroing
out an entire data buffer, with 128 or more samples, is pretty much the
worst possible way to handle a clock mismatch!
My appeal goes to the good people working on PowerSDR. They do it for
free, so neither I nor anybody has a right to firmly request a fix. But
I would still ask them to please look into both of these issues, if
possible. No matter how many great features PowerSDR has, it's not
really acceptable for daily use as long as it contains fundamental
flaws like these! Using a super fast, dedicated PC to get around
the UDP packet swapping problem, as often suggested, is an expensive
bandaid for an existing software bug, and doesn't do anything
about the clock mismatch problem.
I just fired up HDSDR again - it produces no popping whatsoever, even
when running it at over three times the maximum sampling rate PowerSDR
is capable of, and with the firewall and all other software enabled,
running a web browser at the same time, and several other programs.
This shows that there is no fundamental reason why we should live with
popping, nor need SDR-dedicated PCs! The popping of PowerSDR is caused by (at least) two software
bugs, and these should be fixed.
Being a BASIC hobby programmer myself, I strongly hesitate to even try
finding the bugs myself, in PowerSDR's extensive C source code. It
should be much easier for the people who have been working on that
software. But the bugs are probably buried deep inside, possibly even in libraries used by the program. A
web search shows that users have been complaining for many years
about the popping, even on the Flexradio website, and nobody fixed the
For the time being, the popping continues, and is a serious problem
that's making me reconsider whether it makes sense to build an SDR
this platform. I don't want to build a radio that sounds like
Geiger counter!!! Yes, I know what some people will suggest:
"Forget SDRs, and keep using your Kenwood!" I prefer looking
forward. The PowerSDR bugs have to be fixed!
And yet another update (2017-8-24)
Warren, NR0V, undertook improving PowerSDR to fix the popping.
Systematic testing showed that the problem of out-of-order UDP packets
isn't happening inside PowerSDR, but in Winsock2. That's the Microsoft
library that's used by Windows programs like PowerSDR to communicate
through the ethernet. The UDP packets were arriving in proper order in
my PC, but PowerSDR was sometimes getting them out of order. While it's
not nice that Winsock2 does this, one cannot really say that it's a
bug, because by the definition of the UDP protocol, packets are not
guaranteed to arrive in proper order! So Warren put some new code into
PowerSDR that re-orders such out-of-order packets, and this fixed the
problem that was causing the most pops! And since then he has been
working on solving the audio dropouts caused by lack of synchronization
between the acquisition clock and the soundcard clock. It looks like in
some more time PowerSDR will be completely free from popping even those
PCs having less than stellar performance.
Of the Red Pitaya's two RF outputs, only one is currently used by
Pavel's software. This provides the transmit signal, at a level
adjustable up to ±1V into a 50Ω load, which equals a power level of
10mW (+10dBm). Basically this signal has to be amplified by about 40 to
52dB, in a linear way, to be put on the air.
The RP's outputs are intended to be loaded by 50Ω, but they do not have
an internal 50Ω source resistance. To obtain the correct response from
the built-in 50MHz low-pass filters, it's important to load the outputs
with 50Ω. I built a simple and totally conventional class A amplifier
stage around an antique but good 2N5109 transistor, which was on hand,
just to act as a clean buffer stage and isolate any of my possible
mistakes from the expensive RP. This amplifier uses both emitter
degeneration and collector-to-base feedback. I can configure it for
gain levels of 10 to 15dB, by changing two resistors. 15dB gain means
316mW output power, and is about the upper limit for a transistor
running class A and dissipating 1W. Any higher power makes it clip the
signal and produce undue distortion. A gain level of 12dB results in an
ultra clean amplifier, that has the third order IMD products well below
I placed an order for some RD06 and RD16 MOSFETs, which seem to be the most
convenient devices currently available for HF amplification at
levels up to 20W or so, and my intention is to use these for an
amplifier that drives my big, fancy, high efficiency, high power final
stage. It's two months since I ordered these transistors, and they
still haven't arrived, thanks to ever-increasing delays at Chilean
customs. Oh well.
Update! The MOSFET drive amplifier (2017-6-20):
a looooong wait, finally the MOSFETs arrived, and I built a simple
two-stage driver amplifier, using a single RD06HHF1 as class-A driver,
and two RD16HHF1 in push-pull class AB.
The RD06HHF1 isn't really well suited for this driver stage. The Red
Pitaya delivers just 10mW, and this first stage is supposed to amplify
this to roughly 400mW. But the transfer curve of the RD06 begins
to get reasonably linear only at roughly 0.5A! So, at 12V, one needs to
run this stage at 6W input power, to get a reasonably symmetrical
output waveform. This makes for an efficiency of less than 7%! A
smaller MOSFET should have been better for this stage. But which? There
are some SMD ones, but for quick experimentation these aren't as
convenient as a good old TO-220.
When running this stage at lower current, the gain drops somewhat but
is still pretty good, while the symmetry of the output signal becomes
horrible. Interestingly the impact of this on the IMD is small. An
asymmetric waveform implies the presence of strong even-order
distortion products, while close-in IMD is purely odd-order. The most
obvious spectral effect of the asymmetry is instead a very strong
second harmonic. And the most prominent problem caused by signal
asymmetry is very unbalanced driving of the push-pull stage following
this one! One FET works much harder than the other, and there is a
significant DC component in the output transformer. For these reasons
I'm running the RD06 at 0.5A for now, achieving a symmetric-looking
waveform and better than -50dBc IMD, but for any definitive
implementation I would consider using the 2N5109 instead, or two of
them in push-pull. It's very linear at much lower current, and thus far
more efficient at a given level of gain and linearity.
I designed input and feedback networks that compensate for
the RD06's input capacitance and for its frequency response. The result
is an stage that has 16dB gain, very flat from 1.8 to 30MHz, and an
equally flat 50Ω input impedance. This is important, because the Red
Pitaya has a 50MHz low-pass filter on each of its RF outputs, and these
need to be loaded with 50Ω to deliver their correct frequency response.
The RD16HHF1 FETs were a rather nasty surprise. I had taken the
manufacturer's specs of "16 watts output per device at 55% efficiency,
at 30MHz, minimum, and 19W at 65% typical" at face value. But these
FETs just don't deliver that! Their RDSon is so high that at a nominal
12.5V supply voltage the rated minimum output of 16W is the absolute
maximum value, when the FET is running fully saturated, with a
square wave on its drain! Under these conditions the drain-source
stauration voltage is around 5V, which is sky-high for a 12.5V FET, and
the efficiency is scratching the 50% mark. In linear service
the best I could make them deliver is roughly 12W for a pair (just 6W
each!) at about 50% efficiency. Loading them at a lower impedance they
will do just a few more watts, at drastically lower efficiency. I got
17W for a pair, at 38% efficiency, and -26dB IMD.
So I had to change my goals, to meet these FETs' real capabilities.
Originally I hoped to get 25W in linear operation from the pair, at no
worse than 50% efficiency. After realizing that these FETs can't do it,
or at least not at 12-13.8V supply voltage, and changing my output
transformer accordingly, I'm getting 10-12W linear output, depending on
the band, at the drive level that gives an IMD3 of -30dB referred
to each tone, for the complete amplifier.
This isn't the definitive version yet, and that's why I'm not posting
the schematic right now. I intend to use this as a driver for the
development of a high efficiency, high power final stage, and I
don't know yet what the real drive requirements for this stage will be.
So my plan is to work on that final stage first, using this drive
amplifier as it is now, and then determine the specs for the definitive
And maybe - just maybe - the definitive one might even be built on a printed circuit board! :-)
No EER support!!!
While I wait for those FETs, and with the little class A
buffer amplifier in place, I started doing the preliminary
for my intended high efficiency, predistortion-corrected amplifier. The
first big and nasty surprise was that Pavel's HPSDR-compatible software
the RP does not support PowerSDR's EER transmission features at all!
This is really a very big downer. Sure, I can still make an
amplifier by using a conventional hardware-implemented envelope
detector, but it's pretty much impossible to implement the required
delay of the phase drive signal in hardware. PowerSDR implements it in
software, but that's inaccessible because of lack of an envelope signal
output in the RP
software! This is a double shame, because the RP is ideally suited to
EER, actually better than the Hermes, thanks to having two high speed
outputs, compared to the Hermes' single one. It should be comparatively
simple to add envelope output via the second DAC channel!
So, it looks like I will
only be able to implement a much lower quality EER system than would have
been possible through the use of the EER functionality provided by
PowerSDR, and it will be slightly more complex to implement.
In fact I purchased the RP mainly because I thought it would allow me
to make an EER transmitter having the proper time alignment between
envelope and phase! And then I found out that the only software
available for the RP does no support this...
Pavel now implemented EER on the Red Pitaya, by sending out the
envelope waveform on Output 2! Since then I'm building what's
necessary on the hardware side to run EER. I'm using an UC3638 motor
control IC as the pulse width modulator with dead-time control,
followed by an IR2110 high/low side MOSFET driver, and for now just a
pair of IRF530 MOSFETs in class D to modulate the 13.8V supply to my
test amplifier, through a 25kHz lowpass filter.
PowerSDR includes an adaptive phase and amplitude predistortion system,
called "PureSignal", that can correct nonlinearities of the power
amplifier chain. And Pavel's software fully supports this on the RP. I
installed the required RF feedback from my little test amplifier's
output to the #2 input of the RP, and started testing. There
some good and some bad news. The good are that the system easily
improved my amplifier's already very good -50dB IMD figure to
whopping -70dB, and at some times even -80dB.
The first bad news is that the results are a bit erratic, apparently
caused by the popping problem described above, and possibly also by
other software bugs. For example, the phase and gain diagram generated by the
system is sometimes very reasonable, and at other times it's totally
absurd, without me changing anything in the settings nor the hardware.
This needs some more investigation. Maybe the problem will go away if
the popping problem is solved - if that ever
And more bad news showed up when I tried to intentionally degrade the
linearity of my test amplifier, by running it into mild saturation, or
biasing it too low. When I did that, PureSignal didn't work at all! The
signal remained uncorrected, as bad as with PureSignal
deactivated! So it seems that PureSignal can make a good signal
excellent, but it cannot make a poor signal good. And that's very bad
news for me, since I hoped to build an EER amplifier, which inevitable
is quite poor in terms of amplitude and phase linearity, and correct it
through predistortion so as to obtain a decent quality signal.
I need to do more experiments with PureSignal, but the popping problem must be solved first.
Talking over with Warren the erratic behaviour of PureSignal on the Red
Pitaya, it turned out that it was mainly due to the signal level
produced by the RP on RX3. PureSignal requires a specific signal level.
Pavel fixed this in his software, and now PureSignal works very well!!!
The only important limitation I still see with PureSignal is the
limited correction bandwidth. While it can reduce all spurs within
±20kHz to negligible levels, even for pretty crummy amplifiers,
it cannot do anything about spurs lying outside that range. So whatever
amplifier one uses needs to be clean enough to have all high-order IMD
products and spurs sufficiently well attenuated, pretty much regardless
of how dirty it is close-in. And then PureSignal can be used to
dramatically improve the signal purity inside its ±20kHz correction
This allows obtaining very good signal quality even from strongly
overdriven amplifiers, while underbiased amplifiers end up producing a
larger amount of far-out IMD, limiting how low one can set the bias
before this IMD becomes a practical problem. Anyway, even with almost
no idling current, the uncorrected far-out IMD is suppressed at least
50dB, and typically more, so it might be considered acceptable.
It will be interesting to see how well an EER output stage fares with PureSignal!
Is there any point in continuing this project at all?
This sounds a little harsh, but it's a question inevitably going 'round
in my head. My core interest in building an SDR was implementing a
pretty good high
power EER amplifier, using PowerSDR's EER capabilities, and then
correct the remaining distortion through PowerSDR's adaptive
predistortion. So, basically I wanted the Red Pitaya as a system
to properly drive and bend straight a big EER amplifier, having the
typical SDR advantages for receiving thrown in as a bonus. And
the reality I
see now is that because of lack of EER support in the RP software I
can't use the EER features of PowerSDR at all, limiting me to a rather
EER implementation without the required delay of the phase signal, and
then I won't be able
to correct it at all through adaptive predistortion! That's just as bad
as driving an EER amplifier from an old technology, analog exciter! It
simply crashes my project! And the bonus SDR receiver keeps
popping like a Geiger counter...
Sure, I could instead build a totally conventional class AB power
amplifier chain that has good enough linearity, and just live with the
popping. But instead of doing that, I could as well keep using my old
TS-450 transceiver and NCL-2000 linear amplifier! This whole SDR project isn't attractive to me if
high efficiency, high power transmitter producing a decent quality signal can't be implemented.
I even toyed with the idea of trying to get into the source code of both PowerSDR and Pavel's RP program, to try
and fix the popping, and to implement EER functionality in the RP. But that
seems awfully difficult to a 52 years old electronician, who
is fluent neither with Linux nor with C nor with FPGA programming, and
whose programming experience is mostly in BASIC, Assembly,
microcontrollers and computers running relatively simple operating
systems. It seems far more likely that I will have to wait, and cross
my fingers that the authors of this software will keep improving the
programs so that it will work perfectly and do all the things I need.
In the meantime, it's fun to play with SDR and learn.
And an update to this, too! (2017-8-24):
Thanks to the help of Warren and Pavel, improving the software, it now
does make sense to go forward and try building my high power, high
efficiency SDR transceiver. So I have ordered an MRF1K50N and the
lot of other parts required, and until everything arrives I will be
experimenting with EER using my small RD16 drive amplifier as a guinea
pig. I don't know yet what exact flavor of EER, H-EER, ET, etc, will
work out best, and I only have some unproven ideas about how to make a
bandswitched high efficiency final stage. They will have to be tried
and tested. Pure EER is still not possible with the existing software
combination, specially in combination with predistortion, but ET should
ET test successful!! (2017-8-26)
Envelope Tracking test setup described above was completed and tested.
Since I built it on a protoboard, there is some interference from the
switching power stage into the pulse width modulator, causing some
distortion on the amplified envelope signal, plainly visible on a
scope. Even so, the resulting RF output signal is surprisingly good -
and can only get better if the PWM is properly built!
The spectrum shown here depicts the RF output obtained, with over
300kHz bandwidth to allow seeing the most important things. The IMD3 is
40dB down - that's significantly better than what I obtained from this
amplifier in class AB "linear" operation!
All amplifiers powered by a switching circuit (switchmode power supply,
or as in this case a switchmode modulator) will produce sidebands
separated from the main signal by the switching frequency and its
multiples. That's why I used such a wide setting for the spectrum
analyzer, so that the first (and strongest) of these sidebands is
shown. Its peak is 60dB below the main signal, which should be
acceptable. In any case, if so desired it can be further attenuated by
increasing the order of the lowpass filter used between the modulator
and the final stage.
And this is the RF output spectrum with an actual voice signal.
It's almost funny to see how efficient such an amplifier is! Just to
fool around, I lifted the RD16 FETs from the heatsink and ran them in
free air. At 12W PEP output, continuous duty with the two-tone signal,
they got warm but not hot. On the heatsink, of course, everything stays
The modulating IRF530 FETs weren't even mounted on a heatsink. They
stay cold too, in free air. I love EER and ET! At the 12W
level it's just a game, but later at the kilowatt+ level this will be
Who said that 200kHz switchmode power amplifiers cannot be built on a protoboard?
A better PWM (2017-12-20)
After playing for some time with the UC3638-based PWM, it became clear
that this motor controller IC has some shortcomings when used as class
D amplifier controller for the widest possible range of pulse width.
Specially the rather large hysteresis of its comparator makes the
pulses snap to zero or 100% duty cycle rather early on the
transfer curve. Since this behaviour cannot be changed from the outside
of the chip, I decided to scrap the beautifully simple UC3638 circuit
in favor of a more conventional but also more complex solution using
opamps and comparators.
This design uses fast comparators with rail-to-rail complementary
outputs, and fast, low distortion, low noise opamps. It works
significally cleaner than the UC3638, and is fully controllable by the
designer/builder, but is still not able to work cleanly from zero to
100% duty cycle, due to comparator hysteresis. A few percent of the
range have to be sacrificed at each end. Another version using much
slower, antique LM311 comparators with pull-up resistors and a MOSFET
inverter produced less clean internal waveforms, but still produced
almost the same quality in the final signal. So if you don't want to
solder the ant-size LT1713, feel free to go the LM311 route.
Note that this circuit is not final!
It's intended just for experimenting at low power. The final version
will use several MOSFETs of a more modern type in parallel, probably
with a stronger driver, and might not have the deadtime circuit shown
here between U3 and U5, or might have it but with a different time
constant. Actually I built my test circuit without the deadtime
circuit, but included it in the schematic for completeness. Also the
startup behaviour of this circuit is still uncontrolled, which I intend
to revise for the final version. But if you want to experiment with EER
or ET, this circuit should do quite well.
Just in case you haven't noticed: You can click the schematic to get a legible version...
Defining the project
These days I have been in a mood to make handsome drawings, so I
drew a basic block diagram of my intended transceiver too, as things
stand right now. A lot of this remains to be defined, changed,
experimented, dropped, replaced, given up, reinstated, and so on.
Even so, this block diagram might be useful to make clear what I'm trying to develop...
Trying other pulse width modulators (2018-3-10)
I'm not completely satisfied with the performance I'm getting from my
pulse width modulator. So I tested some options. Below are a few
oscillograms that allow comparing the linearity of different
approaches. You can click these oscillograms to get larger and more
detailed versions. Each of these was done by applying a 100Hz triangle
wave, adjusted to slightly saturate the PWM, so that the flat extremes
of the curves represent zero and 100% pulse widths. Then I adjusted the
scope to make best use of its screen.
I was given two samples of the LTC6992-1. That's a tiny 6-pin SMD that
implements a complete, full range pulse width modulator, requiring only
an extremely simple external circuit, and accepting a 0-1V input range.
At first sight it seems ideally suited to the task of turning the RP's
analog envelope signal into a PWM signal.
I made a basic test circuit configuring the IC's oscillator for 200kHz,
its internal frequency divider to 1, and passing the PWM output through
a 2-pole RC lowpass filter with a cutoff frequency of around 20kHz.
Unfortunately the catch lies in the poor linearity this IC has. The
oscillogram shows a very clear bow in the overall curve, deviating up
to about 4% from the straight line. Also the line is somewhat wavy
instead of straight, as if the PWM function was implemented in many
small sections spliced together.
The upper end of the response shows a clean transition to 100% pulse
width, with is excellent, but the lower end shows a slight step
response - the IC cannot produce arbitrarily short pulses, dropping
instead to zero pulse width below a certain threshold.
Looking at the output pulses one can see a severe frequency pulling
effect during modulation, which might be involved in the overall bowing
of the tranfer function.
There are two ways to run this IC at 200kHz. The one recommended in the
datasheet, for reasons of lower power consumption, is the one measured
above. The alternative is to configure the oscillator for 800kHz, and
set the frequency divider to 4. This is what I did next.
Interestingly the overall linearity is much better in this
configuration, with the overall distortion being only about half as
much. But the waviness of the response remains, perhaps even stronger
than before, the distortion at the low end increases, and some
distortion appears also at the high end.
I cannot blame this IC, which was never intended for high quality, low
distortion pulse width modulation, but for simple non-demanding
application such as display backlight control... It has a linearity
specification of 4.5%, and it does meet it. But this just isn't
good enough for the task at hand. And that's a pity, because it looked
sooooo attractive, with its extremely simple application circuit!
So I'm back to the circuit shown a bit up in this page, built around
two LT1713 comparators and an LM4562 op amp. This oscillogram shows its
output, using the same 2-pole RC filter used for the oscillograms
above. But it's powered from 5V, instead of the 8V shown in the
diagram, which puts the LM4562 in a rather compromised situation, given
that it's not a rail-to-rail opamp, and not even a single-supply op amp.
Still the overall linearity of this circuits is very much better than
that of the LTC6992, appearing to be essentially a perfect straight
line from about 3% to 96% pulse width. But the ends of the range do
show distortion. Closer inspection with the scope shows this to come in
part from the switching transients of the second comparator causing
interference to the op amp and first comparator, while another thing
contributing to distortion is the lack of speed of the LM4562. That''s
a pretty fast and very good op amp, but to make a really clean 200kHz
triangle wave, even higher speed would be better. So I have ordered a
few LT1809, which are very fast rail-to-rail op amps. In about 4
months, the time typically taken by the Chilean postal service to
deliver a parcel, I hope to be able to continue improving my PWM...
The ridiculous slowness of the Chilean postal service is a disgrace.
They claim it's the customs processing that causes these delays, but a
simple letter sent to me by priority airmail from Germany took the same
4 months to arrive, and I don't suppose that letters are subject to
This shows the output of the power stage shown in the diagram above,
using an IRS2110 driver IC, two IRF530 MOSFETs, the 4-pole LC low-pass
filter, and a 10Ω load resistor. The power supply was 13V with somewhat
weak stiffness (long cable), and the PWM circuit is the one of the
The first obvious feature is quite some interference from the power
switching into the PWM. I have to say at this place that the circuit is
still built on a solderless protoboard, so this kind of problem is to
be expected! It should largely go away when making a good PCB.
However the poor construction on a protoboard is a great tool to
uncover other problems! The large switching chaos in the upper 10% of
the range is caused by shoot-through in the power MOSFETs, causing
intense current pulses of a few nanoseconds duration, that cause
increased interference to the PWM.
The IRS2110 has pretty good pulse width fidelity when the pulses aren't
too short. But when input pulses get narrow, or near 100% wide, this IC
increasingly alters their widths - and when driving the two inputs with
exactly complementary signals, as my LT1713 is doing, the IRS2110
actually drives both MOSFETs on at the same time, for brief moments!
So it would have to be used with a deadtime circuit. That circuit is
shown in the diagram up this page, but was NOT in place when taking
Instead of inserting that deadtime circuit, I replaced that chip by an
IR2110. The IRS2110 and the IR2110 are extremely similar and
pin-compatible, but the version without the "S" has a
significantly longer delay for switch-on than for switch-off of each
driver output. As a result it provides a deadtime by its own, when both
inputs are driven with exactly complementary waveforms.
The effect of the change is obvious: The interference to the PWM
circuit is much reduced, because the large shoot-through pulses are
Unfortunately there is some waviness in the response, affecting roughly
the first and last 15% of the range. Some of this is caused by the
construction on a protoboard, but also some is caused by the driver
chip proper, which does change the pulse widths to different extents
depending on the input pulse width. Also the deadtime it enforces tends
to be a little too long, like 40ns, and class D amplifiers depend on
near-zero deadtime to maintain a linear response.
What I take away from these tests is:
- The PWM circuit with fast comparators and op amps is best;
- A faster op amp there should help, specially a rail-to-rail one that allows a larger signal swing;
- Good layout on a PCB should contribute to making that PWM circuit plenty good enough;
- The LTC6992 instead is unfit for this application, and so are the
other ICs I tried before (power supply and motor controllers);
- A faster/better driver with the best possible pulse width fidelity is needed in the power stage;
- PCB layout of the power section must be top notch, when the circuit will handle 50V 40A instead of the experimental 13V 1.5A.
More news related to the above
Pavel might program a pulse width modulator into the RP's FPGA. This
would delete the necessity for a hardware PWM. But he sees trouble in
achieving a high enough PWM frequency along with sufficient resolution.
He mentioned using sigma-delta modulation instead of PWM, which he says
is easier to implement with the required quality. The problem I see
with that is decreased modulator efficiency, due to the higher number
of switching transitions per unit of time, causing higher switching
loss. Maybe it would be best to use a sigma-delta system with the data
stream processed in such a way that pulses are transposed and joined,
aways keeping the number of transitions per time unit below a certain
A nice byproduct of using delta-sigma modulation would be that the
humps of spurious signals 200kHz away from the main signal should go
away, replaced by more broadband, lower level artifacts, which are less
likely to be detectable.
I'm wide open to experiment, and finally use what works best.
Comments and questions are welcome. And any ideas to solve the problems
exposed here are particularly welcome! Collaboration is
You can contact me at .
Back to homo ludens electronicus.