Quisk/Charleston SDR Update
tfox at knology.net
Fri Jun 25 15:43:26 CDT 2010
I've spent the last week (when time allowed) fixing some of the bugs in
my mods to Quisk for the Charleston Receiver. As a reminder, Quisk is
an SDR program written by James Ahlstrom, N2ADR. It runs under Linux,
has a decent GUI, and most importantly does not require the use of jack
to move samples from the hardware to the dsp code, which is not DttSP.
Quisk is a combination of C and Python. I combined/transmorgified John
Schwacke's Charleston code for GNU Radio and Jim's Quisk SDR-IQ code,
which also uses USB connectivity to the host computer.
There were some issues with buffer underruns for the output audio, which
I thought was due to CPU loading because of the graphics. That turned
out to be a red herring, as the problem was that I had not matched
buffer sizes between two code pieces. I knew they did not match early
on, but forgot that in the excitement of seeing Quisk work with the
Charleston board. That's been fixed. The software also now supports
all the hardware controls on the Charleston board (PGA control, LNA/BPF
bypassing, LNA High/low, and LNA gain adjustment).
Once I got the software working in a basic form, I contacted Jim
Ahlstrom about a few minor things. He has been most helpful, and has
provided a better long-term framework for adding the Charleston support
to Quisk. He's been great to work with, especially since I'm not
familiar with Python.
Now that I've had the Charleston Receiver working for about a week under
Quisk, I've been able to spot some issues. (the old GNU Radio code did
not allow you to easily see all 192k, while tuning and hearing one
signal very well, plus the screen updates were slow and too averaged)
First of all, the Charleston board is more susceptible to front-end
overload. Having a 12-bit A/D front-end makes its dynamic range
somewhat limited, not a surprise to us. I've begun to use a Brainerd
band-pass filter board in front of the receiver, which helps a lot. I
plan to add commands to allow the host computer to control a Brainerd
BPF, through the Nexys2 FPGA card. Proper PGA and preamp adjustment
helps mitigate overload as well. (alliteration anyone?) Other BPFs
could also be defined and driven from the host software. If I put the
BPF control totally inside the FPGA, a new FPGA bit file would need to
be made for each different BPF, so I am choosing to put that
intelligence in the host instead (for now).
It would be nice to create a loop where the various PGA and preamp
controls were automatically adjusted to reduce/prevent front-end
overload. Unfortunately, the TI AFEDRI8201 downconverter chip does not
have an "ADC-overload" flag/bit. I'm thinking that I could look at the
actual samples, and that would tell me (within a limited amount) if
overload is occurring, such as many samples hitting the 12-bit limits.
Unfortunately, that is not the whole story. For example, a signal
outside of the 192k bandwidth could be overloading the A/D itself (since
it's sampling the total 30MHz input), but that overload is not
necessarily within the 192k band being delivered to the host computer.
The BPF solves some of that, but I've had a VERY STRONG SW broadcast
signal at about 6.985 MHz get through the 40M BPF, and swamp the
receiver, even though I am LOOKING at 7.1-7.3MHz. Maybe if I looked at
an average of the "noise-floor" samples, and see them unexpectedly rise
(which happens during overload), that is an indication. But, electrical
storms can also cause that symptom. Ideas anyone?
The Charleston board is decimating to a 192k output sample rate, lower
than we had been using. If I try to go to 384k or 480k in Quisk, I
start getting significant audio glitching and buffer underruns again. I
am looking into this. It appears to me that most of the Quisk graphics
work is being done in Python, even though Jim says the critical graphics
is done in C. We have used 384k and 480k with GNU Radio, although that
exhibited some occasional audio glitching on my older Toshiba laptop as
I plan to use Jim's new framework, and clean up my kludged code mess
over the next week. After that, I will release my version of Quisk with
the Charleston mods, probably via the AMRAD web site. If anyone wants
to see this interim code, I can send a tarball (except to Louisiana,
which has enough of them already). Keep in mind that this temporary
code will be changed drastically in the next week, but it does make the
Charleston receiver more useful.
I'm wondering if the Quisk code can be modified to work under Windows?
I'm not a Python expert, or even a beginner, so I'm not sure how hard it
would be to convert it to Windows. I feel comfortable that I can handle
the hardware/USB conversion part.
Another Windows option for SDR usage of the Charleston receiver is the
HPSDR Kiss Konsole. It is written in Microsoft Visual Studio C# 2008
(free). It is designed to be used with the openHPSDR hardware, but uses
libusb for USB interfacing, very similar to Quisk. I have an openHPSDR
boardset, and have played a little with Kiss Konsole. Rather than use
the Digilent driver for the Nexsys2 FPGA board, we may be able to use
the generic libusb, which I have working in Linux. Of course Linux's
libusb apple does not necessarily match Microsoft's libusb orange,
especially with USB. I've heard that Microsoft has really screwed up
USB implementations in Windows, and each variant of Windows has a
That's a long update on where I am for now. More details to follow.
More information about the Tacos